Bugs and releases

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Credit to Ewan Silver.

Published 22 Apr 2017

A weekly sketch by email

Learn something new in a sketch each Sunday

Sketchplanations in a book! I think you'll love Big Ideas Little Pictures

Prefer to listen?
Try the podcast

Like Sketchplanations?
Support me on Patreon

Keep exploring

The cost of fixing bugs

When drinking tea, just drink tea

Yesterday’s weather

Rubberducking

By monkeys

Sell painkillers, not vitamins illustration: showing two stores, one for vitamins with just one customer and vague future benefits, next to a busy store selling painkillers with a queue of people seeking "relief now!"

Painkillers and vitamins

Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money. It might go something like this: If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix. If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly. If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it. And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line. You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios. Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.…Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money. It might go something like this: If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix. If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly. If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it. And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line. You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios. Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.

Newer

RRandom

Older