Getting Real About Hacking

Update: Between the time that I drafted this post and the time I published this post, the "Don't be a Codemonkey" post appears to have been taken down.

The best teams that I've worked on balanced creative hackery (finding creative, innovative ways to solve problems) with craftsmanship (enabling easy extension, testing, reuse, and maintainance). I was intrigued to see Erik McClure dismiss the latter quality, in his Don't be a Codemonkey post:

Good programmers write code that does what its supposed to do in the simplest, most efficient way possible. I don't care if it isn't maintainable, that doesn't make you a bad programmer, it makes you a bad codemonkey.

I disagree. I don't want maintainability-be-damned programmers writing any software that I rely on every day. I also object to labeling a whole class of people, many of whom are very smart, as "codemonkeys". Instead of programmer and codemonkey, I'll use the terms hacker and craftsperson as both are perceived positively. 

But Erik brings an important point to mind. Bad things happen when we don't acknowledge that hacking happens and that it's good. As Erik points out, sometimes, a creative burst of hackery is what it takes to get a new feature out the door or to build something that previously seemed impossible. And getting too uptight about maintainability at the wrong time can, ironically, make things worse.

Piles of unmaintainable code often result from failed well-intentioned refactoring attempts. In my previous two jobs, our HTML/CSS codebase had deteriorated to the point where it was unusable. Nobody intended that to happen. Some poor souls had, in months or years past, tried unsuccessfully to make the code maintainable. I could see vestiges of well-intentioned design patterns that had failed. Then someone kludged something to meet a deadline. Then someone else kludged. The cleanliness of the code disappeared, its founding principles were lost, and future programmers piled on kludges.

I found a colleague this week practicing a better approach. He was piecing together a new page and placed all of his styles in a <style> tag at the top of the page. He explained that he always started a page that way – by hacking his styles – and that he graduated them into reusable style sheets as development progressed and as he became more comfortable. He was sheepish and slightly apologetic about it. What he was doing intuitively felt wrong, and he felt that he was regressing to dirty tricks in order to meet a deadline.

His approach, though, is the only one that I've seen work. To make code maintainable, we needed to create a "hack zone" where unmaintainable code can live. My colleague used <style> tags for his hack zone. I create separate files for page-specific CSS and Javascript kludges. Our hack zones buffered the clean, reusable Javascript and CSS from hacks. And, as we gained experience with page-specific code, we often found ways to refactor it into our clean, reusable objects. Hack as we did, we didn't destroy the beauty or usefulness of our clean code.

Did we act as hackers? Did we act as craftspeople? We did both! Our goal is to improve maintainability, but, to make it happen, we need to leave some space for hacking. Over time, we'll rely more heavily on the clean, reusable code and less on the hacks.