Stop Calling My Fun Technical Debt
If anything, hacking around produces Technical Compost.
Technical Debt is one of those buzzwords that is being overused and misused to refer to any coding or platform research activity that is not directly part of a shippable product. Abusers of the term are requiring developers to justify the very tasks that nurture creative and well-Engineered solutions.
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. [Techopedia.com]
Ok, got it, and we’ve all been there: adding ‘XX’ or ‘temp fix’ or ‘kluge’ in the comments for a method that we should revisit before it is too late. Thus, while better programmers are lazy programmers, the best programmers consider not just their current level of effort, but also their future level of effort and all future developers’ time and effort to maintain or enhance a software system — intuitively understanding through training and experience to avoid so-called Technical Debt. So, I appreciate highlighting the risks associated with prioritizing time to market over future costs. However, I don’t appreciate the generalization of the term to cover any tangential research/coding exercise, often wielded by those who are not plugged into the stream of commit messages that provide the actual details of what is going into the product.
Having worked in IT for over 20 years — I’ve been on many projects that include inheriting pieces of failing software systems; I truly appreciate and understand the costs (compounded over time) associated with Technical Debt. Technical Debt will snowball and transform a software system into a growing ball of duct-taped spaghetti that becomes intractable. However, we used to more accurately refer to processes and systems not built with maintenance (and all the other ilities) in mind as not well-Engineered. Furthermore, the root cause was likely inadequate understanding of non-functional requirements, design without traceability, bad planning or even the classic POC goes into prod as a POS; most developers understand long term costs of software ownership and, if anything, may over-engineer a solution to be future flexible so I’m not sure I even agree with the Techopedia definition — personally, I have many times added development effort for future flexibility. Pattern overuse and anti-patterns probably contribute more to technical debt than simply code that is easy to implement in the short run.
Obviously, this metaphor is best explored from an Economics and Engineering view. Ultimately, you are trying to build something that optimizes efficiency. In monetary terms, therefore, you want to build software systems (and related processes) such that their total cost of ownership is well below the value they create. And Software Engineers know that mainentance is the longest phase of the software lifecycle so, along with solid verification and validation processes and tests in code to seed lifetime regression, they attempt to reduce the cost of enhancements during products’ maturation by making sound Software design decisions that support component modularity (balancing coupling and cohesion) along an ideal line of Abstractness and Instability.
Consequently, taking this Software Systems Engineering view allows one to realize that any Engineering system will include some intrinsic form of debt — mostly in terms of future cost of maintenance, but also in terms of probabilistic risk (i.e. failures). We strive to design and build systems to minimize both (the so-called technical debt). So, yeah, what exactly do we mean when we freely throw around the term Technical Debt? And why is it bringing new critical focus on some of the most rewarding aspects of being a relevant software developer — researching and building things with emerging frameworks and technologies?
Yes, I get the context of the term to raise awareness that some code just smells and that not all code is equal, especially code produced in haste to meet a deadline. Some code should be, from the beginning, throw-away and we should understand that and not attempt to prolong the use of sub-par code in an effort to meet “Agile” demos that prioritize time to market over long-term resilience. But, is this not avoiding negative NPV? Please don’t tell me to stop all my side fun projects exploring potential solutions because it is Technical Debt; put my accounting hat on and I would classify most fun tech research as technical invesment. One can relate to personal experiences— my one weekend installing slakware in college yielded a far higher return than many semester long college courses.
Living on a small farm complete with dogs, cats, chickens and horses, my family knows the value of waste. In fact, most waste, is in fact, not waste, but valuable resources for future growth (i.e compost).
And now, in an apparent effort to stifle research, exploration, utility, and basic farming methodologies, anything not part of the final production process is deemed Technical Debt? Any code producing endeavor as a potential creation of technical debt is questioned. And this simply highlights the misunderstanding of the mad scientist side of Computer Science and programming — the creative and artistic act of building things applying the latest tools and techniques.
On a recent project, our scrum master actually recognized this aspect of development and felt these exploratory efforts would be better captured as Technical Waste as opposed to Technical Debt (we all acknowleged this code would not be in the final product and was pure R&D). However, I would like to take it one step further and call it Technical Compost. You see, the best software has come from the decomposition of previous projects and code playgrounds, just as our best vegetables grow out of our food/farming waste. As Engineers, we are taught to “throw away” our first solution. In fact, according to Brooks, we should actually avoid the The second-system effect and thus pile several trials onto our compost to enhance the future results. As a farmer, I know the best crops do not come in the first (or even second) season. And as Artists, we learn to evolve, paint over and refactor our doodles into elegant works of art.
So, think carefully before you strive to meet Management’s desire to avoid technical debt and help everyone understand that we are often amassing matter to grow better software in the future. In fact, most developers are like me in that we actually save much of this compost (as non-proprietary doodles) in our repos and gists to jumpstart future products while refactoring using the latest technologies and platforms. Consequently, code compost is actually better than the organic kind because its nutrients don’t degrade as quickly over time!
Happy Software Growing!
