Media Query Source: Part 21
The responses I provided to a media outlet on December 4, 2019:
Media: Technical debt is the added cost that's incurred when software is developed quickly with little or no regard to quality and must be reworked to reach its intended objectives. Looking for experts who can answer some or all of the following questions:
1. Why is technical debt bad?
2. What is an effective method for reducing technical debt without killing operations?
3. What's the best way to plan a software project that ensures technical debt is either minimized or eliminated?
4. Is there ever a time when technical debt is actually useful?
Gfesser: Absolutely. As such, the definition of technical debt provided for this media query ("the added cost that's incurred when software is developed quickly with little or no regard to quality and must be reworked to reach its intended objectives") can be a bit of a misnomer, depending on the audience.
I've often used the incurring of technical debt as a strategy in order to develop code that fulfills application needs from a functional perspective, knowing that it will need to be revisited for refactoring for a variety of reasons. For example, code may not be fully configurable with respect to environment differences or user needs, or fully enabling DevOps processes. But the lack of these code attributes doesn't mean the code is functionally incorrect.
When developers use this strategy, it does not mean that they have low regard to quality. In fact, code should ideally be written in a way which permits the addition of these missing attributes at a later point, meaning that even though technical debt is being incurred, it doesn't mean that code quality is bad. This just means that some attributes of the code will be worked in at a later point.
The danger of using this strategy, however, is that not all stakeholders will understand how it works, or the implications of making use of it. For example, business stakeholders with minimal technology backgrounds may not understand that just because an application is functionally correct that it may not necessarily be an ideal foundation on which to add additional code down the road.
One key implication in using this strategy is that technical debt needs to be periodically addressed, and cannot be forgotten about or consistently deprioritized by stakeholders over a lengthy period of time, since the more time which passes before it is addressed can often lead to greater challenges as the code base can increase in complexity in the meantime.
It's a good idea to schedule either the periodic tackling of technical debt, say every X number of Sprints, or schedule around a particular release schedule. I've often, for example, knowingly incurred technical debt prior to the release of an MVP (minimum viable product), only to schedule the tackling of technical debt in an incremental manner that coincides with either the MVP or a release shortly following up to it.
Another example is the postponement of addressing application performance. I've followed the philosophy of Donald Knuth that "Premature optimization is the root of all evil", because spending too much time on performance improvement before an application is actually used (or before application usage is known) deviates valuable time that could otherwise be spent on functional correctness.
With respect to some application aspects such as performance, it's important to understand that while the architecture of a given application or system can evolve, in order to minimize disruption it is imperative to choose an architecture which can evolve well. So with respect to performance, for example, while the development team may not know how much data might be processed down the road, the architecture should be able to scale well in order to prevent ripple effects in the code, or worst case, a completely new architecture within a relatively short period of time.
5. Is there anything else you would like to add?
See all of my responses to media queries here.