If you’re reading this, you have probably ended up in a stranglehold of a mountain of seemingly-insurmountable “technical debt” at some point or another in your career. And you are probably also wondering if I have some magic recipe to extricate it from your future?!?
Or maybe you, like me, have, once again, run into the wall of resistance when you want to address a structural mess that’s makes everything you do more time-consuming than it should be. Maybe you inherited it? Maybe you wrote it? Maybe you have been building this house of cards for months — or even years — as you’re pressured into delivering features in less time than you really need to do them justice…
Whatever the backstory is, you’re in a slump, and “un-slumping yourself is not easily done.” (Thanks to Andy Brandt for identifying these categories.)
What defines the quality of a product? (Functional vs Structural)
In the end, we are all concerned with quality. Although, the quality of any product a company produces, consists of two major domains, functional and structural quality.
Functional Quality
Functional quality is a measure of how well a product does everything it is supposed to do and doesn’t do what it is not supposed to do. Pretty straightforward, right? This form of quality can be quantified and qualified by using standard system testing by developers, QA personnel, and even customers. Therefore, this is is largely how a product is gauged to be in a releasable state, within most organizations.
Structural Quality
Structural quality is a measure of how well a product is built, including the durability of the pieces that make up the product. Unfortunately, structural quality is not so easily assessed by the layman, and many times is neither directly visible nor fully quantifiable by the same methods and personnel that performs the functional quality assessment… No matter how much effort is spent. These structural deficiencies generally require experts in the technology and/or materials used in creating the product.
In the heat of the battle of product development, the experts are largely confined to the creation and resolution of defects. Therefore, their input into the overall quantification of quality is either non-existent or ignored.
Why should I care about structural quality? (A simple analogy.)
Let’s take the example of building a house. We know that the first step in building a house is having a plan/blueprint. Creation of the plan, when done correctly, takes construction regulations and best-practices into account. Some notable considerations are: type/quality of materials being used, the flow of one room to the next, and most importantly, the foundation. The foundation must be able to bear the weight and effects of the elements that will burden the structure over the years.
Furthermore, in order to keep the elements out and protect the enclosure, the materials that provide this isolation must be of sufficient quality and also used in a proper manner to ensure that enclosure not only keeps the elements from penetrating the structure, but that they also have the durability to allow the home to survive the years of wear and tear that will ensue.
If shortcuts are taken, the consequences may very well not be apparent to the homeowner during or even after construction is complete. But as the months and years pass, the shortcuts that were taken to save cost and/or time will most inevitably lead to leaks, sagging floors, cracks in walls and ceilings, etc. At this point, fixing these problems may be nearly impossible and will ultimately cost much more to fix than if they were done properly during the initial assembly. Therefore, it more than pays for itself to do it right the first time.
How does structural quality apply to software? And why should I care?
Poorly-structured software can have various undesirable aspects. If written poorly, it can be very hard to read and understand. Consequently, it will be very difficult, time-consuming, aggravating and risky to make changes that add more features (or even fix bugs) until the structural aspects are resolved.
Over the course of time, and as a poorly maintained codebase grows and new features are added, increasing amounts of time are spent on hacking changes into the system while trying to avoid the cobwebs and roadblocks (technical debt) that’s built up. The cost of change rises exponentially as the accrued structural defects continue to hinder development and lead to less-than-ideal solutions to new problems, which fuels this trend forward — sometimes to the detriment or outright failure of a product in the marketplace.
What can we do?!?
When starting the development of a new product, or maybe even a full on rewrite, always be mindful of not just making things work, but also making them maintainable. Taking pride in your work — and doing it right — will give you the fuel to maintain the health of a product in the long-term. Clarify expectations up front on creating and maintaining a healthy and robust codebase. You won’t always do things right the first time, but when you run across code smells that get in your way, refactor them out of existence.
Fostering this attitude of maintaining structural quality across your entire development team or organization will have very significant paybacks. The paybacks not only come in the form of a healthy revenue stream, but also a healthy development culture. These paybacks make us all feel good and inspire us to do more good and be creative, which leads to innovation and long-term success of the company as a whole.