In an experience report on the benefits of object-orientation for OOPSLA ‘92, Ward Cunningham observed:
“Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”
Thus launched the twenty-year IT journey of ”Technical Debt”; and though compelling with sufficient context… “the word Technical is too broad to be useful”1 as a guide for structural quality and the Debt metaphor too abstract for real-world development guidance. Ward has acknowledged that many have “explained the debt metaphor and confused it”2.
This post seeks to promote applying energy toward Software Flexibility instead of Technical Debt management — beginning with two starting-point metrics:
- Application Architecture measured by Cyclic Dependency
- Software Design measured by Duplicate Code3
Like any metrics, these two derive from a belief; the fundamental purpose of:
- Object-oriented use-case-agnostic Application Architecture is to structure source code into dependency groupings
- Software Design is to ”eliminate duplication”4 of source code (Said another way, eliminate waste5.)
Consider the gains realized after two decades of using a metaphor… then imagine what a decade of measurement focus could achieve for a positive impact on global application maintainability as businesses evolve in unknown ways.
And, I challenge tool vendors to include these two Software Flexibility metrics in future offerings.
- Alexander von Zitzewitz – phone conversation.
- Ward Explains Debt Metaphor – YouTube Video
- The author defines ‘duplicate’ as:
- More than one consecutive identical lines of code creating an additional maintenance point
- More than one method of similar structure whereas a generic method could perform the function
- Kent Beck uses this term in “TDD By Example”, although I don’t think he makes an explicit assertion relative to Software Design.
- Richard Askew equates the elimination of duplicate source code with the Lean principle of ‘eliminating waste’ on a LinkedIn “Lean IT Enterprise” group discussion.