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.

Using Innovation Games® With Senior Executives

One question we get a lot is “Do Innovation Games® work with Senior Executives”?

The answer is a resounding yes! A great example of this is engagement I produced for IAM Magazine for its annual conference in 2010. From April 2010 to June 2010, we invited senior executives from a variety of organizations to explore key issues facing Chief Intellectual Property Officers (CIPOs). It’s also a great example of how online collaboration frameworks can work in concert with in-person frameworks to generate truly unique results.

The first part of this project was conducted in April 2010. CIPOs from around the world used Decision Engine and the Innovation Game® collaboration framework Buy a Feature to select the key issues that they wanted to feedback on from CIPO experts during in-person forums scheduled for the IP Business Conference in Munich during June. At the end of the these games, four topics stood out:

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

  • IP strategy in business: Best practices for working with senior management to improve their understanding of the strategic use of IP assets.
  • Improving realisation of IP: How CIPOs demonstrate that well-managed IP programmes can increase corporate market value.
  • Increasing IP licensing revenue: The ways in which CIPOs can help maximise licensing income, and manage expectations of this.
  • Engaging the workforce: Ensuring that the entire workforce is properly educated about and engaged with creating, protecting and leveraging corporate IP assets.


On Sunday,  June 20,  just prior to the start of the IPBC in Munich, a group of CIPOs got together to discuss these topics. I invite you to look at this amazing list of senior executives and thought leaders. The were:

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

  • David Berdan, Invista
  • Joe Beyers of Ambature (formerly at HP)
  • Bill Elkington, Rockwell Collins
  • Paul Fehlner, Novartis
  • Wulf Hoeflich, EADS/Airbus
  • François Jamet, IdVectoR (formerly with France Telecom)
  • Wim Klop, DSM
  • Ruud Peters, Philips
  • Béatrix de Russé, Technicolor (Thomson SA)
  • Andrew Sant, Crown Technology
  • Joseph Villella, Infineon


These CIPOs were joined by eight IP industry experts:

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

  • Jens Bördin, CIP Professional Services
  • Dave Brown, Thomson Reuters
  • Bo Heiden, Qatar Science & Tech Park
  • Michael Lasinski, 284 Partners
  • Ron Laurie, Inflexion Point Strategy
  • Ada Nielsen, LES USA & Canada
  • Ulf Petrusson, CIP
  • David Yurkerwich, Charles River Associates.


The results of this project, including our report, was made public by our client, Joff Wild of IAM Magazine. You can read all about this project and download the report here.

The main point is that these senior executives loved playing the games and produced amazing results. You’ll find that you get similarly great results when you play the games with your executives.