Published 7/13/2005

The nuns of St. Camillus pounded all sorts of interesting ideas into the heads of us grade schoolers. Some will no doubt come out in the inevitable therapy sessions I'll need to get my kids through teenagerhood. Others, though scary at the time, make for good stories today.

"Guardian Angels" were the nuns' invisible avatars, always watching over us, often helping us, sometimes recording black marks in that cosmic book of personal errors. No doubt my guardian angel is a UNIX guru, working full time just to keep the sheer volume of my black marks from crashing all of heaven's database engines. "Reboot heaven? Y/N?"

The nuns neglected to tell us we're each others guardian angels. Parents watch over their kids with a wary eye no supernatural creature can match. Spouses look out for each other's interests. Friends in need are friends indeed.

These thoughts bubbled to the surface when I asked an engineer to recode a few functions in assembly language. The system worked great but just seemed a bit slow. Some analysis uncovered a busy interrupt service routine, supported by a couple of equally stressed main-line subroutines.

I wasn't looking for much speed - a 20 or 30% improvement was more than enough to give the system a snappy feel. Why not translate a bit of code to assembly and be done with the problem?

The engineer's boss collared me, and in no uncertain terms said "No!" Though he knew that the translation would work, he figured the resulting assembly language - the only non-C code in the system - would reduce the system's maintainability.

He was the system's code guardian. As such he had the authority - and the common sense - to ensure we don't do dumb things that erode any aspect of the software, software we've invested in in a big way. Though I might disagree with his approach, he watched over his code like a parent over children. He protects it from the whims of marketing types, and from expedient solutions like mine.

The code guardian is the quality angel. When a dozen approaches will all work, the code guardian selects one that most closely meets the needs of the customer, yet that preserves the software's integrity.

Every project needs a code guardian. Usually this should be the team's highest-ranking technical person, someone with the authority to say "This stinks! We're not going to do it this way!" The code guardian needs the freedom to do work management might consider non-productive, like instituting version control systems, developing and maintaining software standards, and sometimes rejecting working routines that just don't measure up to his or her demanding standards.

It's hard to chuck working code. But sometimes it's simply the right thing to do. The Code Guardian has the guts - and support from management - to make these hard decisions.

It never ceases to amaze me that companies hire huge accounting staffs to guard financial performance, and security firms to protect physical assets, yet seem to neglect the critical importance of their software. Since you can't see or feel code, management leaves it on its own to wither or thrive, protected only by the techies who understand it.

The role of the code guardian is to protect the software from outsiders (marketing) as well as from the developers themselves. Most projects start with the best of intentions: code reviews, structure charts, careful design are our mantra when delivery is a year away. After a few schedule slips, with the deadline looming, it's all too easy to abandon a reasonable methodology in our panic to get a product out the door. The code guardian institutes a discipline of methodology. He or she becomes the code Gestapo as the crunch hits, insuring that things are done right. Bad code always comes back to haunt us.

One tenant of eXtreme Programming is "code that can be improved, must be improved." XPer's refactor mercilessly. In a sense everyone becomes the Code Guardian. Though I worry that unrelenting refactoring fulfills that much-reviled (by managers, at least) engineering need to fiddle with a product forever, I admire the XP idea of keeping a clean code base.

What do you think? Is the integrity of the code important enough that someone has the authority to reject expedient but ugly shortcuts?