Software Engineering and Tax Law
Posted by Jacques Chester on Wednesday, November 12, 2008
Software and the law have a lot in common. Both are complex topics forever catching up with a complex world. They convert intellectual structures into real world events, implications and outcomes. Both of them have simple formal models which turn out to have infinitely complex variations as soon as we embark on developing them in any scale.
This parallel is truest in legislation, the form of law which most resembles properly engineered software. The ideal piece of legislation is as short as possible, as simple as possible, with as few negative side effects as possible. Like software, a mistake in legislation is cheap and easy to fix early and very expensive to fix after it has been released.
One of the many steps in the classical ‘waterfall’ model of software engineering is requirements engineering. The goal is to elicit, analyse and verify what it is the customers and stakeholders want the software to do. It turns out to be a large and difficult topic in its own right11. An observation: Which doesn’t square with time allocated for teaching. The most important predictor of a project’s success or failure is its size, but very close behind is the capability of its requirements engineers. The capability of programmers comes third. Yet in a Computer Science or Software Engineering course, programming topics are given years of attention; meanwhile requirements engineering is squeezed into a few weeks across loosely connected units. [↩].
One desirable property of software requirements is that they be traceable. This means I can follow a requirement to the resulting code, documents or the like. Or I can work back from the output to the requirement. Likewise each requirement has an identified source, such as a stakeholder, and it’s possible to find one from the other.
Traceability has been shown to reduce defect rates, lower project risk failure and reduce costs generally. It is a sadly underutilised practice in software engineering22. Nitpick: Actually, pretty much every well-researched good practice in software engineering is underutilised. [↩], but it could find useful expression in legal reform.
Take tax law, for instance. Suppose for a moment that the tax law had traced links to and from its clauses, to its applications and its justifications. Suppose that these were entered in a structured way into a database. What insights might Ken Henry’s review glean from that data?
Speaking for myself, I expect that a double-digit percentage of tax laws are meant to close loopholes or catch people trying to reduce tax through one scheme or another. Yet software engineers will tell you that every bugfix has a risk of introducing regressions — ie, new bugs. Sometimes the answer is to prevent that class of bugs occurring in the first place.
One such example is changing programming languages. The most influential and important language in the past 30-some years is C and its direct descendant C++. In the past 10 years Java has become the language of choice for most large projects. One of the key things that made Java popular is that it simply did away with entire classes of bugs by design. No need to consciously ensure that your code doesn’t contain array overflows if the language will catch it for you.
So returning to the tax code, suppose we find out that the bulk of its complexity and volume is tied up in coping with subversion of intent. Now what do we do? We could try and make subversion of its intent impossible — but that in itself has been shown to be a fool’s errand. Perhaps instead we need to attack the motivation of the attackers; to destroy the incentive to undermine the tax system at all.
That’s another parallel between law and software, incidentally. You generally can’t solve a social problem with a software solution. And you can’t legislate the weather or people’s economic behaviour. What you can do is to align the software or legislation to people’s behaviour in a way that suits your overall goal.
What high-level decision could a hypothetical Henry make to simplify tax laws? Well, one major way of reducing tax burdens is to transform one tax obligation into another one. Consequently we see family trusts and people incorporating themselves. So perhaps the goal is to eliminate the profit in arbitrage between different taxes. That implies harmonising rates for taxes that operate in an analogical fashion. Corporate rates with income rates, for instance.
I’m sure there are lots more such insights hiding in the data. It’s quite possible, for instance, that my hunch is utterly wrong. Maybe the immediate cause of tax law complexity is transitory politics, or lack of review, or treaties. A properly traceable, structured database of laws would let us examine these questions objectively.
ShareThis
This entry was posted on Wednesday, November 12th, 2008 at 6:27 PM and filed under Economics and public policy, Geeky Musings, IT and Internet, Politics - national.
Follow comments here with the RSS 2.0 feed.
Post a comment or leave a trackback.
11 Responses to “Software Engineering and Tax Law”
Leave a Reply
You must be logged in to post a comment.
If you are after insight, try The Tao of Programming.
Apart from quickies like ” Thus spake the master programmer: ‘You can demonstrate a program for a corporate executive, but you can’t make him computer literate.’”, the following is pertinent:
And given the loopholes always being found in legislation and regulations (which is really, a set of instructions and therefore a program), it’s pretty obvious politicians and most regulators haven’t heard of the “Law of Least Astonishment” (look it up in the op cit).
Posted on 12-Nov-08 at 7:03 pm | PermalinkMy first guess is that history notes and EMs are a bit like this already?
But if you mean practical applications, well, I struggle to see how that data could even be collected let alone rendered comprehensible.
Posted on 13-Nov-08 at 3:38 am | PermalinkThe Asprey Report on Taxation in 1975 (to which the Henry Review is explicitly and consciously a successor) made exactly your point about designing a system that needed a minimum of “bug fixes” (of course they didn’t use that term, but it’s what they meant). They even recommended that corporate and personal tax rates be equalised on those grounds - something Paul Keating (whose views on tax were strongly influenced by Asprey) was also a great proponent of.
Yes, simplicity usually means avoidance is much harder (that, for instance, is why we have a single rate of GST when theory indicates different rates for differing goods would reduce the costs to the economy of raising the revenue). But the trouble is that some tough tradeoffs then have to be made against other goals, such as minimising those economic costs or improving fairness. Proponents of flat tax systems (that is, one single rate of income tax) sell the elimination of most tax arbitrage as a major plus - which it is, but you then have to worry about other things such as taxing poor people as much as rich people (which not everyone thinks is a Good Thing).
I suspect such tradeoffs of reliability/simplicity versus other goals are common in high-level software design, too. As Einstein said “things should be made as simple as possible - and no simpler”.
Posted on 13-Nov-08 at 8:44 am | PermalinkAlso, so has anyone seriously proposed progressive corporate tax rates?
At any rate, it seems a bit silly - surely the vast majority of us who earn income in the tax brackets that are over the corporate rate do pay all our tax. Or is that just me…
Posted on 13-Nov-08 at 9:13 am | PermalinkI assume that the first and second bits of that comment are unrelated?
1) US has them, but no-one in their right mind would propose imitating US tax system unless they had US economy and financial markets.
2) That is not just you, but it certainly isn’t many ‘very rich’ either!
DD, all good points, but GST is a great example of where those goals are really mangled by the present system. It isn’t that hard to work out who is poor, so the GST should just be universal and then poor people should be compensated through a direct transfer.
Finally, invariably these days we are supposed to get rid of bugs through ‘principles-based drafting’ and other such EU-inspired crap. If anyone who actually knows how massively the EU has broken domestic taxation for its member countries and still thinks we should copy them, well, I for one would be surprised.
Posted on 13-Nov-08 at 9:58 am | PermalinkThat’s where expertise in data gathering, management and mining comes in. Off the top of my head, a taxonomy of different causes, a taxonomy of mechanism types, enforcement regimes, agencies etc.
This data all exists in various semi-structured forms. Structuring it is not actually the hardest part. It’s just tedious.
Posted on 14-Nov-08 at 12:25 pm | PermalinkThe software engineers have come up with some clever techniques for complexity management. The result is that you can’t run even a basic desktop in less than a gigabyte of RAM and a half terabyte of hard drive space. Windows Vista is reported as containing 50 million lines of code, and that’s without any actual applications.
Give lawyers and legislators access to parametric macro expansion, recursive function calls, application specific meta-languages, variable substitution, pointer arithmetic and parser and compiler technology, think of the disaster they could achieve!
I think that rule-complexity expands to fill the space provided (just like software), so we run the tax system at the highest possible complexity that can be achieved with the resources at hand. The objective in doing this is to ensure that no one really understands it so, no one knows specifically what to complain about or in what way they are getting less than the next guy. A sufficiently complex legal system ensures that full compliance with the law is impossible, almost certainly the law contradicts itself in many places, and thus we generate a haze of confusion under which we practice selective enforcement.
A veneer of benevolent legal regimentation covering a core of discretionary on the spot judgement — the best of all worlds. Remember the simple mantra: legislate broadly, enforce selectively.
Douglas Adams was secretly describing the legal system when he said that if anyone anywhere understood both the Ultimate Question and the Ultimate Answer in the same place at the same time, then the universe would be destroyed and replaced with something even weirder. Probably this process has already happened many times. It is an arms race of sorts, attempting to consume all of the opponent’s information processing capability before you run out yourself. Not unlike cryptography.
By the way, Common Law already has a system of linking to precedents so any particular judgement chains back to all of the original decisions implicated in that judgement. Statutory Law is generated by a series of modifications to existing statutes (what code-heads call “deltas”) each of which is debated in parliament. All of the necessary information is available to link any particular statute back to the people who wrote the statute, the time is was written and the arguments both for and against (a suitable version controlled database in electronic format might already exist if you pay enough to the right people, or one of us could be the first to compile such a thing).
Tax Law contains delegated authority and internal decisions made by the ATO. Sadly these never see public debate, although some of them are attached to political events at the time. I fully support any attempts to improve transparency of this ATO process, which could easily be done with sufficient political motivation.
While on the subject, we could try to get governments to release their budget papers in a manner that actually adds up. I mean, as full tree of accounts and sub-accounts where the total from the sub-account becomes the line-item in the next step up the hierarchy (every figure should be printed twice, except the final total). Better still to have proper nested account codes. I would expect that treasury would have to run something like this internally, but I’ve never seen it published. Maybe there are insiders reading this who can explain why.
Posted on 14-Nov-08 at 4:17 pm | PermalinkA perl and java suite has been used to create a visualization of US tax codes.
See an introduction here at VisualComplexity.
Get the code from taxmap.org.
So…. when politicians claim to simplify the tax code, perhaps they can look at (and give us) before and after pictures of their proposals…. BEFORE they implement them.
Posted on 21-Nov-08 at 1:32 pm | PermalinkYes, but if that works the way it is described (explicit references within the legislation itself) it would not work very well, in short.
At the least it would need to factor in cases. That can certainly be done, though, and the result might be quite interesting.
But then it will have a massive bias towards ‘age’.
Posted on 22-Nov-08 at 4:59 pm | PermalinkThat is tax administrative practice, not tax law. The two are different problems with different solutions.
This is nonsense. The driver of complexity is equity. In the desire to close the loopholes, we end up with complex legislation. The problem really is that easy. The solution obviously is not, although financial statements-based taxation is not a bad idea (since it fundamentally reverses the traditional incentives: normally paying less tax enhances earnings, but if you are taxed on your accounting earnings, well it is very hard to convince your board to depress earnings so as to pay less tax!!).
Posted on 22-Nov-08 at 5:04 pm | PermalinkTaking the example of work clothing from an earlier thread, I believe that the exact distinction between which clothing can be claimed as a deduction and which can’t be claimed, under various circumstances are the result of internal ATO decisions. At least, I don’t believe that such things ever went though parliamentary debate.
Are the fine distinctions of deductibility the crux of taxation? From the punter’s point of view they probably are. From a government’s point of view they are nothing more than a nuisance.
We almost agree, I just feel the need to insert the words “appearance of” into the above statement.
Posted on 26-Nov-08 at 7:17 pm | Permalink