The Pragmatic Programmer: From Journeyman to Master
Back in January 2006, I finished The Pragmatic Programmer: From Journeyman to Master, by Andrew Hunt and David Thomas. This is a required book. It contains all sorts of thoughtful, pragmatic advice for becoming a better programmer/developer/coder/hacker (choose whichever word you like the best to describe a professional software engineer).
After the ten months of reading it, I remember only two. First, that the journal Communications of the ACM has “published more seminal articles than any other journal”. Which is one of the reasons I finally joined the ACM and the IEEE in March 2006.
Second, allow no broken windows. Once you have a few broken windows, it makes it easier and easier to have additional broken windows, until finally all your windows are broken, the southeast corner of the roof is caving in, and you have Eugene Victor Toombs hibernating in your basement.
This advice stems from the observation that if there is an abandoned building that is kept up and doesn’t look abandoned, people tend to leave it alone. But as soon as a window is broken, or graffiti is allowed to stay, more windows are broken and more graffiti is added and pretty soon the building has turned into an eyesore that nobody wants to go near, let alone maintain.
The moral of the story: it is easier to maintain something that is already clean and organized than something that is a complete dump.
I have noticed this in my home since my son has been born. It is easier to spend five or ten minutes every night to pick up his toys, straighten the living room, and do the dishes than to wait a couple days for things to accumulate.
The same is true of code. As soon as you get lazy and stop writing unit tests, it becomes easier to stop writing unit test all together. Or copying and pasting code instead of refactoring.
I have the tendency as a developer to think “Oh, I’ll come back and clean this up later.” But the time to do clean-up chores never comes. Just try telling your product manager, “We need to spend a month cleaning up our code and unit tests.” It’s not gonna happen because it doesn’t help sell your software.
When was the last time you saw on a set of release notes for a successful, popular product, “Cleaned up and refactored code because it was starting to stink”? Why not? Because good developers keep things clean as they go and when they find messy, rotten code they take the time now to bathe it, scrub it, and put it in a cute outfit so people can admire it.
No broken windows. Because you’ll never be able to go back and fix them.
Comment Digg This