|Web Techniques Magazine
Volume 3, Issue 7
A Web site with any history behind it probably got started as a weekend or late-night project. Initially, it was no more than a home page, but it has grown and grown since then—all part of a continuous home-page improvement project.
As staffs and budgets for creating Web sites grow, Web work becomes much more professional and specialized. Today, the ideal home-page improvement project should have an architect, general and specialized building contractors, and interior designers. Much of this is good, and the end result better.
But as Web development expands, there’s a shift from a pragmatic, bottom-up development model to a comprehensive, top-down model. Information systems professionals are getting involved, now that the Web has proven itself as a platform. IS makes the argument that it can manage Web development just as it does other projects.
The idea may begin to circulate that the Web development team is a bunch of hackers who can’t be trusted with handling enterprise-wide Web development. What manager wants a “fixer upper” when IS promises a more polished information palace?
Even the original Web team members might feel that their own efforts have been inadequate. You might disparage the early, ugly version of your own Web site. It’s no longer cool compared to what you might do today. You can see where you cut corners when there was no budget for an information architect, or where the homegrown Perl-CGI script was workable, but you didn’t want anyone to look at it. You can tell that one or two people did most of the work and that often they discovered, late in the process, something they wished they’d known earlier.
However harshly we might critique our past work, Web developers need to place more value on the process that got us where we are today. We treat the process as something that’s broken, partially because we know that our knowledge is incomplete. Yet even a poorly built site may have been a useful learning experience.
Admitting that a site is a bunch of ugly hacks can be embarrassing, but it should also be a source of pride. A hack is a pragmatic solution to a complex problem, a solution that simply works. Moreover, hackers are good problem solvers who are continually teaching themselves how to answer tough questions.
The typical IS solution is often a mirage: The vision looks good but you’ll never get there. The fully integrated, enterprise-wide, unified Web solution—an idea pitched to executives by their current large-systems vendor of choice—will continue to lure managers. IS will do months of research, bring in the consultants, interview all the stakeholders, review all the commercial alternatives for each category of software, develop a detailed project budget, write an incomprehensible specification, and propose an implementation plan reaching out years into the future. Everyone is asked to be patient, and they have to be, just to see a working prototype. Soon, folks begin wondering how the Web team was able to produce a site so quickly on its own. (The best members of said team have since left the company to become expert consultants, now invited to bid on “I-can’t-wait-for-IS-to-make-up-its-mind” projects.)
In a book about software prototyping called Rapid Evolutionary Development by Lowell Jay Arthur (Wiley, 1992), Paul MacCready, inventor of the Gossamer Condor ultralight aircraft, was quoted as saying: “If it’s worth doing, it’s worth doing badly. If you can make it crudely, you can make it fast and it doesn’t cost much.” Virtually all early Web sites benefit from these “crude” design principles.
MacCready’s quote piqued my curiosity. I found a Web site that called him “Engineer of the Century” and had a long interview (www.achievement.org/autodoc/page/mac0pro-1). On the development of his human-powered aircraft, MacCready says:
“Looking back, we did it just right, as quickly as we could...we built a first version without even putting a propeller on it, just to see if it would fly, and about how much power it took to keep it up. Then we added a propeller and did a lot of tests with it. It was pretty crummy, very crude, bad stability and control and so on. But because we could rush it out and do tests with it, we began getting good insights about all its difficulties.”
What you learn from developing Web sites is more valuable than the site itself. You can always rebuild a site, and the experience you gain from designing and testing a site is what teaches you how to improve upon it in the future.
An organization needs to appreciate its self-taught Web hackers because if it doesn’t have any, it’s not learning anything important about the Web.
© Web Techniques. All rights reserved.
Web Techniques Magazine