Software development should focus on quality
Martin Rice believes people are measuring the wrong metric in software projects
Rice: Better software is needed and that requires a change in thinking
Unlike in many other disciplines, in software projects quality is often sacrificed in favour of quicker delivery time. Perhaps it is because we are all paying for the wrong thing. Many companies believe time is money. Because, well, it usually is.
Most of us are paid by the hour and many services (mobile phones, plumbers, car hire) are similarly charged according to units of time.
In the workplace, this is all well and good when there is a tangible result, like on a production line. For a factory worker, more activity means more productivity – the faster they work the more units they produce at less cost to their employer. If the worker is given improved equipment and better raw materials they can maintain the same quality while churning out more units.
There is a direct and simple correlation between cost and time.
Software development is not like a production line. Clichés aside, programmers do not sit at terminals for eight hours a day, churning out code; their roles are more varied and creative. This includes imagining the software, designing graphics, building, ironing out defects, testing, integrating, and a host of other tasks.
Yet software projects are billed as if they were production lines.
You want cheaper software? Drive down the time it takes to produce it. Unfortunately, this is almost exclusively to the detriment of quality. Broadly speaking, there is a misconception that quality can be traded for reduced development time and lower costs.
If the main driver for a software project is to finish in record time, the software produced will inevitably be of lower quality because less time is available for the development team to focus on the details and improve usability. In the long run this means savings made on hourly rates get eaten by increased operational and maintenance costs after the software goes live.
Software errors cost a lot of money.
So if time to deliver is the wrong driver, what is the right one? There is at this point no industry-wide agreement but I believe the evidence points to a need for a shift in focus to quality rather than price.
The customer wants software that offers the most value and benefit over its lifetime. This includes the least amount of maintenance, security against obsolescence, flexibility, and functionality that meets all present requirements and possible future needs.
The software development house should want to deliver the best quality possible in a reasonable amount of time. This includes the fewest number of defects, functionality that meets all requirements, and an easy-to-use interface – without overworking the programming team.
The value to the customer is a greater long-term gain for a comparatively small short-term outlay, and possible business advantage. The value for the developer is that producing a quality product reduces the need for extensive post-delivery bug fixing, improves the morale and skills of the development team and can be reused for other projects – backed by a customer willing to go on record to say how great it is.
Sadly, the software industry is still afflicted by a condition suffered across much of the Western world: obsessively seeking the lowest price over the best value.
You pay for what you get. Go out and buy battery-farmed chicken because it’s cheaper than the free-range version, by all means, but don’t complain if it’s tasteless.
These changes probably need to be driven by customer demand, or at least a few market leaders putting real effort into engendering an appreciation of quality in their workforce and customers.
The Japanese car industry in the 60s and 70s became a global leader by investing more time and money in developing reliable, better quality cars. At the same time, British Leyland was sending out cars with bricks propping up the suspension – and look what happened to them.
Software houses employ professionals who imagine and create efficient and artfully written code. Given time and encouragement, they can produce software that will be high quality, that will last longer, that will be easy to use (saving on training) and will ultimately repay that slight extra investment, or even make it back completely.
Yes, time is a factor in software projects, but compulsively driving down the time of a project to make a slight saving in the short term will probably cost more than if the same attention was paid to the quality of the software.
Martin Rice is chief executive officer at Erudine