These are the 3 ways bugs are destroying your output

👇 (This is the same intro for all the lean waste posts. If you have read it already, scroll down for 4 paragraphs) 👇

We waste time all the time. Small unimportant tasks. Procrastination. Looking at nothing (this one is not really a time waster if it clears your head). The world is filled with traps that make us waste our time, and some of them we already know how to detect and adapt to them.

Photo by Stas Knop from Pexels

Lean Manufacturing talks about the 7 lean wastes, these wastes can also be mapped to software development.
During these next 7 days, I will pick up one of the wastes and investigate the following questions

  • Why does it impact our work?
  • What could be the causes of this?
  • How can we measure it?
  • How can we avoid it?

For today, the focus is on Defects. Bugs are part of life and part of any code, but they cost time to resolve. They cause extra work on the part of the development team, usually at bad times, causing unnecessary stress.

Left to themselves, things tend to go from bad to worse

Murphy’s Law

Although some bugs are part of life and we cannot run from them, others are just a symptom of a bigger problem. Not only do we have to spend time fixing and testing the code that will resolve the bug, the main issue is also all the time the bug has been undetected.
When we finally find it, there is a high chance more bugs will come from that one.

Anything you try to fix will take longer and cost you more than you thought.

Murphy’s Law

Why does it impact our work?

Photo by Pixabay from Pexels
  • Task-switching and Partially Done work, we need to move from our development work to solve a bug.
  • Blocker on production affecting a large number of customers becomes “all hands on deck”, stopping all other work immediately.
  • Minor defects get de-prioritized and then come back in the future to bite us.

What could be the causes of this?

Photo by Pixabay from Pexels
  • Extremely tight deadlines that force the team to hack the code together.
  • None or a small amount of test coverage.
  • No automated tests.
  • Manual steps in the deployment process.

How can we measure it?

Photo by Lukas from Pexels
  • Time to Repair, how long on average do bugs take to resolve
  • Number of Bugs created vs resolved per week

How can we avoid it?

Photo by Linda Eller-Shein from Pexels
  • Automated and high test coverage
  • Continuous integration and deployment
  • No manual steps after the code has been validated

A 100% bug-free code is a myth. Defects will always happen, the only thing we can do is to mitigate the risk, but never eliminate it completely.

Every solution breeds new problems.

Murphy’s Law



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

search previous next tag category expand menu location phone mail time cart zoom edit close