Two (or four) versions of the debt metaphor
Discussing the differences in the two canonical versions of the debt metaphor and some later clarifications from the author.
In his short article The WyCash Portfolio Management System, Ward Cunningham originated the debt metaphor and kicked off studies into technical debt. But among programmers and academics there has been little consensus on the details of technical debt. For instance, the earliest debates surrounded what constituted debt in the first place - is it or is it not a mess, is it cruft? Despite clarifications by the author himself, confusion remained and taxonomies by different authors sprung up to answer this question.
One factor that contributes to the competing accounts of debt is the existence of multiple versions of Cunningham's article. The two main versions are the webpage on Cunningham's website and the published version in the OOPSLA ’92 proceedings. In the various blogs and research articles on the topic of technical debt some authors cite the c2.com website while others cite the OOPSLA ’92 proceedings or sometimes both. Although the published version is much longer, the fact that there are significant differences between the two seems to have gone unnoticed by most readers.
In this post I will discuss what I think is the most important difference between both versions.
The March 1992 webpage
The first version of The WyCash Portfolio Management System, dated March 26th 1992, is possibly Cunningham's original submission to the OOPSLA Conference. It is shorter and less developed than the version that would be later published in the Conference proceedings. Being online, it was likely the most accessible version of the article for many years and could be more widely disseminated than the printed Conference Proceedings. It's also the only version I knew for a few years.
The December 1992 print publication
The text that appears in the OOPSLA'92 proceedings is 30% longer than the more commonly known version on c2.com. The difference in length is mainly due to the inclusion of a new paragraph. In reflecting on the benefits of the team's approach developing WyCash, Cunningham originally posted "We believe this process leads to the most appropriate product in the shortest possible time." But in the proceedings Cunningham detailed the process his team used in accruing and paying down debt. This addition gives much needed context to the metaphorical definition. Cunningham wrote:
Our newly designed objects could coexist with objects of an earlier design allowing us to defer conversion work until later releases ... [t]he ultimate removal of the immature architecture would leave us with a program that had been simplified in the course of adding features--a truly enviable solution.
I had the pleasure of speaking to Cunningham on debt and he described debt as a strategy one adopts and not just a condition of the program. This is an idea that is easy to miss in the original c2 post and even the clarifications Cunningham would give ten years later.
I believe this addition best conveys the idea that debt can be a positive phenomenon - an "enviable" strategy that improves an already good program. It is important to note that most readers overlook this innovative perspective regardless of the version of the article they are familiar with. While this idea is more apparent in published version it would be wrong to say that it is totally absent in the original c2 post. In the c2 post, Cunningham proposed that the team's development strategy, which had allowed debt to be incurred, nonetheless "leads to the most appropriate product in the shortest possible time." This suggests to me that the lack of consensus on technical could not be primarily due to the differences in versions of the source material. I have come to believe that the disagreement is mainly due to resistance to Cunningham's conceptual innovation but that is a discussion for another time.
The 2016 Clarifications
The two versions I have covered so far are the canonical versions that most readers will be able to recognize. I have two unofficial versions that clarify some potentially unclear terminology. I hope presenting these to a wider audience will help readers get to a better understanding of the debt metaphor.
Cunningham would later provide clarifying revisions to the debt metaphor for the Agile Alliance. This version is not the entire text but it concerns the metaphorical definition that most would consider the primary element of the text:
Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.
Both the c2 and published versions included this metaphorical definition unchanged. However, the authors at Agile Alliance revised this famous quote based on feedback from Cunningham. They wrote:
Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with refactoring. The danger occurs when the debt is not repaid. Every minute spent on code that is not quite right for the programming task of the moment counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unfactored implementation, object-oriented or otherwise.
Only the pdf version of the Agile Alliance article provides the explanations for these revisions. Here, refactoring replaced both rewrite and unconsolidated because it is the term one would use today (or then). Additionally, “not-quite-right code” is replaced by a helpful definition - “code that is not quite right for the programming task of the moment.”
I have no reason to doubt that refactoring is what Ward would say today. However, refactoring is a general practice used to erase any manner of ills from a program. So this replacement suppresses the way in which consolidation can describe a particular type of refactoring that targets the unique problem of debt. Ultimately, I do not agree with the erasure of consolidation as it can further the ambiguity that already surrounds debt as a concept.
In my opinion, the best way to incorporate Ward's revisions would have been to keep the original wording and to place clarifying information in the footnotes. This is what I have done. In the process I have created a sort of fourth version which you can view as a Github Gist. I have also expanded the use of footnotes, placing them in the three places in which rewrite and consolidation appear.
I created the gist to mirror the versions covered, so the first version is the c2.com post and each subsequent revision contains the text of the other three versions. In the second revision of the gist I place the Agile Alliance paraphrase into the published article along with the clarifying footnotes. This gives you a way to review their changes in the context of the entire article for the first time.
The Four Versions
The four versions discussed in this article are listed below.
You can also view the versions in version control. Using the revisions tab on the Gist will give you a convenient way to review each version and visualize the differences between them. Go there to check out the differences in full.