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 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.

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:

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 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 they can help you accelerate your cloud-native application development.

Be the Revolution