Introduction
For this blog post I have elected to use “Technical Debt Quadrant” by Martin Fowler for my blog post of choice. This source was chosen as it directly connects to Design Smells and Technical Debt which was covered in class on September 23.
Why I Chose This Article
I find that this article provides a very detailed way of thinking about technical debt and why it occurs, additionally the article discusses whether technical debt is always a bad thing.
Different Types of Technical Debt
In the blog Fowler explains technical debt using two different distinctions, “prudent vs. reckless” and “deliberate vs. inadvertent”. When you combine all of these you end up with four different categories of technical debt. As an example, a team might deliberately accept some technical debt because releasing the product sooner provides enough value to justify dealing with the problems which may ensue. Adversely, developers might knowingly write poor code simply because they think clean code will take to long to write. Fowler considers this a form of “reckless” debt. Technical debt can also happen unknowingly, especially when the developers don’t know enough to recognize an issue with the design.
This directly relates with what my CS-343 course has covered in class regarding design patterns. In example Strategy, Factory Method, Facade, Template Method, Singleton, and Decorator give us tools for improving designs, but knowing when a design should change still requires judgment and experience.
What Stood Out to Me
Even skilled developers can create technical debt, because their understanding and vision of a project improved while they are building it. A team of people can produce a clean and useful piece of software and only later realize that there was a better way to design it.
This completely changed how I view technical debt, from a face value its easy to associate technical debt with poor programming practices and taking shortcuts.
Applying It
In my future projects (both professional, academic, and personal), I really want to pay more attention to the cost to benefit ratio of fixing “imperfect designs”. I often try to fix things I find imperfect by immediately rewriting it. But in a professional setting (especially with larger projects and code bases), that often doesn’t make all that much sense. I must consider whether or not it provides enough benefit to justify the cost and effort.
Additionally, I want to identify when new knowledge reveals a weakness in an earlier design. Technical debt is not exclusively evidence of making mistakes, but rather can be a sign of growth and improved understanding.
Leave a Reply