The Agile Executive

Making Agile Work

Round Two: Can Technical Debt Constitute a Breach of Implied Warranties?

with 2 comments

In a previous post I discussed whether technical debt could under some conditions constitute a breach of implied warranties. Examining the subject with respect to intent, I made the following observation:

It is a little tricky (though not impossible – see Using Credit limits to Constrain Development on Margin) to define the precise point where technical debt becomes “unmanaged.” One needs to walk a fine line between technical/methodical incompetence and resource availability to determine technical fraud. For example, if your code has 35% coverage, is it or is not unmanaged? Does the answer to this question change if your cyclomatic complexity per class exceeds 30? I would think the courts might be divided for a very long time on the question when does hidden technical debt represent a fraudulent misrepresentation.

One component  of technical debt deserves special attention in the context of this post. I am referring to the conscious decision not to do unit testing at all… Such a conscious decision IMHO indicates no intention to pay back this category of technical debt – unit test coverage. It is therefore quite incompatible with the nature of an implied warranty:

Responses to my post were mixed. Various readers who are much more knowledgeable in the law than I am pointed out various legal defenses a software vendor could use. Click here for a deeper understanding of these subtle legal points.

Imagine my delight reading yesterday’s uTest interview with Cem Kaner. Cem makes the following statement in his interview:

ALI [American Law Institute] … started writing the Principles of the Law of Software Contracts. One of its most important rules is one that I advocated: a seller of software who knows about a defect of the software but does not disclose the defect to the customer will be held liable for damages caused to that customer by that defect. Note that this does not apply to free software (not sold). And if the seller discloses the defect, it becomes part of the product’s specification (it’s a feature). And if the seller doesn’t know about the defect there is no liability (once customers tell you about a defect, you have knowledge, so you cannot avoid knowledge for long by not testing). ALI adopted it unanimously last year. This is not law, but until the legislatures pass statutes, the Principles will be an important guide for judges. Even though I am a minor contributor to this work, I think the defect-disclosure requirement might be my career’s most important contribution to software quality. [Highlights by IG].

While not (yet?) a law, the Principles could indeed lead us where IMHO we as an industry should be. Technical debt manifests itself as bugs. By making the specific bugs part of the spec the software evolves from a quality standpoint. Moreover, the defect-disclosure requirement practically force software vendors to address their bugs within a “reasonable” amount of time. Customer bugs become an antidote to the relentless pressure to add functions and features without paying due attention to software quality.

I guess I missed the opportunity to include technical debt in the 2010 revision of the Principles. As we always do in software, I will target the next rev…


2 Responses

Subscribe to comments with RSS.

  1. This is a good series of posts. You can write anything into a contract. And – if it is written into a contract as an explicit warranty, it is then not implied. Most commercial agreements will specifically disclaim implied warranties. In fact, it would be quite foolish for a company to not disclaim such responsibility.

    It’s all a very interesting concept that may provide incentives to improve quality. To be effective however, I believe that such terms would need to be specified in a contract. Further, there would need to be a precise meaning of what is “Technical Debt” and how such debt is accrued.

    John Petersen

    July 29, 2010 at 1:13 pm

    • Thanks for the kind words, John!

      I will certainly defer to you on the contractual aspects. With respect to the technical aspects, the term “technical Debt” is broadly accepted as a metric for intrinsic quality (or lack thereof). Various tools are available to calculate technical debt based on the cost structure of the project. I routinely do technical debt assessments through the Cutter Consortium.




      July 29, 2010 at 7:27 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: