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

Much of the success of a good manager or leader is making sure your team can get the right work done. The demands on a team, say a product team in a tech company, increase as organisations grow. Before you know it there are requests from all sides that can sap a team's time, energy, and ability to get the key work done.

Todd Jackson, former product manager of Gmail, memorably shared that a manager can be an umbrella or a funnel. The umbrella protects their team to let them get work done and the funnel lets everything pour through.

All of us want autonomy to choose our own actions but none of us want to be overwhelmed.

Umbrellas and funnels

Hofstadter's Law is one of my favourites.

“It always takes longer than you expect, even when you account for Hofstadter’s Law.”

Hofstadter’s Law

I regularly find the Kano model a useful way to think about design.

Kano highlights 3 different types of benefits your product can provide:

Threshold
  These support the minimum requirements of the product. Like the brakes on a car, you’re not going to buy one without them, and yet no matter how good you make them they are unlikely to thrill people about the car. But if you do a bad job, people will sure notice.


Performance
  these benefits are appreciated the more you deliver on them. For a car this may be acceleration or fuel efficiency. The better you make them the happier people will be, and the worse they are the least satisfied they’ll be.


Delighters
  these are the fun benefits that get people to love a product, but if you only had delighters you wouldn’t have a product. For instance, if you car is slow, not fuel efficient and the brakes don’t work, it doesn’t matter if it has the best stereo on the planet, for almost everyone it just won’t help. But if your car has serviceable brakes, reasonable acceleration and fuel efficiency, and the best stereo on the planet then it could really delight.

Sketchplanations tagged with product-management