Code warrior

Just this past week, I found myself in a position that was familiar to me from days gone by, but at the same time a little unsettling and unfamiliar. It was 2 a.m. and I was staring at a computer screen, a stack of O’Reilly books at the ready, half a dozen terminal windows open on my computer desktop, starting at an httpd.conf file in the vi text editor. I was writing code again.

Several weeks ago, I wrote that one of my New Year’s resolutions was to write more code because it keeps me closer to the technology I manage every day. I got started on that resolution this week when I chose a harmless project that wouldn’t burden InfoWorld’s IT staff: I decided to build a database-driven Web application on my laptop to search and display metadata from my MP3 collection. I just wanted to get my hands dirty again, but intensely re-engaging with the code for a few days gave me a nice refresher on what it’s like to write code day in and day out.

Although I have been actively using open source software for well over ten years now, the high quality of the code available and the decentralized but tight organization of open source projects continues to amaze me. I used to spend a lot of time hacking Perl code, so I chose Perl as my development language for this project. As I got started, I spent a good deal of time browsing Perl modules in CPAN, the Comprehensive Perl Archive Network. If you’ve never been a Perl developer, you might not know about CPAN, a veritable treasure trove of modules and libraries to handle almost any programmatic task you can imagine, usually with solid documentation to boot. Need code to convert any date string imaginable to any other date string imaginable? Date::Manip will do it. You can easily set up persistent database connections from Apache to MySQL using Apache::DBI.  There’s even a module available in CPAN to automate building modules from CPAN itself. For those of us who think that a solid programming environment consists of caffeine, a stack of reference books, a Unix text editor, and a simple scripting language, this is a fully realized environment.

As I battled the usual Web development hassles — arcane Apache configurations, file permissions issues, debugging bits of code — I also appreciated the value of working within a team just a bit more. Although I’ve eased into management, I still write scripts here and there and pitch in with a little sys admin help now and then, but it had been a while since I had attempted a complete coding project on my own. When you’re working within a functional technology team, the others in your group can challenge your assumptions and help you write better code. Methodologies such as Extreme Programming validate this approach — it does work.

Finally, this “little” programming project is taking me longer to finish than I initially planned, and I’ve only implemented about half of the intended functionality. What happened? Well, the angel on one shoulder (my inner developer) kept arguing with the devil on the other (my inner product manager), and the temptation to add more functionality kept pushing the finishing line farther out. I got unnecessarily hung up on UI issues, initially deciding that I wanted to use stylesheets for the Web pages in my applications, then I got bogged down on the relative merits of Courier versus Helvetica fonts. The lesson: Focus on the important requirements and don’t waste time with unnecessary cosmetic issues, especially in the early development phase. And now, it’s back to the code for me.