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 an intentionally minimum set of starting-point metrics:
- Application Architecture – measured by Cyclic Dependency
- Software Design – measured by Duplicate Code3
- Software Modularity – measured by Class and Method Size
This balanced set of metrics is derived from core principles; that 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.)
- Software Modularity is to promote human code understanding (or readability)
Consider the gains realized after two decades of using a metaphor combined with a narrow focus on static code analysis… are they sufficient? Could more balanced measurement have a broader impact?
Comments and feedback are welcomed!
- 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.