Le vin qui plaît

Why increase quality? One good reason: costs reduction. There are many others, but this one is important enough.

Hacking together lines of codes at the speed of light and throwing them in the nature generally results in a boomerang right in your face in a future that's never that distant.

Hiring great programmers, providing them with a good environment, buying whatever hardware or software is needed and promoting the taste for quality within the organization are the first obvious steps.

Tests (unit tests and integration tests) improve quality as well, but not immediately and not as much as you might have been led to believe.

They have the advantage, especially unit tests, to reduce the difficulty of refactoring. If refactoring is less expensive, you'll do it more often, giving you the opportunity to rework and improve the parts within your program whenever they need it. That's extremely sane and virtuous.

You know the projects where some areas are "left untouched because every time we try to change something everything falls apart"? These projects become more and more expensive to maintain, difficult to sell and awful to manage. I call them Innsmouth projects because people who arrive in these projects eventually gaze upon some ancient code conveying horrors that no human mind may withstand.

Tests are good, but you guessed that this post isn't about tests. Do you want to know the thing I do that improves code quality the most?

It's tracing through the code I just wrote with a debugger and validating that it does what I think it's supposed to do.

That's exactly the same process than reading the letter you just wrote to catch misspelled or misplaced words.

Sounds quite mundane and obvious doesn't it?

You'd be surprised how many bugs you can squash in stepping through your code, ensuring the variables contain what you think they should contain and observing that the behavior matches your expectations.

To see how much you can gain from this method, let's consider this way of doing:

  1. Write some great code
  2. See if it works for one or several cases
  3. Consider it works
  4. Work on a different part...

At no moment did you check the internal behavior of your program. Unfortunately you might get lucky and your program may work for the wrong reasons.

If instead you...

  1. Write some great code
  2. See if it works for one or several cases while stepping through with the debugger
  3. Consider it works
  4. Work on a different part...

As you step through, you will quickly see if it works for the wrong reasons!

When you write unit tests, don't just check they pass, trace and debug your code. Don't rely on someone else's to do the code review, do it yourself.