Teaching a Webmonkey Old Tricks

I’ve been involved in web development, in one form or another, since 1994. Professionally, since 1996. During that decade and a half, I’ve built a lot of web sites. I think my career has been fairly consistent with most other web developers: long hours, lots of caffeine, constantly changing requirements, good, bad and truly horrid clients, and lots of typing.

When I started, you could build a web site with Notepad, WS-FTP, and Microsoft Paint. HTML was so new that you could charge upwards of $90/hour to code HTML 1.0, just because no one knew how easy it was to learn. Those days are gone. Long gone.

Web developers are becoming so specialized in particular areas that there are few generalists left with deep knowledge across the entire spectrum of web technologies. I expect increasing specialization as mobile, e-readers, and desktop browsers proliferate and become more technically diverse.

But design and development doesn’t just cover ‘hard’ technologies, but also ‘soft’ topics like process, management, and advocacy. In these areas, real-world experience is the only way to learn.

I’ve learned a lot, but always feel that I’m still at the tip of the iceberg. These are a few of the things I consider truisms in web development.

Content Management Systems don’t manage content. People manage content.

I’ve heard a lot of thunder from salespeople regarding CMS products. Don’t believe the hype. CMS’s only do two things: store content in a database, and manage workflow. If you don’t get the workflow right, no one will use it.

What have you forgotten? Help stamp out bravery.

These two phrases come from Arthur C. Clarke’s novel Rendezvous with Rama. The captain of the Earth spaceship sent to investigate the alien vessel put them on a plaque on his bridge. They were meant to remind his crew that every mistake in space was deadly, and that stopping to think and review before acting almost always yielded better results and drastically decreased errors. These two phrases have been my development mantra for a long time.

No process fits every occasion.

I’ve worked in many companies, with many different processes; some home-grown, some adopted wholesale from vendors and process gurus. I’ve done XP, RUP, and various home-grown Agile processes.

I can tell you from experience that all of these fell down when applied to projects to which they did not fit. I don’t want a pacemaker made by an extreme programming team, and I don’t want a micro-site built with the Rational Unified Process. These processes don’t fit the tasks.

I’ve come to look at process as more of a cookbook of techniques than a rigid, standardized dogma. Organizations will need to pursue projects that come in radically different levels of size and complexity, and choosing the right process will increase the chances they actually get completed. Something like RUP for major infrastructure projects that last years, something like Agile for projects that last weeks or a few months.

90% of all project meltdowns are communication breakdowns.

I can’t count the amount of times that simple things like ‘header’, ‘footer’, or ‘call-to-action’ have meant different things to team members, managers and the client. Likewise for any type of animation, steps in filling out information, or what happens when errors are encountered.

In this area, there is really no way to lay blame at anyone’s doorstep. Everyone building the web site needs to own how requirements are communicated. Otherwise the wireframe, mocks, prototype, content deck, and finished product will all look like they belong to different projects.

The only advice I can give is:

• Make sure terms are repeated throughout every stage of the project. If you start off calling the main navigation area of the website ‘header’ in the wireframes, everybody needs to refer to it that way, even the client.
• Always repeat back what’s been said to you. Repeat until everyone knows what’s going on. It sounds silly, but it works.

It’s called The Bleeding Edge because it makes you bleed.

There is a profound amount of satisfaction in being first-to-market in a new technology area, in doing something nobody else has yet pulled off. If this is what turns your crank, there are hundreds of fly-by-night start-ups that will hire you to work long hours with minimal pay and stock options that may never materialize. Knock yourself out.

But the great swath of web development projects available now are middle-of-the-road or maintenance projects. This is where most webmonkeys are going to be spending their time.

And there are advantages to being last. The Touch line of products from Apple (iPhone, iPad, iPod) are not really that innovative, if you look closely. All of the hardware technology (accelerometers, touch display, wireless connectivity, SMS, SSD, etc) are not recent innovations. Apple waited for these technologies to mature, and made the value-add the operating system and application/content ecosystem. In this way, being the last to market has made Apple winners in the mobile space.

Frameworks and tools are almost never important. Good style always is.

Right now, a lot of developers who just read that are planning my demise. I’ll just have to out-run them.

Everyone has their favorite editor, IDE, framework, server architecture, or doohickey of one form or another. They are all designed to make your life easier. Some actually do. A lot don’t.

For the most part, this comes down to the nature of development itself. A good tool is optimized to do one thing well. By this virtue, it will do almost everything else poorly. It’s possible to create tools that work well together (the Unix command line, for instance), but you have to remember that tools will perform poorly outside of their core competence. This goes for frameworks as well.

As a website evolves, the tools and frameworks needed to keep it healthy will evolve as well. The server framework that you started with will probably not work as well when the site has expanded to ten times the size it was on launch. When a tool or framework doesn’t fit the solution space, ditch it.

Good style, on the other hand, almost always pays dividends, no matter what you’re doing. Good style includes guidelines for writing content, programming style guides, and guidelines for documentation. Enforcing good style not only allows developers to use different tools on the same files, but also cuts down on confusion. Once developers get used to the house style, it’s easier to spot errors, read unfamiliar code, and maintain a sense of pride and ownership.

Style, like process, has to fit the organization. If your developers are geographically distributed, don’t speak a common language, or have radically different skill levels, your style guide will have to accomodate this, or it will fail.

One last thing: style is arbitrary. Don’t get sucked into the One True Brace Style arguments, and other flame wars. Just pick something and stick to it.

History is important.

I’ve worked with many developers whose primary source for information was blog posts, forums, and other internet watering holes. These folk were always up to speed on the latest developments, could type for days, and were brilliant console cowboys who could perform miracles.

And their code was always unformatted, littered with minor errors, and broke with the next major browser upgrade. They also had no patience, and regarded process with contempt.

Know your history. Read books. Know what has come before. You don’t have to become a computer science archaeologist, but knowing the history of your craft will not just deepen your appreciation for it, but give you a richer toolbox of techniques to employ when building software.

Exceptions should be exceptional.

I’ve worked with a lot of graphic designers and information architects. My mileage has varied (but we won’t name names, here). But, often, they were just typing up demands dictated by clients, instead of being allowed to, you know, do their jobs. So, fair play.

Consistency is probably the biggest development advantage you can have. Every time you can code something once, and reuse that code on every page of your website, you win in terms of performace, maintainability, and cost of change.

Every minor exception to layout or behavior is not just something that has to be built; it has to be maintained. Every line of code you can eliminate is a win.

Pay your respects.

Open a text editor right now. Type the following:

• Thank you.
• Apologies.
• Thanks for your help.
• Appreciated.
• My mistake.
• Are you available right now?

It didn’t take long, did it? Every one of those phrases are political, make no mistake. I’m not advocating ruthless politics here, but every time you make the effort to add a measure of civility to your communications, it’s remembered. And you can bank on it when you screw up, need help, or want a favor.

You will encounter some folk who are immune to all forms of politeness. You will also encounter serious assholes. But…you’ll always encounter these people. For most everyone else, banking some goodwill will smooth out the truly disastrous days you will encounter as a web developer.

One other note: if you’re forced to do something because of a management decision, say so up front. Don’t take the heat. They made the decision. It’s why their job title ends in ‘manager’ and yours ends in ‘developer’. Explaining where a decision originates goes a long way to fixing it if it’s broke, and celebrating it if it’s gold.

And a slim bibliography.

There are hundreds of books on languages, frameworks, processes, tools, gee-gaws, and what-not. The following are not about the technical bits, which get outdated fast. These are the books I consider classics, and will help long after whatever technology you’re using now is gone.

The Pragmatic Programmer. Andrew Hunt and David Thomas.

This book surveys the field of software development, from career development to debugging practices. It is highly readable, and the best book on the craft of software development I’ve read.

Facts and Fallacies of Software Development. Robert Glass.

Facts and Fallacies is written for a general audience, and this is a gift for your manager if I ever saw one. Covering software management more than development, it discusses many of the verboten topics that are glossed over in many of the process meetings I’ve attended over the years.

Web Style Guide, 3rd Edition. Patrick Lynch and Sarah Horton.

This is still the best guide to building a web site I’ve ever read. It has gone through many editions over the years (there were 3 online versions previous to the print edition, making this actually the 6th edition!), and although dry in some parts, it has the most common sense you will find on the process of building a site.

The Martian Principles for Successful Enterprise Systems. Ronald Mak.

This is a guide to building middleware, by the chief architect for the Collaborative Information Portal for NASA’s Mars Rover mission. This is simple common sense in creating architecture and managing teams.

The PC is not a Typewriter. Robin Williams.

Alternately, The MAC is not a Typewriter (the only difference between the two are the keyboard shortcuts listed). This will not make you a typographer, but it’s brevity is unmatched, and gives you the absolute basics for professional typesetting.

The Elements of Style, 4th Edition. William Strunk, Jr. and E. B. White.

This classic guide to English grammar and composition is something I re-read every few years. It’s the best book on the topic. Period.

The Elements of Java Style. Rogue Wave Software.

Modeled on The Elements of Style, The Elements of Java Style is the model I would advocate anyone building a developer’s style guide to take. Although there is extensive information that is solely confined to Java, the rules in the first half of the book could be retro-fitted to almost any programming language (there are two more books written by roughly the same authors for C++ and C#).

I’ve seen many ‘style’ guides that are simply a cookbook of recipes, or have so many rules that you will never get anything done. The Elements of Java Style is a good compromise between too many rules, and too much generalization. Teams using this style guide still have plenty of room for personal style, while maintaining consistency.

I consider it a classic, and it’s highly recommended.