Code jag in Vegas

About two years ago, a funny thing happened during a stay in Las Vegas. Up against great implementation odds, I got in touch with my inner hacker.

A business deal had closed, and when the terms were related to me, I knew I was in trouble. The deal essentially had to be implemented within a couple of days, and there was no packaged open source or commercial solution at the time to handle the problem at hand. Turnaround time was extremely short. I surveyed my IT staff. Quickly, I realized I was the only person with the immediate domain knowledge of the kind of systems we were dealing with. Given little time to train internal staff or to even find an outside consultant to take on the task, I had no option but to do it myself. And to make matters worse, I was off to Las Vegas for a conference I couldn’t skip.

When I landed in Vegas, I hurried past the airport slot machines and hopped a taxi to my hotel, where I checked in, drew the shades, and began feverishly writing code, thinking, “Just a short-term fix — we’ll write better code later.” Oddly enough, my code binge was fun. Don’t get me wrong, I would have rather been hanging out in casinos. But in some ways, Vegas is a coder’s paradise. Nighttime becomes a mere abstraction — the fluorescent glare of the Strip reminiscent of the harsh, artificial light developers know well from working in rooms lit only by CRTs. Although I’m not a gambler, I suspect that the thrill of a 3 a.m. winning streak at the poker table is not unlike a successful 3 a.m. build of code you’ve been working on for weeks. Holed up alone, facing high stakes, I broke almost every software development best practice you can imagine: I wrote the code, tested it myself, rolled it out, and opened my shades. Fortunately, the code worked and the immediate problem was solved — just not in an elegant way.

Fried, I surveyed my work. It was rather incoherent and not particularly well-structured — the angel of the thoughtful object-oriented approach on my right shoulder had clearly overwhelmed the sneering procedural devil demanding lots of obtuse wrapper scripts and heavy-handed root privileges on my left. My reasonable manager superego had been subsumed by a vicious hacker id eager for the immediate gratification of code running on a production system. But again, it worked. Fast-forward two years, and that code is still humming along, although we have started running up against scalability problems. Thankfully, the one best practice I didn’t skip over was the one that is most often omitted: documentation. I had carefully described my thinking and essentially drew a map that described in great detail where all the bodies were buried.

There are a few lessons to learn from my freewheeling code jag in Vegas. First, when managers like me are writing code, something has gone wrong in the communication process and must be corrected. In this instance, the time between the signing of the deal and the implementation was simply too short. Second, if you get stuck in a jam where you have to write “temporary” production code, it probably won’t be “temporary,” so the least you can do is document your feverish hacking well enough for the inevitable cleanup later on. Well-documented but inelegant code is superior to completely undocumented but structurally sound code. Finally, sometimes you must write ugly code to get a job done. But if you think what happens in Vegas stays in Vegas, you’ve never written production code there. I don’t recommend it.