Hackers in a Decade of Limits

The following commentary originally appeared in American Programmer magazine. In the context of this commentary, the term "hacker" is used as it was back in the day -- to connote someone who insists on building software is an undisciplined manner.

Aah .. the 1960s and 1970s - my formative years. Growth and opportunity, free love and mind expansion, JFK and Motown. The terms "downsizing" and "outsourcing" hadn't yet been coined, reengineering didn't apply to computer software, and anyone who talked about the "decline and fall" of American programmers would have been certifiable. It was the age of hippies and hackers.

But times change. We're now living through the decade of limits. And sadly, those limits have reached many software development shops. Few organizations have escaped downsizing and outsourcing, demands for measurable "process maturity" (e.g. SEI models or ISO 9000 standards) are on the agenda, so much software needs to be reengineered that we choose to ignore the problem and hope that it will go away, and The Decline and Fall of the American Programmer became a best selling book. [Recently, a sequel, The Rise and Resurrection of the American Programmer was published. Maybe there's still hope!]

And yet, like aging flower children who still believe that LSD holds the answer to the universe, a cadre of software cognoscenti continue to insist that hacking is the way to create "important" computer programs. As we used to say in my formative years ... bummer.

I think the allure of hacking has something to do with our desire to view software as an extension of human thought - free and unbounded. Like an artist, the hacker "creates," unencumbered by any rules, unfazed by technical problems, and unrepentant when others can't understand or extend the software art that has been created. We often use the term affectionately, as if every hacker created programs of lasting value - programs that were defect free, maintainable, portable, and effective. But I've got news from the trenches, that kind of hacker is extremely rare.

Sure, there are true software wizards - hackers who whip out 40,000 lines of defect free, real-time operating system code per week. Do we really want to turn them into software engineers. An honest answer is "no." The true wizard is not a hacker, he or she is gifted with the ability to create prodigious works while operating outside the bounds of conventional discipline. Leave 'em alone and let 'em create .. any way they want. We all benefit.

The problem isn't with the wizards, who probably represent less that one-half of 1 percent of the software population. The problem is with the other hackers who think they're great artists but are actually more adept with crayons than paint brushes. They're the ones who contribute to many of the software problems that we face today. They're the ones who build programs that are unmaintainable and unreliable. They're the ones who would benefit if they transformed themselves into software engineers.

Software engineering discipline would channel the hackers skills. They'd work in an environment in which principles of good analysis and design are more important than the latest esoteric syntax quirk in C; they'd learn that quality is something that can be measured while you're working, not something that can only be determined after the product is delivered; they'd learn that engineering discipline doesn't constrain creativity, it merely channels it so that others can tap into the flow and contribute as well.

The 1990s are a decade of limits. If we don't limit the negative impact that hackers have on system quality, if we don't convert them to a more engineering-oriented process, we probably won't have to worry too much about the decade that follows this one. Downsizing and outsourcing will be used (unwisely, I think) in an effort to rid of us of our software problems. Hackers will lose, but many good software engineers will be swept up and discarded as well. And that would be a shame.



Home About us Products Product Models SE Resources Commentary Contact us
Web site and all contents © 2006, R.S. Pressman & Associates, Inc.
All rights reserved.

Free website templates