Software. I design it, write it, test it.
In 30 plus years in the industry, I’ve worked on almost every application you can think of – except wages.
Commercial applications? Yes. Just a few. Sales order processing, sales, purchase and nominal ledgers, parts explosions, work in progress, factory loading and production planning, stock control, and warehouse picking systems. Quotation systems, and a system for handling cash (Called CRAP from Cash Received And Posted – Yes, really!). And a Sickness and Savings membership system.
Some of the more esoteric applications include a compiler for “pilot”, a Petri net animator, and a system tacked on to the end of a production line to produce ECWVTA certificates for cars.
And the whole time, I have been pushing one message to anyone who would listen. It is better, faster, and cheaper to build it right first time that to build it wrong, and then have to find the bugs, design the right solution, build it, and test all over again.
Seems obvious to me.
But managers fight me. They say we can’t afford it.
Customers fight me – usually with some form of “I have no time to think out what I need – just build me something”. How they think I know how they want to run their business I can’t imagine.
Colleges fight me – with “That’s not how its done here”.
And you know what. The managers were right.
We can’t afford to build it right first time. Let me explain.
The “Normal” way a software house bids is for fixed price work. The market is competitive, so margins are thin. However they know the specification is wrong, and will need changing. So they quote a fat rate (2.5 times cost?) for changes.
Lets assume the software is delivered on time and on budget. (Humour me – it can happen).
The specification wasn’t perfect. It wasn’t bad – 10-15% was not needed, 10-15 % was missing and 10-15% was wrong. Now we don’t need to un-write the extra stuff that simply complicates things. That can stay. That leaves about 25% extra work, plus testing, to do at the fat, change rate. Lets guess that it takes 30% of the time to identify the problems and retest the system.
That makes the project 30% late, and 30 * 2.5 = 75% over budget.
Ouch!
A career limiting result
As one wag put it “That’s a career limiting result!”.
I hated to see that happen to our vict^h^h^h^hclients.
So I resolved to find a solution.
It took a long time to find one. First, I noticed that there are four parameters to every project – scope, duration, quality and cost. The relationship between these is complicated, and time dependant. If you change something, things have a habit of getting worse before they settle down. For example, if you add people to a late project, the new people have to be trained by the existing staff – so progress SLOWS for a week or two, before picking up.
The traditional way to buy software development is broken in another way also. If you specify the scope and duration, and let the supplier specify the cost, then you only have one independent variable – the quality. If the original guesses were a bit off – and they often are – the only thing the project manager can do is alter the quality. Its is not surprising that poor quality software is delivered so often.
And there is worse to come. With the cost of changes being so high, the customer will argue that a given change is a bug fix (free) and not a specification error (costly). So the supplier has to document every decision, so that he can allocate blame, just to protect his margins.
Oh dear. I thought that building software was about solving the customer’s problems, not fighting with him over who pays for what.
Finally it dawned on me. Use a system that fixes the quality on “high”, choose the resourcing level and have duration proportional to scope and cost. Deliver the whole thing as many tiny deliveries as necessary, each complete, tested and proven. Do the most valuable things first. Stop when what remains would be more costly than it is worth to the customer.
Results:
- No matter where we stop, the client gets good value for money.
- No matter were we are, the client has been invoiced for only delivered software
- No matter what problems we face, the customer and supplier face them together
- Bugs are as rare as rocking horse droppings.
So, enter TDD. Test Driven Design (or Development). The idea is that the programmers wait until the last possible moment to freeze the design of each tiny part of the system. That way they have the best chance of getting it right.
Then they create executable tests that will tell them if the system does or does not perform to spec. We have a computer, so lets make it work for its living. (A computer costs £5000 over 4 years, a programmer costs £5000 a month – 50 times as much – and goes sick).
Run all the tests and they pass. You just proved that not only have you written the code right, you haven’t broken anything you wrote yesterday, or another wrote last week/month/year/decade. You haven’t introduced any bugs.
So you quickly have a system that will run, but does not yet do everything. If Pareto was right, you spend 20% wisely and get the functionality used by 80% of your cases. That is a usable system. Use it, and you can discover where the original ideas aren’t quite right.
OK – you may spend 30-40% and be able to handle only 60=70% of the cases. Its still worth doing.
The idea is that we build the system in tiny (weekly?) slices. You, the customer selects what is to be included each week. The system grows to become what you really need. We don’t build the 15% you won’t need. We build the 15% that was originally missed instead.
And the 15% that was wrong in the original spec? You correct the “story” as we call it, before we build, and we build it right.
Result. No over-run, no time delay. And no bugs. Ever.
Really?
Well, nearly. There are things that we can’t test, and spec errors do still happen. What it does achieve however is a situation where bugs are a real rarity. Our guess about how long a project will take is still as rough and ready as the next man’s – however there is real hope.
We measure progress. If we have built 25% of the initially identified functionality it is possible to multiply up and say that the final outcome will be 4 times what has been spent so far. So we can quickly – and reasonably accurately – estimate the final cost. If that is way off the initial estimates, there is plenty of time to alter scope or budget to make things come out well.
Remember this is after spending 20-30% of the budget. Compare that to receiving buggy software, late, after spending all the budget, and being faced with spending as much again to sort things out.
We won’t (don’t have to) alter the quality to make the delivery.
Look ma, no bugs
The spec is fluid and the customer can play with the system, so he can tell us what is really required of this small function, this Monday(say). We freeze the spec and deliver the new functionality next Monday – tested proven and debugged. We both know we have not introduced any new bugs. Great.
We can assume that anything wrong is either a new feature to be added or a spec error that needs correcting. Either way, its not a bug.
So we no longer need to document every decision to apportion blame. Horray! Lets save 10|% of all effort and make the working relationship pleasant! Lets us both – software house and customer – work on the problem, and not argue. It makes for a great life!
But it is a hard sell.
To make a profit, I have to quote a rate that is more than cost, because I haven’t the cushion of the fat rate for changes.
Lets work through an example. There is £10K work (at cost) in the spec that I am quoting against.
Before, I could quote £10K and 10 weeks.
I know this will work out to be £13K (cost) and the invoices will amount to £17.5K for 14 weeks work. The 35% margin overall is just fine.
But look at the new situation. I have to quote £13.5K and 10 weeks in order to make the margin, and that looks bad against the competitors £10K and 10 weeks.
The difference is in the final outcome. 13.5k on 10 weeks, or £17.5K in 14 weeks? Which would you prefer?
So now you know that my old manager was right, way back when.
I can deliver on time and to budget as I have explained – but I can’t sell it! He could sell us, even if the outcome was hardly pleasant. Thats why he was right to say he could not afford it.
But I’m not giving up yet. I believe that there must be a way through this problem. Treating customers fairly and honestly should always be the best policy.
If you have any ideas about how I can sell my services, so I can deliver top quality wok on time and budget, please add a comment.
If you want to explore working with me to create your computer system using these ideas, please email me.
Ian