Unquiet

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 and 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 just a few, knowledgeable people working tightly to create web presences quickly and effectively. The technology had barely escaped its text-only confines when it began to explode 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 as well as 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 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 later became so important in the development process.) When these applications finally _did_ reach market (often over-budget and behind-schedule), they were forced to adapt quickly to the realities of user expectations and desires, or die.

Most died.

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][1], for example, arrived from 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 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, but instead in a deep understanding and unprecedented attention to what people wanted and what they didn’t need.

[1]: http://www.apple.com/ipod/

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. The new iPod nano offers a great example of this.

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][2] 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.

[2]: http://37signals.com/

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][3]. Why? Generalists bring a stronger understanding of the development process as a whole. Well-rounded developers can 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.

[3]: http://www.37signals.com/svn/archives2/2005/03/sxsw_2005_prese.php

Small teams benefit from less complexity and a more iterative process 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 and DHH, Clear:left, Dan Cederholm, and many others whose names I simply can’t recall at the moment. 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.