April 05, 2003
I have very much been enjoying the serialized interview on artima.com with Andy Hunt and Dave Thomas, authors of The Pragmatic Programmer. In particular, the first segment rang true: "Don't Live with Broken Windows".
As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can't fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn't trust it, shouldn't go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. "Well, that's broken. Oh I just broke that. Oh well."
I picked up the book at the library a few weeks ago and devoured it. It's very good, I learned a lot and have much to think about. I'm not ready for everything in the book, especially the latter chapters, partly because of the situation in which I work, partly because of where I am in my development as a programmer. So much of it, though, just resonated with me. They just plain make sense and have some great ideas. Read through the interviews and you might see what I mean.
It's been especially interesting to me as I've been working with code that I wrote a couple years ago and realize just how far I've come in my programming practices. Sometimes I look at the code and wonder, "What was I thinking?!" Other times I just look at it and go, "Oh yeah, that made sense, but I've figured out a better way of handling that now." It's kinda cool. When I read "Don't Live with Broken Windows," I had just come across a comment in some oldish code: "Not the best way to handle this, but it'll work as a proof of concept. Clean it up before it goes into production." Of course, it had been in production for over a year. Heh. So i cleaned it up.
I don't do so much of that anymore: I try very hard to take the time to get things right the first time, while at the same time avoiding premature optimization. The trick is balancing this against the unreasonable timelines I must usually work with. It's been satisfying to realize that the code that I write under these conditions is far better than it was even a couple years ago. I'm confident that what I learn from The Pragmatic Programmer will help even more.
