Sunday, April 30, 2006

Software Myth busting - final ACCU notes

I had intended to draw a line under my comments on the ACCU conference last week. I’ve got most of it out of my system but I had to return to Peter Sommerlad’s presentation - Only the code tells the truth.

Peter’s starting point was that, well, only the code tells you the truth about the system. That is the code, the stuff that is compiled and executed, not the documentation, not the specification, certainly not the UM and not even the comments but the actually lines of computer code.

There is nothing new in this assertion really. One of the things I had drummed into me by Derek Andrews when I was an undergraduate was: code is an executable specification, and as such it is the only completely accurate specification because, well, its the one that executes!

(And thanks for Hubert Matthews for a very interesting keynote at ACCU and reminding me that Derek is still out there practising software!)

Peter’s argument continues: if only the code is the truth what are we doing with all this other stuff? In fact, maybe a lot of what we think of as “good” software practice is actually mythology that has grown up around how we do it.

At one extreme some of this myth may be rooted in good intentions, it never did us any good but we thought it might and somehow we came to believe it. (I’d put the original ISO9000 in this category.)

Some of the other myths may have been true at some point in the past but we should really ask “Is this still good for us?” - perhaps we need to abandon some practices that were good once upon a time but don’t really add value any more.

One of Peter's suggestions was the comments in code may actually detract from its maintainability. The argument goes like this: some comments are useful, many are useless (comment “increment i” before ++i for example), others are confusing, some are downright wrong. If the code is expressive enough then perhaps we don’t need comments in here at all.

This is pretty contentious stuff and unfortunately the group allowed ourselves to get side tracked down this avenue for 20 minutes or so when really is was just a side show.

Peters other suggestions included: strong typing may reduce understandability, design before coding can be detrimental, testing after we code is wrong, “everything is an object” and a few more too. Basically Peter is challenging us to look long and hard at some of the practices we engage in and ask: are they still useful? And so it was the session became a very interesting debate.

This opens a real Pandora’s box but its about time the software development industry engaged in some Myth Busting.

Here is a suggestion of my own for something we need to look long and hard at

Myth: accountancy correctly values knowledge based companies and their assets.
Is developing software an expense or an investment?

Most of the time when we develop software it is classed as a cost on the balance sheet. But in fact the result is an asset - software code - in which case we are increasing the assets the company owns. If this was a car or a factory it would be included on the balance sheet and it would be classed as an investment. So, £1 spent on development becomes £1 on the assets owned by the company.

Take this a step further; what about our people? - remember “our people are our greatest asset.”

In which case, sending someone on a training course isn’t a cost, its an investment and should be included on the balance sheet under assets. Companies regularly include “good will” on the balance sheet so why not people? And why not source code?

Once accept both these points the incentive for companies to invest in people and software increases drastically. No longer are these expenditures reducing profits, they are increasing assets. However, current accountancy doesn’t recognise this.