Software without a design can very quickly grow into an unmanageable mess
Making changes to this mess or even maintaining it in a working condition can be a costly and time consuming exercise. I have recently come across two applications whose owners refuse to work on them any more – for fear of upsetting something and then never to work again. These are strategic applications, not just tiny insignificant bits of code.
In both cases, the companies can’t move, they can’t afford to re-engineer them – they are stuck.
A good design and some guiding principles can prevent the mess happening in the first place. It can even be retrospective to un-stick the project – so to speak.
I use the analogy of a building – very few would build a house without a design. And software can be far more complex than a house (and sometimes more costly too). You live with both.
I have an answer: it’s either long enough or it isn’t.
Too short you have to either get another bit and tie it together or find a longer piece in the first place.
Too long and you can either cut some off or just not use the loose end.
Quite often it’s just perfect.
And my point? Well software is the same, whether you just spent a million or £200; if it fits the bill – great. Off the shelf and not use it all – fine (as long as it’s not too long). Integrate software components – fine.
One big difference in software is that the job itself can expand after you have tied it up – or even while you are tying it up! So the answer becomes: it’s long enough with some spare. And it’s important to know how much spare.
Of course you could also use cable ties, plastic coated steel wire, ribbon or tape …
Just a thought, but it occurred to me that the best way to pass an exam is to write the test paper.
Now before you say “obvious, you dopey dude” (use your own vocabulary) I’ve been using test driven development on certain types of project for years and am quite surprised that not many others do.
Like you build the tests before you design or write any code …
No need to over-do it of course, but it saves a huge amount of time and in fact helps with the requirements up-front too – one of the benefits is that it overcomes the “it always works this way … except for this little scenario that I forgot to mention” problem. Lots of other reasons too but I get boring …
Some of the quickest, largest and most successful projects I’ve been involved with have used this approach.