Smash it up
I completely agree with Jeff on this one. Fear of breaking code can hold you back from making the kind of changes that are required to keep the code alive.
As a consultant I see this kind of fear a lot. Quite often I arrive at a client site and start to speak to the natives about the lay of the land and one of the first things they do is point out that their system is very very complicated and that you have to be very careful not to break things; right, I think, they have no tests then… Next I’ll be told that new features should be added without “disturbing” much of the existing code; which translates to, expect to see a patchwork of code that has been hacked in all sorts of wierd and wonderful directions…
Now, there are some very good reasons for restricting changes to an area of code; but fear isn’t one of them. When I see this kind of fear in a team I know that none of them really understands the system, and that often they don’t even really want to understand the system.
It’s a pity because when a team is responsible for a body of code then their main tasks should always be to understand the system, keep it healthy, and help it to grow. If they’re too scared to make the changes required to keep the system healthy then this usually means they lack the knowledge and experience required to be responsible for the system. This is fine in isolated pockets of more junior people on the team, after all, that’s why they’re junior. The problem is when it’s the whole team that think this way, when nobody is moving things forward.
I’ve said before that often there simply isn’t a good reason that code is the way it is. If you’re not brave enough to question why the code is in the state it is in and recognise when that state is a symptom of disease rather than a desired situation then you’re doomed to hack and patch development and a system that slowly slides towards chaos. Question why code is the way it is, experiment with ‘fixing’ things that look broken, work out what happens when you’re left with several pieces on the desk after you’ve taken it all apart and put it all back together again. Experiment, explore and learn and you’ll find the fear starts to go away.
Of course you don’t do all this learning on the code you’re about to check in on the day before a code freeze… Use source control to make these experiments safe. Use testing, preferably automated unit testing, to make the changes that you do make, safe changes.
Lose the fear and start enjoying the challenge.