Using AI for customer service in your company is a definite method to save time and money. If you’re like most business owners, you’re constantly searching for fresh, creative ways to improve your enterprise. We’re here to inform you that improving AI customer service is a simple and rapid win.
If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
“Owh, come on, it’s just a bug.”
— Johnny Rico, Starship Troopers
Bugs are our greatest threat in software development as measured by time, cost, and consequences. The Cost of Poor Software Quality in the US: A 2020 Report by Herb Krasner of CISQ estimates the cost of bugs at roughly $607 billion for the United States alone. This includes costs associated with unsuccessful projects, maintaining legacy systems, and software failures in operational systems. It doesn’t include security issues, technical debt, or a host of other “quality” issues having an overall price tag of over $2 trillion.
So, that’s the big picture. Let’s look at how much bugs are costing you, whether you need to fix all of them, and how you can prioritize which bugs to fix.
It’s important to distinguish between the actual cost of fixing a bug and the consequences that may result from not fixing a bug… and then having to fix it. We discuss the consequences of bugs below. The cost to fix a bug, however, is highly relative – depending on when and where the bug is discovered. The “relative costs” in the chart below from the IBM Systems Sciences Institute (2002) still appear to hold true as a function of process:
| Design | Implementation | Testing | Maintenance | |
|---|---|---|---|---|
| Defect Discovery Cost | 1x | 6.5x | 15x | 100x |
In Design, a developer writing code can see and rapidly correct an error. In this case, the cost is a perhaps some portion of the developer’s Code Churn. But, the more time that elapses after the code leaves the developer’s hands, more people and time are needed to find and fix the bug, test and validate that it’s been fixed. In the maintenance stage, that could include support for angry customers and clients.
| Measurement: | Plug in Your Own #’s |
|---|---|
| Average Time to Fix a Bug | 15 hours |
| Average Fully-Loaded Hourly Rate of Engineer* | * $68.83 |
| Base Cost to Fix a Bug | = $1032 |
* Here we’re using the US Bureau of Labor Statistics June 2021 average US-based software developer hourly rate of $52.95 for US-based developers. Fully-loaded costs can vary widely, but typically run from 25-40% of base salary, with 30% applied here.
The only trick here is finding your average time to fix a bug without having to do it manually… but the bigger issue is total number and types of bugs (fewer critical but hard to fix vs a horde or small fast fixes).
With our automated software development analytics you’re provided with everything needed to determine the costs of fixing bugs for your entire organization, project, team, and individual developer. The main metrics you’ll use include:
For a broader picture, again at your organization, project, team, and individual developer level, you can get an annualized cost based on:
Presume, in our example, that your organization is generating just 5 bugs per 1k SLOC and producing 100k SLOC yearly. That puts you over $500k for fixing bugs, requiring 3-4 full-time engineers just to fix bugs. Or, if you had 9 engineers, you’d know they’re spending at least a third of their time fixing bugs. And that is not at all unusual.
Again, software must be delivered on schedule or risk the consequences. You probably won’t have time to fix every single bug. For that matter, you may not know about a lot of bugs until the software gets into the hands of end-users, not just with how many different devices they have, but how they actually use the software. How “some” use it may be impossible to predict. Leastwise, three things are working in your favor for “most bugs”:
Thankfully, all bugs are not created equal. It is on the product manager or software engineering manager to prioritize which bugs should be fixed now or later, and which bugs can be safely ignored.
Technically worth an article unto itself because software can include everything from games to managing nuclear power plants. There are five major areas to consider according to a) how easy it is to fix plus b) the number of people impacted (scope) and c) degree of impact (severity):
That’s five major areas, each with three dimensions, a lot to consider. It’s important to determine the risks associated with the software being developed in advance.
In terms of managing the risk of a bug, a good question to ask is, “Are you willing to be held liable for any consequences caused by the bug?” Ultimately, it’s the software development company that’s responsible, but that doesn’t mean CEOs and CTOs won’t be asking how or why you let a “critical bug” slip by.
Beyond bugs that can cause injury and mayhem, you’re left with a lot of bugs that can impact business requirements and customer satisfaction. Knowing how many people a bug effects can help you prioritize which bugs to fix. In most cases these days, development teams are building in automated error reports to let you know how many people are being affected by a bug, and how frequently.
Earlier in development, project specifications should clearly outline the families of devices the software will be used on. Sites like StatCounter can help you get a good estimate for a variety of statistics (device, OS version, device vendor, browser version, screen resolution) by state and country. Post-release, your APM metrics can tell you exactly what to prioritize. It makes sense then to focus on sequentially fixing bugs that will impact the next largest group of users.
It’s also worth noting that some bugs may end up being treated as features – actually working better than the original idea. Infrequent bugs experienced by small numbers of users with trivial impact may be assessed as safe to ignore. The cost to fix them exceeds the value of fixing them. Depending on your view, the Blue Screen of Death may be regarded as a bug or a “bug check” – suffice that Microsoft let this issue persist across several generations of Windows.
Gitential’s work on an AI Assistant for Software Delivery will help reduce delivery costs and the cost of bug fixes in several ways. Simply stated, an AI Assistant lets users ask questions (Google-like queries) and receive instant answers — data, supporting visuals (graphs/charts), explanation of the data, a summary and Next Best Actions.
Functionally, our AI will provide engineering managers, and developers “Insights On-Demand” – things you can do almost immediately to improve team and individual developer performance. The AI can provide insights to C-levels, BI Specialists, and even HR managers, too, to align on organizational OKRs, optimize budget allocations, and drive hiring strategies.
Preventing bugs in the first place is a function of optimizing teams around project specifications and requirements. Initial team selection and growth scale in complexity to the number of developers in the company (not just project or team) – and scales proportionately. This isn’t so simple, it needs to factor:
From a risk management perspective, bottlenecks are almost inevitable without a proper mix of experience on a team – equating to either low quality PR code reviews or delays in picking them up. Much can be said about how code complexity tends to increase dramatically as teams expand – increasing the likelihood of bugs and increasing the time/effort to find them.
Where managers have spent hours digging through analytics to find helpful insights – AI renders actionable insights in seconds – how to help a developer reduce their defect rate or what their team needs to do to improve their MTTR.
We’ve prepared a lot more to explain the benefits an AI-powered Assistant can provide software development teams. The following articles are related to software delivery costs – and we hope you’ll check some of them out!
Article Updated: February 07, 2022
