Tag Archives: technical debt

Is technical debt the right financial analogy?

Posted on by
Reply

The concept of technical debt has been well-known in computing for many years. It has been the subject of research by practitioners and academics. It’s been chewed over pretty well. But my CTO recently shared an article that suggests debt is a poor model for bad code.

Steve Freeman proposes hedging options as a better model. Debt is too structured and predictable. Call options are inherently unpredictable. Debt will accrue at a defined rate and you can figure out (assuming an accurate model) what payments will look like. Options can be ultimately profitable or ruinous.

Freeman’s analogy makes a lot of sense. It’s probably truer to reality than the more simple debt model. But as the excellent comments on that post pointed out, it’s less approachable to people without a background in finance (which is probably most IT managers and even more developers/admins/etc). Technically correct is the best kind of correct, but there’s a lot to be said for being understood.

Quantifying the cost of bad code remains a challenge, particularly when the badness is situational. So whatever gets people thinking about the longer-term consequences of design and implementation is a good model.

Impact of license selection on open source software quality

Posted on by
Reply

I’ve made several vague references to my master’s thesis on this blog, but I’ve never said much of substance. Your long wait is over though, as I’ve finally gotten around to uploading it and creating a research page on the website. If you don’t want to read the full thesis, there’s a condensed version that was presented at a conference in March (and won best paper in the session, I might add).

The even more condensed version is that my research shows (to my dismay) that copyleft projects tend to have higher technical debt than permissively-licensed projects. What’s more interesting than the results is the pile of questions that it brings up.

I’ll admit that my methods are not necessarily the most stringent, particularly when it comes to how quality is proxied (or even the quantification of technical debt). My methodology was partly driven by convenience and partly driven by the dearth of research available on the topic. Of course, the steep price of the C/C++ plugin hampered my ability to get a good sample.

I hope someone else picks up where I left off and does a more detailed analysis. For my own part, I hope to be able to conduct some research in my “spare time”. In addition to the mere study of differences in debt, I’d like to see how non-license project governance affects software quality. There was no analysis in my study of developer quantity, funding, etc. The ultimate goal is to develop concrete recommendations for FLOSS project leaders that would improve the quality of the finished product.

 

Product debt

Posted on by
Reply

I’ve spent a lot of time in the past two years researching and thinking about technical debt. In most of that time, I’ve thought about it as something that’s an implementation detail of the code. It’s probably fair to keep it defined to that context, but that leaves a lot of places for debt to be introduced before any code is ever written.

A recent post on the Instigator Blog discussed the concept of “product debt” (also referred to “design debt” or “user experience debt”). One of the key indicators of this sort of debt are differences between, for examples, different forms within a product. I’d argue that the ability to reuse documentation between products (e.g. installation instructions) is an inverse measure of debt.

The post is a great introduction to the concept, but as I re-read it, I realized that I didn’t like using the term “product debt” for what the author describes. Most of the discussion is around user experience design. While UX is obviously very important to successful products, it’s not the only consideration. Similarly, there are other kinds of design apart from UX design.

I have given the matter some thought, and I’ve come up with the start of a taxonomy for debt. “Why create a taxonomy?” you may ask. Firstly, because if we can use a common vocabulary, we can communicate more clearly with each other. Secondly, because having a way to categorize debt can allow project/product managers to manage debt payment. Finally, it could be a launching point for academic studies of debt in order to better guide the debt payments in the second point.

So here’s a first draft of a debt taxonomy. The categories below are all components of a total product debt.

  • Technical debt. This is the debt that occurs in your code as implementation details.
  • Architecture debt. This is the debt you incur from design decisions, including the API.
  • User experience debt. This debt is basically the debt described by to in the linked post.
  • Documentation debt. This debt accrues when your documentation is missing, incorrect, or unreadable.