Originally published in 1979, Philip Crosby’s book “Quality is Free” is a seminal work in quality – especially manufacturing quality. The premise of the book is that defects – poor quality – often causes re-work which is expensive.
I’m sure we have all seen it … a road gets torn up (for months) and new infrastructure is embedded under the roadway … and then it is paved over … and construction is finally over. And then here they come back again … tear up a part of the road that had just been replaced … and put something else in … or fix something. If it had been planned properly… or the workmanship hadn’t been shoddy … then it would have all been taken care of the first time the road was torn up. Re-doing it cost somebody (probably us) much more then doing it right in the first place would have cost.
With respect to software, as one of the reviewer of Crosby’s book puts it: “Very good read, but I’m not sure how well it translates outside of manufacturing – the software world is not like a production line: requirements are fuzzy, the designers are also the builders, and defects often arise from emergent complexity.” Fair enough. However, re-work in software is much more expensive than getting it right in the first place. That is not to argue for a “waterfall” development process (more about that later) … but just to observe that adding – or correcting – a feature after it is developed is much more expensive than developing it correctly in the first place. Studies have shown that correcting errors after the software is fielded is 30x more expensive than doing it right in the first place.
So, quality is free – in software – when the entire lifecycle of the software product is considered. The lifetime cost of software is heavily weighted to the lifetime maintenance of the software (we’ll define exactly what that means in a later post). Consider that there is still software running today that was written 40 years ago.
The confounding factor – and a subject of yet another, later post – is how to decide how much focus to put on quality when you have no idea whether the software will survive in the marketplace. How do we balance the cost of quality when building a “minimum viable product?”