Emerging from Hibernation on the 4th of April

I always wanted to reach the top page of HackerNews with this blog. It’s one of my favourite sites, full of amazing articles, a variety of viewpoints, and intelligent commentary (most of the time anyway). So, to my delight and friend’s surprise/horror, my last blog post reached number 2 on HackerNews, and stayed on the front page for a whole day. The article (here and HN link here) explains why no-one really understands Technical Debt, and is co-authored with the wonderful Paidi O’Reilly and Stephen McCarthy at UCC. We had 20,000 reads, hundreds of comments across multiple platforms, and Grady Booch introduced me to Philip Kruchten on Twitter. Let me rephrase, the guy who gave OO programming its name introduced me to the guy who invented 4+1 Architectural views. I felt like I was joining an exclusive blogging club. Heady times indeed.

To capitalise on this success, I posted nothing for nine months. Life became busy (I had Covid among other things), work became busy, so the usual 5% of the time I spend on writing, running and listening to music became 0.5% for a while. One reason work was so busy, Workhuman is becoming more successful almost every month. We officially became a tech unicorn (a private company valued at over 1 billion dollars) last year. This means that we are recruiting, building new teams and delivering product at record rates, so less time for my typed brain debris. If you are interested in joining us, have a look here. We have on-site, hybrid and fully remote roles. We also always seem to have loads of cake. Just saying.

That said, a paper that Paidi, Stephen and I wrote last spring and summer got published at the HICSS conference in January 2022. I will emerge from hibernation on Monday the 4th of April to talk about our paper, at a Cork University Business School conference.

The paper is here, and discusses the link between Technical Debt, social unrest and the environment. I would love to hear any feedback or suggestions for future research. You can register for the conference here. It’s free and features an outstanding lineup (and me):

  • Alan D Duncan – Gartner Distinguished Vice President
  • Gar Mac Críosta – Chairperson, Public Health Advisory Committee at Linux Foundation Public Health
  • Ken Russell – Principal – Ericsson Global Digital Transformation Office
  • Ruairi O’Callaghan – Director – Global Command Center at Pfizer
  • Sharon Jones – Director, Kee Jones Ltd

Technical Debt Is Not Debt; It’s Not Even Technical

Co-authored with Dr Paidi O’Raghallaigh and Dr Stephen McCarthy at Cork University Business School as part of my PhD studies, and originally published by Cutter Consortium’s Business Agility & Software Engineering Excellence practice on 22nd of July 2021

Take a minute and write an answer to the question, “What is technical debt?” Then read this article and reread your answer — and see if it still makes sense.

Technical debt is a common term in technology departments at every company where we’ve worked. Nobody explained technical debt; we assumed it was a fundamental property of the work. We never questioned our understanding of it until we discovered a paper by Edith Tom et al. entitled “An Exploration of Technical Debt.” Turns out, we didn’t understand it at all.

Now, one major concern in academia is rigor. Academics like to get deep into a topic, examine the nuances, and bring clarity. After thoroughly reviewing more than 100 seminal papers on technical debt, we saw it as an amorphous ghost, with enormous differences and inconsistencies in its use. Next, we began looking at it in practice, asking colleagues, ex-colleagues, and working technologists, but couldn’t find a satisfactory explanation for it there either. Ultimately, we went back to the original source to figure out the history — and get a sense of its evolution.

One thing that is agreed on: the term technical debt came from Ward Cunningham. Cunningham is the inventor of the wiki and a tech legend. In the early 1990s, his team was building a piece of financial software, and he used a metaphor from the world of finance to explain to his manager how the team was working. As he later explained in a paper at the OOPSLA conference in 1992:

A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.

The metaphor quickly became part of standard technology discourse. Because the conference focused on object-oriented development, it took hold in that community. Popular tech authors such as Martin Fowler and Steve McConnell soon took it on, helping it become part of the broader language in software development. Today, the use of “technical debt” has become commonplace, from a mention in a single paper in 1992 to over 320 million results from a Google search as of July 2021.

Over time, Cunningham saw the term shift to signify taking a shortcut to achieve a goal more quickly, while intending to do a better job in the future. In 2009, dissatisfied with how the metaphor had mutated, he clarified the use of technical debt in a YouTube video. Cunningham disliked the notion that technical debt signified “doing a poor job now and a better one later.” This was never his intention. He stated:

I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem, even if that understanding is partial.

But it was too late. By that time, the metaphor had outgrown his initial intent. It was out in the wild, excusing terrible decisions all over the globe. Technical debt now represented both debt taken on intentionally and the more insidious form, hidden or unintentional debt — debt taken on without the knowledge of the team. It had also moved past code and spread to areas as varied as technology architecture, infrastructure, documentation, testing, versioning, build, and usability.

Technical debt allows practitioners to look at tech delivery through the lens of debt. Is this an appropriate lens? Debt repayment has one vital characteristic: it is easy to understand. Debt repayment has three properties that are straightforward to grasp — principal amount, interest rate, and term (i.e., length of time to repay). But when comparing technical debt, there is no agreement on the principal, no agreement on the sum owed. There is no concept of an interest rate for technical debt because technologists individually evaluate each project as a unique artifact. Finally, term length isn’t a fixed concept in technical debt — in fact, Klaus Schmid even argues that future development should be part of the evaluation of technical debt.

Enormous effort and energy have gone into trying to calculate an accurate number for technical debt across many technology and academic departments. Unfortunately, trying to glue a direct mathematical representation to a metaphor seems to have failed. The idea of technical debt as a type of debt doesn’t hold up well in this light.

So is it technical? This depends on whether we consider only the originating action, or the consequences that follow. If an aggressor punches a bystander in the face, we consider not only the action of the aggressor (the originating action) but also the injury to the bystander (the impact of that originating action). Through this lens, technical debt can only be technical if we consider where it originates, as opposed to where it has an impact. Technologists take on the originating action; the business suffers the impacts of those decisions. Technical debt affects:

  • Competitiveness by slowing/speeding up new product development
  • Costs (short-term decrease/long-term increases in development cycles)
  • Customer satisfaction
  • Whether a company can survive

Once we realize that technical debt is a company-wide concern, we can no longer consider it technical, this label is too narrow and doesn’t communicate its significance. In fact, our current ongoing research shows that technical debt may even have an impact beyond the company, and we need to take an even broader view (its effect on society as one example). 

The most important takeaway: we must broaden our awareness of technical debt. In the same way that company executives examine financial cash flows and sales pipelines, we must communicate the consequences of taking on technical debt to this audience. Our most important challenge is to find a shared language to help business stakeholders understand the importance of unknown decisions made in technology departments.

Finally, look back at how you defined technical debt at the beginning of this article. Do you communicate the action or the impact? Is it suitable for a business audience? What is?

If you enjoyed this article, please share it with three people who would appreciate it.

You may also enjoy this article on how technologists make decisions

If you would like to work in Workhuman with talented people on some of the most interesting challenges in technology and society, please contact me, or browse open roles here.

Thank you so much, Mark.

Conference Slides from the UCC Technical Debt presentation

I was delighted to present at the Information Systems Mini-Conference in UCC on Friday the 19th of June 2020. My research is concerned with Technical Debt and its impact on an organisation.

It was hosted by Cork University Business School and the Fantastic Dr. Paidi O’Reilly, with presentations from Dr Stephen McCarthy, Elaine Beare, Michael Twomey, Kieran O’Driscoll, Bernard Swierczyna, Kenneth Russell, and Keith Burton.

If you should like to discuss my research, technical debt or technology at workhuman, please get in touch via the contact form, Twitter or LinkedIn (preferably) here.