Don’t Aim to Win Battles – Aim to Win Wars

July 29, 2014

Blog | Development | Don’t Aim to Win Battles – Aim to Win Wars
Don’t Aim to Win Battles – Aim to Win Wars

My apartment is a warzone. I am locked in a heated battle against nature. My defenses are strong, but nature’s attacks have been relentless. I am, of course, talking about The Great Centipede Invasion of 2014. Backed by the Paper Towels of Justice™, I have rid my apartment of the hundred-footed invaders time after time. But every time I crush the enemy in battle, there is one question that I ask myself –

Am I taking the right approach to eliminating these bugs?

The world of software design is no different, though I hope you don’t have any centipedes in your code. When presented with a bug, our immediate response is, “How can we fix this?” But is that going to be the response every time a bug is reported? Wouldn’t it be better to work to prevent this and similar issues from happening again?

Of course, bugs in software are pretty unavoidable. (In non-trivial situations. Don’t sass me.) They exist in your code right now and you don’t even know it. You just call them “features”.

According to Software Testing Tricks, two of the leading causes of bugs in software are unrealistic development timeframes and last minute changes. If we keep following this mentality of, “Here is an issue, fix it now”, instead of taking the time to properly clean up the code, these bugs aren’t going to go anywhere.

When “quick fixes” become the method of choice, developers are forced to push pieces of code into the software so that they can meet their deadlines. This makes the software bloated and harder to manage. The client may pay less at first, but in the long run they end up paying a lot more.

“Pay more?” you ask. “How?”

It’s time for some math!

Let’s say we have an average of five bugs reported each week, over the span of a year (52 weeks). That’s 260 bugs per year. Now, assuming each bug takes two hours to fix, we’re up to 520 hours of work. At $100 an hour, we’re spending $52,000 a year to apply fixes to these bugs.

But what happens when we instead choose to take the time to properly research why some of these bugs happen and implement cleaner fixes?

Let’s go ahead and spend five hours on each of the bugs during the first week. Since we took our time to look through the issues, we better understood what was causing the issues and had time to clean up a broader area of code. This knocks us down to 4 bugs per week (after the first week). This is where we end up:

(4 bugs * 51 weeks) = 204 bugs + 5 bugs = 209 bugs/year
(5 bugs * 5 hrs) + (204 bugs * 2 hrs) = 433 hrs
433 hrs * $100/hr = $43,300

That just eliminated 51 potential bugs, saved us 87 hours of work, and $8,700!

Of course, this is a pretty convenient example. There’s no guarantee that taking extra time to fix one week’s worth of bugs will have that kind of impact on the yearly report. But when developers are given enough time to properly examine the programming style, methodologies, and dependencies of a piece of software, they are less likely to inadvertently blow something else up. Taking this extra time helps maintain a clean and easily maintainable codebase. This makes it easier for the developer to find where an issue lies.

Granted, coming from a developer’s standpoint, it may sound as if I’m saying, “Clients need to give us more time to do the things they want!” This isn’t the case at all. In fact, Software Testing Help says that these deadlines are often set by a developers’ overconfidence in themselves or in the hopes of not running into any issues on the way.

Less frustration for the developer, and less money spent for the client. Everyone gets to go home happy!

 

Cory Bergquist

Project Producer
Tags
  • Bug
  • Development

Recent Work

Check out what else we've been working on