Have you ever heard anybody boast about their site, or their client's site,
"And of course all our HTML is hand-coded and perfect. None of that bloated crap turned
out by (insert name of famous competitor here)"?
Whenever I hear this, my first thought is, "Strange, your competitor is
indeed famous, yet you're not." And I wonder whether perfect HTML is actually
an asset, or whether in practice it's more of a liability.
September 27, 2000
We're all working with limited resources. That's business. Apart from a few
daydreamers running ineffectual businesses into the ground, everybody in the real
world has to deal with limitations on the resources they can use. They can swap
resources from one aspect of site development to another, but they can't just
add resources every time they feel they could use a little more.
One of the skills of management is getting exactly the right balance on how
those limited resources are used. Should that bundle of ten thousand dollars at
the bottom of your venture capitalist's suitcase be spent on site promotion or
on hand-coding perfect HTML? That's a real choice faced by businesses every day. Perfect
HTML isn't free. It takes time and uses skilled personnel, therefore it costs
money - money that could be spent on something else instead.
My point is that there are many cases where it should be spent on something
else, that perfecting HTML is often not the best use of resources. To be fair,
there are also many cases where perfect HTML is worthwhile, and for mature businesses
that's probably most of the time, but for young businesses it's worth considering
the sloppy HTML option. It may be the only way to get through those lean, early
years and get to a stable position where you can start contemplating perfection.
A two percent budget shift from perfection to promotion in those early days may
mean the difference between success and failure.
In a young business, you know there's a chance you'll fail. If it's an Internet
business you can read the daily Internet news and see failure stare you in the
face. In those circumstances you have to work out which option most improves your
chance of success - perfecting your HTML or getting yourself in the public eye.
Or perhaps that two percent shift in resources gets you fresh content, or a usability
review, or more pages. Anything more tangible than fine code.
If you'd prefer a non-business example, think about a doctor working in accident
and emergency. It's a busy shift, they've got ten broken arms to put in plaster
and another three cases arriving every hour. Should they take care that all the
plaster casts are smooth and perfect (five extra minutes per cast) or just make
sure they're going to mend the bones properly, even if they look a bit messy and
bits of gauze show through (result: one extra patient fixed per hour)? I know
what the patient at the end of the line would say.
It's not a silly example, because perfect code is similar to the perfect plaster
cast. It looks pretty and has some small advantages in functionality (the smooth
cast won't catch on clothes) but it's not essential.
What's Sloppy
What do I mean by sloppy HTML? I mean HTML that works on the majority of platforms
but isn't perfect. It may just have a few extra useless tags that were inserted
by a WYSIWYG editor in the rush and chaos of design. It might have more than a
few. It certainly hasn't been optimized. Any decent HTML guru could probably cut
the filesizes down by ten percent or more.
It might even fail on a few platforms. Try browsing the Internet on a Mac kitted
out with an early AOL browser. Nightmare. But how much of your precious resources
should go into reaching that 0.1 percent of the Web population? (OK, 0.2%. Who
cares?)
I certainly don't mean HTML that fails on popular browsers. That's bad HTML
and a different case altogether. I just mean HTML that's a bit crinkly at the
edges and could definitely be improved - the kind of stuff churned out by most
Web editing software.
It's even debatable whether mature businesses need perfect code. Sure, it impresses
the techies when they look at the source, but then techies are a small minority
on the Internet these days, not the overwhelming majority they used to be a few
years ago. The great majority of visitors can't read HTML and don't have a clue
whether code is good or bad, they're just interested in good content and navigation.
And speed. Yes, they're interested in speed and that's a weakness in my argument
that has to be admitted. Perfect HTML loads faster than its sloppy equivalent
and that's an advantage. It's one of the few solid reasons why perfect HTML may
be worth the effort. But the question still remains, how much effort, and are
those resources better used elswhere?
Changing perception
Maybe it's time we reassessed the whole way we judge HTML - what we consider
to be good and bad code. Historically this has always been seen as a technical
issue, but in these harsher days for the industry perhaps it needs to be viewed
in more of a business light.
The reason why we take a technical approach to good and bad code is because
the early pioneers of the Internet were technically competent people, and that's
their way of judging things. But that scientific viewpoint is starting to look
a bit dated. We need something closer to an engineer's point of view. "If
it works and it's cheap, we'll do it that way."
Perhaps the next time you look at the source code of an up and coming site
and see all those extra tags that FrontPage has put in, or Dreamweaver, or even
Golive (v4), and which nobody has bothered to take out, you might take a moment
to admire the site's business priorities and say to yourself, "Hmmm, good
code."
