The message is: you don’t have to be perfect. You just have to be agile and good at what you do.

In the early days of the graphical Web, everybody was a generalist, mainly because the technology wasn’t moving so fast that keeping track of everything required full-time attention, but also because the standards for excellence were much lower. As the web matured, the market inevitably encouraged the rise of specialists – programmers, database developers, UI architects, graphic designers, etc.

But some of us refused to give up our ‘webmaster’ titles and kept learning, kept plugging along, incrementally gaining experience in a range of different disciplines. We loved to learn and studied design, usability, programming…

Clients called us ‘webmasters’; we consulted, designed, developed, hosted & publicized their sites. For a brief time, we enjoyed the grand spotlight at the top of an emerging industry.

And then the specialists caught on. We generalists explained (time and time again) to the print designers the limitations then inherent in working within the web medium. We lost footing to old school programmers who’d adapted to web programming, replacing our Perl and PHP with C, Java and bringing words like ‘enterprise’ with them.

But what we really lost in that initial rush toward specialization, toward the creation of an ‘industry’ out of a collection of enthusiasts, was the simplicity of having just one, or only a few, knowledgeable people working tightly, quickly and effectively to create web presences. The technology had barely escaped its text-only confines when it exploded in popularity; we generalists had built these sites from scratch, had discovered (on our own most likely) the painful limitations and Byzantine workarounds necessary to get around them.

And when it came to designing sites, we could communicate sensible guidelines to the designer because we were the designer or we worked right next to him.

What happened when suddenly it took a whole agency to build a site?

“It’s Gonna Take a-Money… a whole lotta spendin’ money…”

A few things happened when the web specialized and agencies emerged as the dominant web development force. The first, most obvious, is that costs skyrocketed. What used to take one to four skilled people now required:

• a designer,
• an HTML producer,
• a developer/programmer,
• (later) a UI architect,
• a client representative,
• a creative lead,
• a project manager,
• an office manager,
• human resources officers,
• etc., etc., etc.

“To do it – To do it – To do it right, child”

The second, but more insidious side-effect of the rise of specialists? Focus on initial perfection, one of the single most deadly mistakes of many companies who set their sights on the web (both brick & mortar companies moving their operations onto the web and internet-only startups).

As the Internet ‘Bubble’ expanded, we all rushed to be first-to-market. At the same time, the companies we worked for urged this ideal of initial perfection. Not only did we have to build faster than anyone else, we also needed to create the end-all, be-all web service that everyone and their mother would use every day.

That’s an incredibly dangerous way to go about building software; throwing more money at more people and more management with less time is the perfect way to build a product that looks great, sound great, and serves nobody adequately. It’s also a great way to burn through a tremendous amount of cash in a very short time, all because the company pursues what is really a false ideal.

Great Tools Don’t Appear, They Evolve

‘One point oh’ releases of software generally serve their own developers and designers more than anyone else; and if they don’t, that’s because the software builds on the knowledge learned from the tools that came before. The feedback of users helps create tools that solve real-world problems.

So when companies rush money into what amounts to a closed-door, black-box development process, they base their application on what they perceive to be the market’s required features, workflow, etc., not what really works for the users. (This is one reason that UI architects and usability studies have become so important in the development process.) When these applications finally do reach market (often over-budget and behind-schedule), they are forced to adapt quickly to the realities of user expectations and desires, or die.

Most die.

Admittedly, there are a few exceptions to any rule, but when we look closer even those exceptions seem to yield to an evolutionary interpretation. Apple’s iPod, for example, arrived out of left field to take the portable music player world by storm. So many of its elements seemed new and innovative, but on closer inspection we realize that MP3 players existed before the iPod, and that many of the features it offered had been present in various ways on the market before. Apple’s genius and innovation wasn’t in the black-box development of a brand-new product, it was in a deep understanding and unprecedented attention to what people wanted and what they didn’t need.

And you know what? Even Apple has found ways to improve on the iPod, by melding new technology with strong attention to user wants and needs.

But what’s the alternative? How does a company get to market quickly with a great product that everyone will use?

That’s easy. Start simple. Build the core of your product or service and get it out there. Add your features and complexity over time. Get feedback and improve your work based on real-world use. “37signals”:http://37signals.com/ does this, almost to a fault, with their web applications. As part of their own philosophy, they often espouse these very same ideas on their blog.

Instead of burning through money at a breakneck pace, trying to create the perfect application, you’ll spend money as needed, and the product you create will be tailored to the people who form the base of your business much more effectively than if you did everything behind closed doors.

The message is: you don’t have to be perfect. You just have to be agile and good at what you do.

“What,” you cry impatiently, “does this have to do with the return of the generalists?”

A New Hope

Small or one-man teams of multi-talented web developers require different development processes, almost by default, than do large agencies. Projects of any size are often worked in series, not parallel, and the scope of these projects, due to sheer person-power, don’t approach the gigantic scope or complexity of agency projects.

At SxSW 2005, Jason Fried of 37Signals encouraged hiring generalists in his talk on “How to Make Big Things Happen With Small Teams”:http://www.37signals.com/svn/archives2/2005/03…. Why? Generalists bring a stronger understanding of the development process as a whole. Well-rounded developers take part in the entire process, instead of being thrust into ‘boxes’ and fulfilling some of the ‘arrows’ in the creation of a product or web service. Furthermore, generalists have gone through the process of learning multiple times: they’ve got it down to an art form… Learn what’s necessary to use a tool in the real world, use it, and repeat.

Small teams benefit from less complexity and more iterative processes than large teams. Where traditional programming models progress from idea through a linear development process to testing, bug-fixing, and release, the more agile techniques used by generalists focus on building a product’s core features first.

In the same way, Java frameworks have enabled those traditional development models, while newer frameworks like Ruby on Rails almost enforce a more agile practice. (To be fair, much of the XP world writes its example code in Java and there’s little or nothing inherent about Ruby that makes it more agile than Java. I believe the relative newness of the framework and the opinions of its developers has more to do with the popularity of agile methods among its proponents than does the language itself.)

The web development celebrity world is filling up with generalists: Shaun Inman, 37Signals, Clear:left, Dan Cederholm, and many others… The new agencies that are springing up comprise themselves not of a dozen individually spectacular specialists, but instead of a handful of strong generalist developers.

The point? Save money. Develop more quickly. Create insanely great products. Generalists have been around the longest, they’ve got the greatest passion for their jobs, they know how to learn, and they understand how to build solutions for people, not just users.

And yes, I’m a generalist. So I’m biased. Hire me, or enlighten me. That’s all I ask.