Technical Bankruptcy occurs when technical debt overwhelms the maintainers of a software system. I’ve previously blogged about a case study: how the accumulation of poor development practices resulted in the business failure of highly successful Enterprise IT software company.
The technical debt metaphor provides a nice handle for a software development trade-off that’s been present in every project I’ve ever done- as a manager, architect, programmer, or tester. Ward Cunningham has done us all a favor in creating a memorable tag line. And with this popularity, everyone is of course against it. But how many really understand what drives technical debt? And that is it a symptom — not a root cause?
As Fred Brooks learned in the 1960s, the true difference in effort between developing a program (which is how most developers see what they’re doing) and programming systems product is 10 times (Brooks said 9x – I’m rounding up a little.) The drivers are the additional complexity of system of programs and features for sustaining a product.
This is true regardless of scope: number of function/feature points, use cases, user stories, etc. Even this is under-stated: the number of interfaces increases exponentially with the number of components (programs.) That is, a system of 1000 components isn’t necessarily 10X to system of 100 components — it is often 20x or 30x. The context of usage matters in ways that are hard to appreciate unless you’ve had to live with the long-term effects of sustaining a system of programs for a user community (a product) over many releases.
Yet hope springs eternal in software development. Developers and sponsors of software projects often don’t understand this disparity, so expectations and commitments are made assuming programs instead of a systems product. Developers, managers, and sponsors all underestimate work. Then Bad Things happen. Even if a project is de-scoped and time-boxed, necessary work is skipped – that’s where technical debt starts. Then schedules slip, bugs escape, and revenues don’t come.
This is a chronic problem. If a project isn’t cancelled after an initial confrontation with reality, attitudes often harden and people begin to game each other. This usually results in more technical debt piled on top of the first tranche. That’s how technical debt gets compounded. Left unchecked, this leads to systems (and the businesses built around them) that consume more resources than they produce value — in effect, technical bankruptcy.
This vicious cycle can be broken. Preventative principles were articulated in the 1970s and have been rediscovered about every ten years since (just as each generation rediscovers sex, as friend and mentor Boris Beizer often observed.) Hundreds of software engineering and software process strategies have been worked out and applied with success to many thousands of systems. They all share certain strategies:
Moreover, problems worth solving tend to be big and complex, so some kind of step-wise, iterative, incremental, or agile process is necessary.
Model-based testing is a relative newcomer to the mix. It can and has prevented much technical debt and therefore substantially reduces the risk of technical bankruptcy. Agile processes tend to generate a unique form of technical debt – the Testing Backblob. Model-based testing can reduce this substantially.