"If it ain't broken, don't fix it." Like Dave Thomas and Any Hunt, who encourage fixing "Broken Windows" in their timeless book The Pragmatic Programmer, I prefer "If it's broken, fix it." The only other option is to stop using it. The assumption about unnecessary fixes is often that the machine cannot handle change well and will probably run best if left alone. This may be true but the machine might still be severely lacking.
Fixing broken things applies as much to machines as it does processes. If you find yourself in a broken process, you can either let it beat you up, fix it, or just exit stage right. More often than not the best alternative is to fix it. And yet, oddly enough, it seems most people's m.o. is to get the snot kicked out of them until they finally just leave, defeated.
Insist on the Fix
A better plan is to reject status quo and push to fix the problem. This can be instigated at any level. Often problems and their solutions aren't noticed where you'd expect they should be and fixing things means breaking out of baked in patterns and even, occasionally, talking to people who don't think things should be fixed. In The Pragmatic Programmer, chapter one, section three, titled "Stone Soup and Boiled Frogs," Thomas and Hunt suggest avoiding the blank stares you'd get by asking permission to fix something:
Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say "of course, it would be better if we added..." Pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success.
If You're Wrong...
It also means occasionally being told to slow down because "It ain't really broken, Gungho." And they'll probably respect what you're doing enough explain why. So, the worst that can happen is, you'll learn how to stop worrying about whatever it was you thought was a problem.
Comments