Free initial chat

Free Initial Chat

Complete this form if you would like a free, no obligation conversation with a solicitor.

Contracting for Software Quality

Mar 30, 2017

Like most things in life, software breaks down. Not like, say, a car through old age or over-use, but from inherent errors. Bugs. Odd as it might sound generally software is too complicated to be perfect. When software fails it causes downtime, which in turn causes disruption and cost to businesses (and frustration in our personal lives).

IT departments have a hard time delivering services to their client organisations and developing and deploying new software solutions ranks amongst the trickiest operations. IT lawyers aim to add value to the procurement process, so is there some way that contracts can help to make better quality software? Is that even possible?

A recent report from CAST [1] looked at the quality of software from a large library of applications, over 2 billion lines of code from over 400 organisations. Some of the findings will ring true with IT industry veterans, but others are a little surprising.

The report shows that there is not much difference in software quality between agile-developed and waterfall-developed code. So the myth that agile code is just lashed together can be put to bed. But both methods come second to hybrid development – that is, some traditional up-front analysis and design, followed by an agile coding phase.

Lawyers who (probably rightly) complain that agile development agreements are really just time & materials contracts can buy some contractual protection for their business when a hybrid model is used. The contract can provide for some traditional early design deliverables (and an exit point) before launching into the expensive and difficult agile build phase. And ultimately the software is likely to be better, saving the business from problems in the long term.

The location of the development team makes little difference; it does not seem to matter whether a system is developed off-shore, on-shore, contracted out or in-house.

The bigger difference comes with development team size – 10 or less seems to be ideal. Small is good for programming. Software engineers have known this for a long time. It’s the sort of thing the famous book The Mythical Man-Month was getting at. This can be contracted for as part of an agreed software development methodology.

The maturity of the developer organisation (whether third party or in-house) is a significant factor in software quality; the report used CMMI level as a proxy for maturity (roughly speaking, CMMI assesses the extent to which an organisation has defined processes for running its business) and showed that CMMI Level 2 organisations developed significantly better code than Level 1’s; the move from CMMI Level 2 to 3 made little difference. CMMI Level 2 organisations use better planning techniques, thus allowing more time for rigour and discipline in development. This one is easier to catch during the vendor selection process (which lawyers often help with) but can also be a contractual commitment to maintain (or achieve) a CMMI level 2 (or equivalent) certification.

So, yes, lawyers can help their businesses contract for better quality software, both by asking good questions during the vendor selection process and by adding drafting to development contracts to support practices that are known to improve software quality.

[1] Source: CRASH Report, 2017 Global Sample, Global Trends in Software Structural Quality

Richard Chapman was originally a software engineer working on large defence projects. For the last 20 years he has been a lawyer advising businesses on IT projects. He is recognised as one of the UK’s leading IT lawyers. Read more.