1 The goal

I tried to imagine a Rule #1 for programming.

Today I think it would be best formulated as:

Don’t let your user down.

There are things a user expects, and things he or she doesn’t expect.

New features are highly valuable. However, if they come at the expense of existing users experiencing errors in workflows that previously worked well for them, then we’re letting our existing users down.

That causes pain to us, because we feel like we are a failure.

Meanwhile, the program doesn’t work and should be fixed – when? Right, “as soon as possible!”.

Remember how frustrating it is to have to drop everything you had been working on, in order to jump into a bug in existing logic?

If the bug was tricky and deeply hidden, it’s not that bad. If it was deeply hidden and trivial (and that’s so often the case!), then we’re spending time debugging while we could have been been developing new useful and interesting stuff instead.

How can we prevent regression bugs?

The best (and cheapest!) way I know is to write an automated test to accompany each important behavior.

The test will go through the moves of obtaining the result of the workflow, and will verify that the result was correct this time too.

If the result was different from what had been expected, the test fails and we know right away that had this been pushed to your user, they are very likely to experience buggy behavior as well.

Since you caught the error early on, your user never experienced the error.

As a programmer, you probably remember well how frustrating it is to keep trying the same thing that used to work just moments ago, and to be obtaining the same, wrong result.

User’s frustration means we’ve let them down at the particular time, and we as professionals do not agree to keep letting our users down.