What does code actually cost? Over the last 15 years, there have been many good and, from my own experience, credible studies and estimates on the impact of bad code on costs. Among the most recent is an estimate from technology company Stripe and Harris Insights and Analytics, which found that on average, a developer spends 42% of their time on technical debt and maintenance challenges. This means less than 60% of working time is spent producing what they were originally hired to do. Furthermore, 59% of developers believed that companies spend an insane amount of money fighting bad code. 79% of developers felt they weren’t given enough time to produce good code. According to the study, companies spend up to 300 billion dollars annually on maintaining old code and services - 85 billion dollars on fixing bad code alone.
Software projects often focus on getting a product or service into production on schedule and in working order. Working, but not reliable? Is it enough that a service works if its quality is so poor that maintenance, further development, and normal use require large sums of money that were never mentioned when the software was ordered? The problem is holistic and doesn’t stem from bad developers, unskilled clients, or incompetent project managers. Software is teamwork, and that requires communication to work and trust to be in place.
A Story
A popular clothing store’s new e-commerce project was implemented using agile methods, stayed on schedule, and was launched within budget. The client, the production team, and the customers were satisfied. For a moment. The day after the service was released, several problems were noticed: some products were missing from the store, some couldn’t be added to the cart, consumers flooded the site in the evenings and the store couldn’t handle the rush, and some purchases failed due to unsuccessful payment transactions.
The team that built the store started investigating the problems. It took 4 weeks to fix all the issues. It was calculated that failed payment transactions alone accounted for 10% of all attempts (0.1*200) per day. About 15% of the extensive product catalog was missing from the store (150 articles), and the store crashed three times during the first week, interrupting an average of 20 purchasing transactions. Sales had to be suspended entirely for two days when the fixed store was re-released.
Further problems arose when the store underwent continued development, and new features like an improved search, new payment methods, store aesthetics, and the product management panel were improved. Some developers in the supplier’s team changed, and the new developers were unfamiliar with the code. Developers had to work with incomplete documentation and poorly commented code. The code produced was complex, and 30% of working time was spent reading it and figuring out even simple problems. Refactoring the code for better readability and performance consumed an average of 40% of the time. This meant that new features could only be implemented during 30% of the available time. Further development took 4 weeks.
When they finally reached a point where the worst problems were solved, a new version of the store was released to customers, and sales began to flow, they had to sign a maintenance contract with a new partner. This was because the service still didn’t operate reliably; the maintenance team still had to fix errors in both the code and the purchasing transactions. The maintainers had to restart the store on the servers due to system crashes occurring for unknown reasons.
What Could Have Been Done Differently?
Nearly every decision made during implementation affects the quality of software production. Are the right tools chosen for the production process, are they used effectively, and does communication work? Can an efficient and functional solution be designed and implemented? Does the team have sufficient competence in the tools and technologies, solution models, and methods? Are the team’s architect and the client’s representative (Product Owner) knowledgeable enough? Are the team’s and developers’ practices correct and reliable enough? Does the team produce high-quality, functional, scalable code suitable for solving the problem, or are they content just to get the desired function completed? Many questions about what needs to be considered.
When choosing an implementation team, focus should be on experience, broad technological expertise, and business understanding. If you only hire developers to produce functionality, you often only get those functions. Selecting a team by playing “buzzword bingo” might result in a team that knows the chosen technologies but says nothing about the quality of the code and service they produce. Growing into a good developer is a long road with few shortcuts. Good mentors help people get on the right path and stay there.
Since I originally asked what bad code costs, let’s use an example and studies to help.
In the story, approximately 480 purchasing transactions were hypothetically lost over a week, with the average purchase being worth about €75. The lost sales amounted to at least €30,000. Fixing the issues took a five-person developer team four weeks, costing €75,000 (€100/h). Further development was done with only 30% productivity, so out of a €75,000 labor investment, up to 70% or over €50,000 was wasted. A new maintenance partner spent an average of one work day per week during the first year fixing problems and performing extra maintenance, at a cost of €39,000. The total cost impact resulting from the project’s problems was approximately €200,000. The annual sales value of the store was over €5.5 million. Without the repairs, lost sales could have been as high as 35%, or €1.8 million annually. Often, repairs are made late or even left undone due to costs, causing lost sales to realize invisibly.
Next time, I will write more about practical solutions and quality, and how that quality is achieved.
Sources
The Developer Coefficient:
a $300B opportunity for businesses
