The fear

When programmers start out they are like small children, they have no awareness of danger. So they just go ahead and hack code, with no thoughts for the consequences. It's only after a few late nights caused by introducing serious bugs due to a one line change for some minor cosmetic problem that programmers develop the fear. The fear is a good thing, it helps us programmers to spot potentially dangerous changes to code and try our best to reduce the risk of breaking things. But there are two main ways that programmers (and managers for that matter) will deal with the fear. The first approach is to try to limit the amount of code change. If they are fixing a bug in an area they are unfamiliar with, they'll try to find the smallest amount of code they can change that fixes the problem, so rather than try to understand what the code is trying to do, they'll just shove in something that fixes the problem for this specific case and move on. This approach has some merits, there is certainly a link between the number of lines of code changed and the chance of new bugs being introduced but it doesn't solve the underlying problem, that the programmer doesn't understand what the code does. If they did, the fear wouldn't be so bad and they'd likely fix it properly. In the short term, that bit of code probably just got even more difficult to maintain. In the longer term, areas of the product can become no go areas that haven't been touched for years and nobody understands anymore. But they work mostly so that's OK, until a new feature needs to be added. At which point, the developers will turn round and say "we need to rewrite it all because it's such a mess". So how else can we deal with the fear? What you need to do is get into a place where the fear holds no, er, fear. It starts off simply enough, get some source control in place. If you haven't got source control, you're pretty much screwed, unless you're working on the next 'hello world' app. It's a great thing to be able to check out some code, hack it around, then if it doesn't work out go back to what you had before. Or two weeks down the line, when you realise that the bug fix wasn't such a big success, you can rollback to something that's more sensible. Check in regularly, like twice a day, not every two months. There are lots of other things to help reduce the fear. If it's code you don't understand too well, try to work out what's going on, do a bit of refactoring, try adding some unit tests, throw FxCop at it (or in the Delphi world Pascal Analyzer), adopt some agile methods, get a QA team. The tools are out there, so lose the fear.