Can Technical Debt Constitute a Breach of Implied Warranties?
Photo credit: Dancing Lemur (Flickr)
Cunningham’s quip “A little debt speeds development so long as it is paid back promptly with a rewrite” is intuitively very clear. We are talking about short-term debt which will be reduced, and hopefully eliminated in entirety, at the earliest possible time.
The question this post addresses is what happens when the expected short-term technical debt becomes a significant long-term debt? Specifically, can technical debt under some conditions constitute a breach of implied warranties?
In his InformIT article Don’t “Enron” Your Software Project, Aaron Erickson coined the term “Technical Fraud” and connected it to Lemmon Laws:
As a reaction to seeing this condition and its deleterious effects, I coined the term technical fraud to refer to the practice of incurring unmanaged and hidden technical debt. Many U.S. states have “lemon laws” that make it illegal to knowingly sell someone a car that has undisclosed maintenance problems. Selling a “lemon” is a fraudulent practice in the world of cars, and it should be considered as such in the world of software.
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.
Best I understand it, the rationale for not “bothering” with unit testing is a variant of the old ploy “we do not have time for testing here.” It is a resource allocation strategy that bets on the code being miraculously bug-free. Some amount of functional testing is done out of necessity – the code in customers hands needs to function as proclaimed. But, the pieces of code from which functionality is constructed are not subject to direct rigorous testing. The individual units of code will be indirectly exercised in some manner through functional testing, but not in a systemic manner to verify and validate correctness of the units of code per se.
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:
An implied warranty is as an unstated promise, assumed by the law in most sales transactions, that the product will be of at least average quality and will do what the average customer would expect it to do [The Reader’s Digest Legal Questions & Answers Book]
To #1 defense open to a software vendor who gets sued over lack of unit testing is that a fair average quality of software can be attained without any unit testing. As a programmer, I would think such defense would fly at the teeth of the availability since 1987 of the IEEE Standard for Software Unit Testing.
It is fascinating to note the duality between contracts and programming. For the programmer who follows the tenets of design by contract, “a unit test provides a strict, written contract that the piece of code must satisfy…”
Disclaimer: I am not an expert in the law. The opinion expressed in this post merely represents my layman’s understanding of principles of contract law that might be applicable to technical debt situations.
The Agile Executive 
Interesting post. I am both a lawyer and a software developer.
To answer the question of whether implied warranties can be or are breached, you must first address the question of whether implied warranties apply in the first place.
Implied warranties are typically found in the context of the UCC – the sale of goods. You go to the store purchase a product – and per the UCC (Uniform Commercial Code) – there will be an implied warranty of merchantability, and in some cases, an implied warranty for fitness for a particular use. If I tell the vendor that I am going to use this product for a specific purpose, both implied warranties will apply.
These implied warranties are necessary because in most cases, there is no writing to evidence a contract between the buyer and seller. Such written contracts would be impractical in commerce.
These warranties cannot be disclaimed.
These implied warranties are to be differentiated from express warranties – those warranties that are expressly stated in writing.
In the software development context, we are not talking about the sales of goods. As such, it is highly unlikely that implied warranties would apply. Most engagements are covered by a contract. And typically, such contracts have integration clauses that incorporate all previous discussions, writings, etc into the 4 corners of the contract. Also, contracts typically have language that disclaim warranties, express and/or implied.
When you cite the IEEE standard, you are actually bringing a standard of care to the discussion. And this brings up the notion of negligence. To not follow a standard of care, in other words, to deviate from what the reasonably prudent developer would do, is to arise to a breach. And in the event of such breach, the question then turns to whether there are any damages that are factually and/or legally caused by such breach. If there is, there can be liability. This gets to why developers should be careful about what they ask for re: being a profession. Professions, whether it is the law, medicine, engineering, etc – have promulgated standards care. To violate those standards is to commit an act of malpractice.
Again, great post.
John Petersen
April 7, 2010 at 7:56 am
My contention is that implied warranties could indeed be applied to software. I don’t know that applicability will be established before we have some court rulings on the subject. However, I would think it would be quite straightforward in numerous cases. For example, when the technical debt is $10 per line of code…
Best,
Israel
israelgat
April 7, 2010 at 9:54 am
I certainly wouldn’t put it past some judge, out of a sense that equity would demand it, to impute an implied warranties. That said, the problem is averted by simply having a provision that disclaims any implied warranty.
Often times, clients assume the risk of technical debt. They want something right away. Very often, we advise against those quick solutions that run the risk of incur tech debt. In those cases, there are strong arguments that cut against an implied warranty as the client got precisely what was bargained for.
Again, great discussion and great post by you!! Thanks. I look forward to reading your posts.
John Petersen
April 7, 2010 at 3:42 pm
John, thanks for the explanation and the very kind words!
I am not certain on the exact tactics that will lead to the evolution of a legal doctrine around technical debt – I am a novice on such matters. I would, however, speculate it could be done through some combination of legal and operational levers. For example:
My understanding of disclaimer on implied warranties is that the exclusion must include words such as “with all its faults.” Hence, I would think a company with a lot of buying clout could use a 1-2-3 strategy:
1. Negotiate a contract that does not contain such an explicit disclaimer. It could be embarrassing like hell for a software vendor to insist on “with all its faults” language in a negotiated contract that supposedly is fair and balanced.
2. Ask the software vendor for detailed technical debt data.
3. If the software vendor does not provide the technical debt data or the data indicates severe quality deficiencies, advise the vendor legal remedies will be sought.
To put it in other words. It would be extremely difficult for the courts to make a decision based on a metric such as Lack of Cohesion Among Methods (LCOM). However, everyone can understand and relate to “debt” expressed as $$ per line of code. Moreover, numerous non-technical folks can understand the intentionality when a software vendor has no unit tests whatsoever. Intuitively speaking, the case is strong.
Your thoughts?!
Israel
israelgat
April 7, 2010 at 4:23 pm
At the end of the day, it boils down to contract law. In the US, courts are loathe to step in and re-write contracts. Contracts after all, are private things – between parties. In the software dev context, we are typically talking about business on both sides.
If however, this notion of an implied warranty on tech debt could become a trade usage – and standard industry practice if you will – then perhaps it could be a standard part of dealing. As a developer, I would not be in favor of such a thing as it leaves open the question of precisely what is tech debt and how it should be quantified. Would those be questions of fact or law? This goes to your point about it being difficult for courts to decide such matters.
At the end of the day, it will be up to people to deal with it on a contract by contract basis.
John Petersen
April 8, 2010 at 1:38 pm
I would say the state of the art enables us to put our hands around technical debt in a rigorous manner. See, for example, Analysing Software Repositories to Understand Software Evolution by D’Ambros etc al in Software Evolution by Mens and Demeyer (editors).
Israel
israelgat
April 8, 2010 at 2:11 pm
The client who “just wants it to work” is bound to see the risks of technical debt differently from a developer with a “problem-solving” personality. So, we expose it and then manage it.
I wholeheartedly agree that “technical debt,” “backlog/wip” can be well-defined and *should* be within the context of the developer’s explained process. This allows us to also define work that simply won’t get done and to distinguish it from “technical debt,” which I would argue should be limited (legally) to work that *ought* to be done, not just cleaner code that is “nice to have.”
An ecosystem approach would recognize that refactoring will be necessary to ensure that code is more robust (adaptive). This might require the development team to integrate special teams as a matter of economic sense and clients must be made to understand this. It’s also a strong argument for ensuring that the team has a good mix of experienced (lazy?) developers and the Jolt crowd. Solid code with a boring presentation can always be prettified by a competent interface designer.
Nor do we really have to worry about “take the money and run” judgment proof developers: quality in an Agile environment means a fair amount of transparency. It’s hard to hide lack of infrastructure if the client can see that you’ve got 5 developers “pair programming” around 2 workstations.
One concept I’m thinking about is the customer as “short-term-investor” or “limited liability partner” in a stretch of code. The idea is an offshoot of the work Black Duck is doing in open source tracking. Seems to me that in an object-oriented world, we might be able to make this happen, such that clients have a vested interest in code development,–without the ability to tell the team how tasks are done. This might work well for smaller developers and “freemium” type projects.
Regina Mullen
April 16, 2010 at 10:17 am
Regina, “short-term-investor” is an intriguing idea. Do you consider it applicable to enterprise software? If so, how?
Many thanks,
Israel
israelgat
April 16, 2010 at 11:29 am
This is a very interesting idea. At the very least it highlights the longer term cost of allowing technical debt to accrue. I consistently see organisations that “don’t have time to test”. Our “shareholder value” business systems results in quarterly earnings myopia which in turn results in short term decisions not to invest in keeping technical debt down.
Until people take this seriously, software will continue to be brittle and full of bugs. Considering that the average family car now has embedded software well into the millions of lines of code, the sad state of the industry is going to have serious consequences if we don’t do something about it.
Dave Rooney
April 7, 2010 at 7:34 pm
The beauty of expressing technical debt in $$ terms is that it provides a metric which is easily understandable by non-technical folks. Stakeholders should be able to relate to something like “a debt of $10 per line of code.” If we are discussing a code base of 500K lines of code, all a stakeholder needs to do is to compare $5M (500K X 10) with whatever value he/she places on the code.
With respect to the legal aspect, I would like to think the availability of a $$ metric should make it possible to develop a legal doctrine around technical debt. Experts could debate coupling and cohesion in court till they are blue in the face. $$, however, are well understood and often reverted to in the legal system.
Israel
israelgat
April 7, 2010 at 7:54 pm
Rambles a bit, but here are some preliminary thoughts:
I don’t see “technical debt” (without more) as a legal concern, provided the process is transparent to the client. We always ask,”Did the customer get what he bargained for?” If the developer can answer “yes,” there’s no liability. This is why the wise developer will not only put periods of refactoring and testing on the table during negotiations, but push to have them explicitly written into the development contract. There’s no reason to hide quality control in the price.
Of course, there is a threshold that implicates competency…but the iterative approach of Scrum, for example, bakes in the idea of making sure the client is receiving VALUE iteratively. This is why everyone in the enterprise needs to understand how the team delivers *value*. We have to be clear, though, that using “value” as a deliverable is very different from both “functionality” AND “lines of code” approaches. It needs to be well-defined and clearly stated. Easy? Not at all, but it can be done, provided the client is fully informed.
If the core metric that needs definition is “value,” it may be dangerous to try to define technical debt in terms of lines of code…how can it be reduced to a number when one line of code could account for 90% of the “debt weight”? It would be useful from a damages perspective, but that’s a post-liability consideration. It’s a much better position to explain to a magistrate that your customer signed off on 16 consecutive weeks of demonstrated and bargained for value over a 20-week project.
It’s naive to expect full client participation, but some sort of proxy is absolutely critical. For example, there are quite a few mature Agile project management tools,–do they have client interfaces? Why or why not? With multiple layers of protection, it’s pretty easy to defeat the argument of “you didn’t tell us in time!” using an Agile development model. Further, an Agile contract ought, by definition, be flexible enough for the client to define “value” iteratively as well. A very un-touchy-feely reason to build relationships first and contracts second.
Of course, we deal everyday with software that couldn’t possibly be “fit” for ANY useful purpose, let alone the purpose for which it was marketed. Disclaimers as the rule,–particularly for low-priced mass-marketed licensed products. Remember, software is usually not “sold” as a product, but is licensed. The good is that consumers need not depend on hardware manufacturers to develop specific software. The bad is that software is a separate line item, and well, it doesn’t really have much to do with whether the machine works or not. Thus, the rise of open source software as a symbiotic adjunct to licensed products. While one can argue abut the merits, there is no question that this regime has allowed software vendors to flourish without worrying about liability.
However, warranties aside, contractors are expected to act in “good faith,” both in performance of contracts and in the execution of an agreement. For that reason, the case is certainly coming in which an expert will be called to weigh in on the quality and quantity of technical debt (reality) balanced against value and price terms (optimism at contract signing).
The argument might be that if a developer knowingly enters a contract with the expectation that significant technical debt is going to be an on-going “feature” of the relationship with the client…reasonable minds could differ over “good faith.” I don’t think anyone wants to see software become a licensed profession subject to codes of ethics, but standards of care then begin to matter a great deal.
While it would be a pleasure to show a jury a video of planning poker to demonstrate reasonableness (it’s bound to happen), a truly Agile approach to contracting will prevent a lot of the issues around software that simply doesn’t work.
Regina Mullen
April 16, 2010 at 1:30 am
[…] 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 […]
Round Two: Can Technical Debt Constitute a Breach of Implied Warranties? « The Agile Executive
July 27, 2010 at 6:31 am