Business Cost of Skipping TDD and Code Reviews
Most software projects have tight deadlines. Operating at the speed of business today demands this.
When you're working under these tight deadlines, it can seem prudent to cut processes that take extra time. Best practices like Test-Driven Development (TDD) and Code Reviews - despite directly contributing to defect-free software - can get shoved aside.
It's easy to justify because you think you're saving time, and there's a deadline to hit. TDD and Code Reviews take extra time. Some software estimates say these can add 30% to your design phase.
But the cost of skipping Test-Driven Development and Code Reviews is much higher than you probably realize. It's not just the cost of fixing bugs that you need to worry about, but bypassing TDD and Code reviews can have a real and detrimental effect on your business's health and success.
What is Test-Driven Development?
With TDD, automated unit tests are written before any code is written, instead of the more traditional practice of writing code and then creating your test. Studies have shown that TDD reduces production defect density by a whopping 40 to 80%.
While there are many articles and books written on the topic, TDD can be summarized in a few quick steps.
Write your automated test. The test should only be big enough to cover the function you're implementing.
Run and fail your test. Your test should fail because you haven't written any new code. If it doesn't fail, rewrite your test.
Write your code. This should be just enough code to pass the test.
Rerun your test. If it passes, go to the next step. If it fails, make changes to your code and retest.
Refactor your code. This is intended to improve the design of your code but may not always be needed.
Repeat. Move on to the next piece of code you want to implement.
It's easy to see how this can add extra time to your development efforts.
What are Code Reviews?
Code Reviews are the actions of one or more developers reviewing the code written by another developer to ensure that requirements were met and catch any potential mistakes or design issues.
A common form of Code Review is the Over-the-Shoulder technique, where the developers sit together, in person or virtually, and go through the code together. However, these reviews can also occur through email threads or by adopting a Pair Programing approach.
Like TDD, Code Reviews take time. Most notably, you now involve other developers - often more senior developers - in the review. So instead of working on their code, they're reviewing someone else's code.
Hard Costs of Skipping TDD and Code Reviews
Writing code is, ultimately, a human endeavour - a person has to sit down, interpret the requirements, and then write code lines to fulfill those requirements. Like any human endeavour, mistakes can happen. Defects are a part of software development.
But the point at which you catch those defects, and the rate at which you resolve them, matters greatly. It's a simple fact of software development: the sooner you catch defects in the SDLC, the cheaper they are to fix. Studies vary, but a figure generally used is that the cost of repairing a defect in production is around 100 times more than fixing a bug found during the design phase.
So a defect that costs $50 to fix during development could cost up to $5000 to fix after it's been delivered to the client. This number seems huge, but not when you break it down.
Let's take a simple scenario: A developer using TDD finds a defect in her code when an automated test fails. At that point, she's fully immersed in the requirement and the code - she knows what she's trying to accomplish. After refactoring her code a couple of times, the test passes. The total time to fix the defect is about 15 minutes.
Now let's look at the many extras that get piled on for a defect found in production:
Cost of Customer Support: A production defect generally gets reported to your customer support team. That team must then work with the customer to verify the bug and then create a development ticket. Depending on the severity, a workaround may be needed. And every time the defect is re-reported by a different customer, your support team has to respond.
Cost of interruption: The developer hasn't worked on that code for weeks, maybe even months. It will take her time to get back into the code, even if it's well commented. Even worse is if that developer is not available and someone new has to work on the fix.
Cost of implementation: That fix must now be merged back into the main branch, which carries its risks.
Cost of QA: Your QA team must now test the fix. The scope of testing will depend on the complexity of the fix.
Cost of delivery: While this fix may go out in the next release, a high severity defect may require a patch to be delivered to dozens or even hundreds of customers.
When you add up all the extra team members' time, you can easily see how this could balloon to taking 2 to 3 person-hours to resolve. Now multiply by the total number of defects, and the cost can be jarring.
Business Costs of Skipping TDD and Code Reviews
Defects found in the design and implementation phases are internal - no one outside of your company sees them. Once those defects hit production, it's a different story.
No CEO or CTO wants to get a phone call from their counterpart on their biggest customer complaining about a defect. It's not a pleasant conversation.
These days, everything is reviewed. Multiple ones and two-star reviews can be devastating. And gaining a reputation for producing "buggy" software is not something companies strive for. The impact on sales and renewals can affect your bottom line.
And you can't discount the internal strife production bugs create. These cause real stress to your front-line staff, put unnecessary pressure on your development team, and throws off the schedule of everyone involved. Stress and panic can lead to even more mistakes and defects an unnecessary employee turnover.
Long Term Benefits
Test-Driven Software Development and Code Reviews add time to the design phase. There's no way around that.
But the costs of skipping these best practices can quickly add up and can have devastating and long-lasting effects on a company.
Successfully implementing TDD and Code Reviews in your company is really about creating a culture in which they are encouraged and expected. Support for these comes from the top and is reinforced at every level.
Soon, it becomes part of who you are. It defines you as a company that delivers and stands for quality.
Get in touch with INGENO today to find out how we can help you accelerate your cloud-native application development.