Crappy Code or Crappy Collaboration?

One of the fastest growing memes in the software development community is “Technical Debt.” As outlined by my colleague Martin Fowler in this post:

“Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick-and-dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick-and-dirty design choice.”

An example of Technical Debt would be the result of asking an individual or a team to add some URLs for a website. The “quick and dirty” approach might be to “hard code” the URL, making the resultant system brittle and unusable if the URL changes. The “proper” way to do this might be storing the URL in a database or configuration file that can be easily updated – but the “proper” way definitely takes more time, and in reality the URL may not really change all that much.

Unfortunately, a growing number of technical teams are jumping on the Technical Debt bandwagon in order to get their business leaders to allow them to make desired improvements in their software architecture. More explicitly, these teams do not have Technical Debt. Instead, they have poor collaboration with their business counterparts — and that lack of collaboration is forcing them to “scare” their business leaders by asserting they have massive technical debt.

I tackled this topic in my Agile 2015 keynote when I discussed how organizations should tackle wicked problems. Briefly, the wrong way to tackle a wicked problem is to identify a single option that the group accepts or rejects. In the case of Technical Debt, the wrong approach is to assume that you have to rewrite your system — which most developers will advocate, especially when collaboration with the business is poor.

The right approach to tackling a wicked problem is deliberation, a process in which a group of people evaluate between three and four strategies for tackling a problem, the actions associated with each strategy, and the inherent drawbacks of these actions. Does this mean that sometimes rewriting the system is the right option. Sure – but only after you’ve actually considered options!

To illustrate, let’s consider options, actions and drawbacks for tackling Technical Debt.

[separator type=’transparent’ color=” thickness=’1′ up=’-1′ down=”]

Option 1: Total Rewrite

This is the option that is (often forcefully) advocated by developers: “The system has so much Technical Debt that we must totally rewrite it!” An inherent drawback of this option is that investing in a total rewrite means NOT investing in new features or serving existing customers. But to move beyond a trivial review of the option and its inherent drawback, we need consider specific actions and drawbacks. (In the framework we use for deliberation, there are typically 5 to 7 action-drawback pairs for an option, and you’d need to tailor these for your situation).

[unordered_list style=’circle’ animate=’no’]

  • Action: Change the technology we’re using in the rewrite. Drawback: Our developers don’t have experience in the new technology, training is expensive, and it introduces unnecessary risks.
  • Action: Do not make changes to the existing platform so that developers can focus. Drawback: Customers may defect, and bugs will not simply vanish.
  • Action: Increase budget and let 3rd-party developers handle bugs and new features. Drawback: This will further depress our ability to invest in new products and our existing developers will have to manage questions from the 3rd-party developers.


Hmmm… Isn’t it interesting that once you consider the drawbacks of the actions required to implement an option, the option often becomes less appealing? That’s not a negative; that’s a positive, because it should also motivate you to consider another option.

[separator type=’transparent’ color=” thickness=’1′ up=’-1′ down=”]

Option 2: Purchase Software

Once the organization considers a total rewrite as a potential option, the business team will quite naturally suggest that the organization get out of the business of writing software altogether and simply purchase a system. An inherent drawback of this option is the loss of control and inability to tailor the software to meet the specific needs of the business. Let’s review some potential actions and drawbacks for this approach.

[unordered_list style=’circle’ animate=’no’]

  • Action: Develop a list of requirements for selecting a vendor. Drawback: Developing requirements for existing systems is time-consuming and often results in “forgotten” requirements.
  • Action: Identify and evaluate software vendor offers. Drawback: Evaluation of a vendor is costly and may require undesirable workflow changes.
  • Action: Implement the new system. Drawback: We’ll have to train users on the new system.


What’s curious about Option 2 is that it is usually similar but “opposite” to Option 1. In both cases, the options involve addressing the Technical Debt through standard mechanisms. The key to creating a really powerful choice isn’t just saying yes or no to one option, or simply considering two options that are opposite. The key to deliberation is to make sure that there is at least one additional option that helps us consider the problem we’re facing from an entirely different perspective; a perspective that sheds meaningful insight into the true root cause of the problem.

Option 3: Improve Collaboration Through Roadmaps

My experience is that a lot of what is called “Technical Debt” is really a lack of effective collaboration between business leaders and their technical counterparts. Eventually, the lack of collaboration creates schisms that can become unsolvable, with developers clinging to their belief that a total rewrite is required to get what they want, while business leaders scheme to replace those frustrating engineers with an outside vendor.

An alternative to rewriting a system or buying software would be to develop a collaborative roadmap. (You can find my pattern language for product roadmapping from my book Beyond Software Architecture here). By learning how to collaborate more effectively, business and technical leaders can manage the strategic evolution of their solution and identify the backlog items that authorize the work necessary to implement it.

Let’s review some potential actions and drawbacks for this approach.

[unordered_list style=’circle’ animate=’no’]

  • Action: Develop a collaborative roadmap. Drawback #1: Our positions may be so entrenched that we’re not willing to engage in the hard work needed to build an effective roadmap. Drawback #2: Our Agile method says that all we need is a backlog; introducing a roadmap will require us to change our method.
  • Action: Identify the right participants for this process. Drawback: The right participants may not have the perceived title or seniority; therefore, their opinions and insights will not be accepted.


Collaboration Over Crappy Code

The deliberative process that I outlined above exposes the actions and drawbacks behind each potential solution. There may be others in your individual situation. Regardless, I hope this post has got you thinking about the real challenges that exist in identifying and managing Technical Debt — and whether you really have as much crappy code as you think, or more crappy collaboration than you’d like.