I have recently delved into the concept of technical debt through a series of articles, among which this insightful piece by the esteemed Martin Fowler stood out. In his article, Fowler describes the Technical Debt Quadrant and also references the observations of Uncle Bob regarding messy code and its relation to technical debt. These discussions resonated a lot with my own past experiences. Reflecting on these discussions, I've recognized a key concern in my technical leadership career: ensuring that my teams engage in prudent software development.
In recent projects, I've encountered a significant amount of legacy code. The challenge, however, wasn't the legacy code itself but rather its disorganized and messy state. To illustrate that, I encountered methods that spanned thousands of lines of code and files containing literally +5K lines of code — a clear testament to the level of disorder. Unfortunately, the existing engineering culture at that time referred to that mess as "technical debt”. Simply, it was not!
Ward Cunningham, years ago, defined "technical debt" as the necessary engineering trade-offs made to meet pressing business requirements and customer needs, often under tight schedules. There is nothing wrong with assuming suboptimal solutions in order to accelerate product releases. That is part of the game while developing software specially for business purposes. However, a method with 4K lines of code 😨 should never be considered in that category. As the wise Uncle Bob affirmed, "A mess is not a technical debt. A mess is just a mess.”
Technical debt, a part of our ongoing trade-offs in software engineering, should not be an excuse for poor code quality. True technical debt arises from genuine project constraints and should offer a clear benefit for the impending release, entailing reasonable risks and being manageable.
Why Might Teams Write Messy Code?
In my experience, I have observed teams descending into disorder due to two primary factors: irrational decision-making and poor work ethics. Often, the intense pressure of meeting business demands and adhering to tight release schedules can lead teams, especially those with less experience, to abandon rational planning. In their haste, they may end up implementing solutions without proper process or discipline. This approach inevitably results in losses, not just for the team, but for the entire organization.
Poor work ethics is another significant contributor to messy outcomes in software development. Factors like laziness and unprofessionalism are at the core of poor work ethics. Theses factors can be deeply rooted in the culture of the organization by the people building it up. Dealing with this type of challenge extends beyond the scope of engineering techniques. Addressing them effectively requires a cultural shift within the organization, which usually involve replacing individuals who perpetuate these negative behaviors.
Working Towards Clean Technical Debt
To achieve this, technical leaders and managers must empower teams to work on the basis of prudent software development. From Fowler's Technical Debt Quadrant, we can figure that a prudent debt aligns with the concept of technical debts. By deliberating taking a debt, a team should be prudent on whether an earlier release pays off or its costs will be irrationally high. In that sense, the consequences of debts will tend to be wisely beneficial and manageable to pay them down.
Managing Technical Debt Effectively
Effective management of technical debt requires a proactive approach. The first step is to acknowledge and document technical debt as it occurs. This involves keeping a record of where and why compromises are made, and the anticipated impact. Regularly reviewing and prioritizing technical debt during project iterations can help ensure that it doesn't accumulate unchecked. This process allows teams to make informed decisions about when and how to address technical debt.
Additionally, implementing good developemnt practices and standards is crucial. RFCs (Request for Comments), Design reviews, Code reviews, Pair programming, and adherence to design patterns can significantly reduce the introduction of messy code. Such practices also promote knowledge sharing and collective code ownership, which are vital for maintaining code quality over time.
Cultivating Prudent Software Development
Creating a culture of prudent software development involves more than just technical practices; it requires a shift in the engineering mindset. Encourage teams to take a long-term view of their work and understand the future implications of their coding choices. Robust engineering processes like Request for Comments (RFCs) and Architecture Decision Records (ADRs) are essential tools for establishing long-term visions and documenting key decisions, thereby facilitating world-class software development.
Emphasizing the importance of sustainable development and continuous learning can also help cultivate a prudent culture. Investing in training and professional development will equip teams with the hard and soft skills they need to make prudent decisions under pressure.
Moreover, it’s essential to establish an environment where team members feel empowered to voice concerns about potential technical debt. Open communication and a blame-free culture can help in identifying issues early and addressing them before they escalate.
In conclusion, while technical debt is an inherent part of software development, its management is critical. By distinguishing between prudent technical debt and messy code, and fostering a culture that values sustainable and thoughtful development practices, teams can deliver high-quality software that meets business needs without compromising future maintainability and scalability of the entire organization.