Bug fixing is really important, it isn’t?

In the result of an external quality audit for a company that I know, I read the following sentence in the improvement section:

Very successful implementation of a development philosophy that favours the definition of requirements and the test phase rather than the fixing of bugs.

Hey! But a rule from Pragmatic Programmers reads like this:

Rule #2: Fix broken windows

The concept of Broken Windows come from the criminological theory:

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters.

In software development, broken windows are bad designs, wrong decisions or even poor code. If you don’t fix them as you find them, you’ll end up quickly with software rot.

Uhm… Max Kanat-Alexander (of Code Simplicity fame) also says:

The secret of Success: Suck Less

Not only… it also says that, when you solved the issue, you are supposed to make it never came back!

When solving a problem in a codebase, you’re not done when the symptoms stop. You’re done when the problem has disappeared and will never come back.

It’s very easy to stop solving a problem when it no longer has any visible symptoms. You’ve fixed the bug, nobody is complaining, and there seem to be other pressing issues. So why continue to do work on it? It’s fine for now, right?

No. Remember that what we care about the most in software is the future. The way that software companies get into unmanageable situations with their codebases is not really handling problems until they are done.

There is something I don’t really understand about these quality audits…

Bug fixing is really important, it isn’t?

One thought on “Bug fixing is really important, it isn’t?

  1. Mike W. says:

    Came over here from Max’s blog. Funny observation!

    The way it *could* be interpreted, the most sensible, charitable interpretation, would be:

    > Don’t just ship some crap that does everything backwards, and then “fix” problems one by one as people report them.

    In other words, if your philosophy of “fixing of bugs” doesn’t include tracing down the *actual* cause of the bugs, your codebase is just going to get worse over time.

    But perhaps that’s giving more credit than deserved to that particular quality audit. 😉

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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