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.

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.

The cost of fixing bugs

The chaos monkey is a smart piece of software and a brilliant idea from engineers at Netflix.

The chaos monkey deliberately switches off servers in live environments at random. It takes the pain of disappearing servers and brings that pain forward. By deliberately sabotaging their own systems it created strong alignment for the team to design-in redundancy and automation for the necessary resiliency and reliability in the face of random failures. Training for this randomness helps make stronger, more resilient and fault-tolerant systems and software and keeps your movie streaming so you can keep chilling without interruptions.

The chaos monkey is a great metaphor and trigger to actively work on what life could throw at your system before it happens.

More monkey inspiration for writing and for bananas.

Chaos monkey

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.

Bugs and releases

I love this diagram by Henrik Kniberg for how to think about what to release to your customers when. Hopefully it’s self-explanatory, but the idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not, when explained like that, so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. At the beginning they’ll probably have to put up with a lot if they want to use it, but with each successive release they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning and all along the way the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it usually involves some rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

HT: the brilliant User Story Mapping by Jeff Patton and Kevin Alves

A release strategy for happier customers, sooner

Shares information passively, with the neat effect that having a good one in an office can go a long way to getting people on the same page without explicitly calling meetings or sending out updates to do so. Handy to also have a good space in front of it for talking, discussing and generally collaborating. A common term in agile development, originally I believe from Alistair Cockburn of Thoughtworks. To quote from his article, of many possible:

- Is large and easily visible to the casual, interested observer
- Is understood at a glance
- Changes periodically, so that it is worth visiting
- Is easily kept up to date”

Information radiator

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Sketchplanations tagged with development