John Barrdear has an interesting comment on IT and how it often introduces inefficiencies into a business process. He writes:

In practice, I have seen two other phenomena that both work to increase bureaucratic staff numbers:

a) IT tends to make work practices quite rigid. ...

b) IT projects, at least in the public sphere, are rarely implemented (or, frankly, designed) well. This seems to exacerbate the problem in point (a).

I tend to split software projects up into two possible sections; ones that have to take into account a dynamic business model, and those that are for a static business model. They require different software approaches.

The static business model is one where the requirements can be written out, then they can be handed off to some designers to be estimated, and then commodity labor - probably in India - can be used to write software to the APIs or interfaces.

Because it is a static system there is not that great an issue of it is late or overly complex. Testing can also attract large resources as the system will be in production for a long time simply because the business model is not moving at all.

As an example a friend of mine works at the federal reserve in DC. A lot of their systems are written in COBOL and run on mainframes. The issue they are facing is that much of the skilled labor required to run these systems are retiring. The only reason they are updating them to C# is because the labor is getting to expensive to run the old ones. Not because the old systems are not working or don't reflect the current business process.

The flip-side to the coin is the dynamic business model. In my opinion and experience this is the fun part of software design and development. It is also the most stressful and full of pitfalls.

Because of dynamic business requirements that change constantly over time as new challenges from existing customers or future markets are met, the software cannot be designed as a static system. In the six months of requirements collection, nine months of design and year of development overseas a dynamic business has a new business model and process. The software lags behind and enforces inefficiencies in the system.

Consequently it requires a different approach. The Agile Methodology is a response to this. I personally like Alistair Cockburns production philosophy that minimises development process such that it meets customer quality control requirements. Anymore is overhead and imposition.

One of the components of Agile Methodology is unit testing. This is done to meet quality control requirements. For instance Space Shuttle software will have a 100% test coverage. A social networking website may only have 5% test coverage. It depends on what the customers will accept.

There is an analogy between software development and law. Artur Bergman mapped and visuallised several systems of code and law to determine if there was a pattern.

Bergman writes:

Quite clearly, we can see that US Code is appropriately named since it has more in common with kernel32.dll than the contents of Project Gutenberg. Not only is code law, but law is code: a highly structured set of instructions that allows a state machine to function, ideally without any ambiguity.

It is probably not a surprise that SSR is heavily haunted by software developers and technologists. There appears to be a natural union between software code and legal code.

We can also divide the legal world into static and dynamic. Where the static is the constitution which has a slowly moving business model and process. And the dynamic component is statutory legislation. Far more volatile and requires greater customer input and quality control. There lies the rub, our quality control in legislation is constitutional constructs such as separation of powers and checks and balances.

Not direct unit tests however; Andrew Leigh and Justin Wolfers have argued for policy testing:

Why don't we see more randomised trials in Australia? One impediment is a cultural attitude that government services are an entitlement, and therefore must not be rationed. Yet it is time that this conventional wisdom was balanced against the benefits that can flow from careful pre-testing of government programs.

The easiest step to take is to open ABS data to citizen auditors and stop charging for it. The cost to the taxpayer is an extra seven million. A spit in the ocean compared to the electoral bribes that will be handed out this year.