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.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
