Written by David Tebbutt, MicroScope 03/84 item 02 - scanned
Do you know how many computer projects have gone in on time, to specification and within budget? I suspect the answer is none. In fact, I don't suppose any project has ever gone precisely according to plan, but computer projects seem to be particularly vulnerable to this general problem.
I dare say it can be quantified, like the popular 80/20 rule so often quoted in business. This is used as rough guide for all sorts of things. For example: "80 per cent of your time is spent looking after 20 per cent of your customers". With computer projects, the rule is likely to be something like "80 per cent of the development work is done in 20 per cent of the project duration".
All computer projects have a software element, and I once heard someone describe the management of such projects as an exercise akin to nailing jelly to a tree. I have found myself in charge of many such projects over the years, and I have enormous sympathy for that person's point of view. After all, when you're building a house, you can see when it's 80 per cent complete. With software, things appear to progress remarkably well up to that point and you always get optimistic, thinking that you've hopelessly over estimated the time needed for the whole project. Little do you know that you're about to get caught again, and the rest of the work is going to take four times as long as it has already taken. Woe betide if you ever let on to your customer (manager, PR company, shareholder, etc.) that you think things are going well. They aren't and they won't.
Of course, what usually happens is that the software development actually progresses to become 80 per cent complete in something like half the allotted time. Boy, are you in trouble then. Following the 80/20 rule, this means that your project is going to take 2 1/2 times the original estimate. So always expect massive optimism from software people and if, in the early days of a project, they're not telling you it'll take a quarter of the original estimate, then something is seriously wrong.
That all sounds pretty cynical doesn't it? And yes, maybe I've gone a bit over the top with the 80/20 proportions, but ignore the general principle at your peril. A lot of hardware manufacturers have been caught out by optimistic program development estimates. A good programmer pours his or her soul into whatever bit of programming they happen to be doing at the time. The end product is a sort of immortal and highly visible statement of how good a programmer they are. At first, the programmer simply wants to crack the problem which is the subject of his or her attention and, if things stopped there, projects would finish early as often as they currently finish late. But once the basic problem is cracked (the 80 per cent stage say) the programmer starts to get 'creative' and think up little ways in which the product can be 'improved'.
Let's picture a programmer who has been commissioned to write an operating system for a new machine. It has to fit in a certain size of memory - let's say 8K. This is a magnificent challenge, and the programmer sets to work to produce the very best system he can for this limited amount of memory. As he goes along, he thinks of little improvements which make the product far better than its original conception. Each one takes only a few extra bytes, not to mention a few extra days. He is well on the way with the project when he realises that the code has turned out just a little bit longer than it should be, and there is a real danger of running out of room. Sensibly, he discusses the problem with the project's sponsor who decided that, rather than drop one or two of the less important features, they will increase the amount of memory available for the operating system.
You can guess what happens next. Our programmer realises that not only can he re-implement the dropped features but he can build in all those others which he'd had in the back of his mind. Despite wails of protest from the marketing people who are anxious to get the show on the road, our friend is more concerned about being connected with the best operating system than with hitting a particular deadline. And therein lies another problem.
It is rare for someone who is essentially a craftsperson to have the same commercial outlook as a marketing person. The craftsperson's objectives are totally at cross-purposes with the marketing person's. One wants to give the best they possibly can. The other wants to get an acceptable product on the road in the shortest possible time. In the case of our friend, he is likely to get his own way on the grounds of "Well, now we've got all that memory, we should really make the best use of it". The project will run late and, no doubt, as the new memory begins to fill up, there's a danger of going through the same loop again.
The fatal mistake in this fictitious but entirely plausible scenario was the decision to give the programmer more memory to play with. The dropping of a couple of features would have been infinitely preferable in business terms than the decision to increase memory. After all, the buyers of the system will be quite oblivious of what might have been. And, no doubt, looking at the 8K, they would still have been impressed at the achievement of our whizzo programmer.
If you want to maximise your chances of getting a programming project through the door on time within budget and to the original specification, then the last person to employ for the job is a 'craftsperson' programmer. It is better to get one who has less ego wrapped up in the task at hand and who is more interested in doing a good job of work than in pushing the software art to its limits.