Stories From The Battlefield: #2 - My God, It's Full Of Bugs!

I don't know if this applies to your case, but focusing on bugs as the problem is part of a typical testing/bug-fixing cycle of quality management, leads to the situation you described. When you mentioned scratching the surface of the problem uncovering a can of worms, it lead me to think this case applies to the typical situation that I come across when dealing with software quality issues.

Often bugs are not the problem, they are a helpful indicator of a deeper problem. Usually that problem is some form of technical debt, usually poor software design. Fixing bugs in this case is like putting a bandage over a deep infection. Sure, the customer doesn't see it any more, the tests may pass, but the problem is still lurking underneath. Often bug fixes make the problem worse by building another layer over an unstable foundation. At best they prevent the true problem from being discovered as easily in some other situation. Each time you fix one of these bugs, you are actually paying interest on technical debt. Sometimes that's cheaper than paying back the principle, but usually it is not.

Instead of putting the surface indicators of the issue (the bugs) in your backlog, try to identify the specific technical debt that needs to be paid off (and the interest it costs) and put that in the backlog.

The problem lies with quality management processes left over from waterfall. Testing and bug-fixing, repeat as necessary. Testing (and I am not talking about testing as in test driven development here, as that is more about design than testing, but I do include unit tests) is a fairly superficial activity that has more to do with whether the software meets requirements without crashing or displaying inappropriate or unexpected error messages. It doesn't actually say anything about the quality of the software itself. (Testing only covers a couple of the ISO 9126 defined aspects of Software Quality) Bug-fixing too is an approach that focuses on getting the tests to pass, rather than improving the actual quality of the software.

Software quality is mostly about good software design, and, until recently, mostly considered, a technical issue for the developers, something out of the hands of project managers. However as agile has changed the role of developers into becoming craftsmen and having more responsibility for planning and organizing the development, quality managers (or project managers in general) are also finding they have to become craftsmen too, and take more responsibility for software quality beyond the old testing/bug-fixing cycle, primarily by becoming managers of technical debt.

I prefer an approach to bug fixing that doesn't assign a fixed (upper) amount of time to bug fixing. Instead, fix bugs as soon as you know about them - and do a root cause analysis how it got out into the wild in the first place, and what you will do to prevent similar bugs escaping in the future. Don't schedule stories for this, just do it as part of the infrastructure work. Yesterday's Wheather will take care of how much time to plan for this. (And this doesn't have to stop you from shipping a feature.)

I've heard of teams who get down to having a handful of bugs report *per year* - and that's not because the software wasn't used. And there is this story of Toyota (who invented this Lean technique, as far as I know), who took over a plant in the US - it took them a month to produce their first car, because they had to stop the line so often to fix small problems. After that month, they were the most productive plant in the whole US.

That building cars and building software are different would be a good argument for the possibility that the technique might not work for building software - if there weren't software development teams out there that tried it and proved that, in fact, it can.

I hate agile developers: i own one piece of - well you know. Fully of bugs and developers tell us "we have the method which produces best software".

@pbielicki
Calm down, I never said ALL bugs were due to bad design. Phrases like "often" or "in this case" don't mean "always" and "in every case".

Of course there are many types of errors.

Simple errors like the 0 instead of 1, or forgetting something, usually lead to a situation where it either works or it doesn't, and I would like to think that the developer will notice this when trying out what he just wrote, or at least during software testing.

I was trying to respond to what I though the original post was referring to, those tricky errors that keep popping up after release despite being repeatedly "fixed". These types of errors use a lot more time and effort in maintenance and debugging than the former, to the extent that the former are almost trivial. At least the simple errors can be fixed once, and then they are gone.

I still maintain that the current focus of software quality on testing and bug fixing does little beyond what the developer himself should be doing before checking in his code anyway, and the really tricky "bugs" are often just symptoms of the real problem: bad software quality. Often, but not always, this poor quality is a result of bad software design.

"any software systems are more complicated these days than can be managed by reasonable means"

I agree that todays software systems are too complicated to be managed reasonably *using the methods that are typically applied*. It seems to me that the pure existance of teams who *do* manage to get such high quality that they get just a handful of bugs reported each year is prove enough that there are ways to reasonably manage complex projects. It seems to be more productive to me to ask "what are they doing differently" than to pretend that we are simply screwed. Your mileage may vary, of course.