Horses For Courses

Over the years I've worked on projects in various problem domains including electricity metering, defence, taxation and banking and, if you've followed my blog over the last year or more then you may have realised that I currently work for an advertising company. In working in the advertising domain the main thing that I've noticed about projects is that they usually have shorter development timescales for a given set of functionality and, once completed, the software's natural lifespan is also fairly short. All of this got me thinking... if the software you're writing will only be used used for a few short months, then should you employ a different style of coding? And, not to beat about the bush, can that software be written in a more slip-shod way to software that will be used for year's or upon which people's lives depend?

Taking a look at some of these problem domains, it should be possible to characterise and prioritise the features of software that are important. The quick table below details the life expectancy of software in some of these domains:

Problem Domain	Estimated Lifespan
Defence	Possibly Years - with updates and modifications
Taxation	In the main a few short years with a minimum lifespan of one year. It'll have constant updates to reflect changes in legislation.
Banking	Depending upon the banking area, banking software can last for years, though with updates to reflect changes in legislation.
Advertising	Months, or possibly a year or two.

Next, compare this to the consequences of your software crashing:

Problem Domain	Consequence of a Crash
Defence	Someone on your side dies
Taxation	Taxes are uncollected or overpaid
Banking	The bank loses lots of money on a deal
Advertising	People get a bad perception of your product

Taking the tables above together, then for defence software where people’s lives are at risk then I suggest that your design approach should produce ‘robust’, ‘safe’ and ‘fully tested’ code.

Did you know that one of the things that worries me about flying is that I know that staying in the air depends upon working software. Now, it’s people like me who write the software and I can, like every other programmer, easily make mistakes and a simple mistake at 33,000ft can send me plummeting into a mountain... it doesn’t bare thinking about.

In terms of taxation, then the word ‘accuracy’ comes into play. Imagine what would happen if inaccurate software charged everyone too much tax... Also, as this software will be updated regularly to reflect changes in legislation, then it must be maintainable and readable, as people may be enhancing it years after you’ve left the company.

Getting back to my current problem domain of advertising, then yes it has to work, but as the projects and the lifespan are pretty short, then in order to fulfill clients’ needs and expectations the word reusability seems to be more applicable. The more re-usable tools you have in your toolbox the more short term projects you can deliver.

Finally, you may ask what about software for the banking industry. If you believe the newspapers, bankers have all the money, pay themselves huge bonuses and have caused the current recession. If that’s true, the software written for a bank must be very expensive.