Good Code — Bad Code

HTML is like gears and pulleys for your website. It's hidden from the casual observer but it's what makes your website GO. Without it, your site might as well be a printed flyer or billboard. Unlike visual design, where good and bad are largely matters of opinion, HTML is easy to qualify and easy to measure.

Good code is characterized by efficiency, elegance, and stability. Bad code is revealed in slow downloads, difficult updates, unnecessary complexity, and frequent errors.

Good code makes your customers happy by making your site quick to view, more responsive, and consistent in its behavior. What's more, solid HTML makes the site easy to maintain, easy to update, and light on bandwidth.

Good HTML isn't a luxury.
It makes you money.
It saves you money.
It pays for itself.

Case-in-point

When we were asked to rebuild Aequitas Capital Management, we inherited a site that was originally built overseas in Russia. The site was run on a (literally) byzantine system of database tables, undecipherable administration utilities, and totally undocumented code. Fully 2/3rds of the files in the site were not in use, making maintenance and expansion a brutal chore. In the programming world, that kind of code is known as 'job security.'

First of all — organization. Code-Monkeys has developed a proven process of project flow and organization that ensures timely, and efficient future development. This system focuses on common-sense rules for naming files, organizing graphics and source documents, and minimizing extraneous data. Poor organization alone can make a site a maintenance minefield.

Our next goal — simplification. It's not uncommon for HTML to be more complicated than necessary, particularly when pages are developed with WYSIWYG editors like FrontPage or GoLive. In this case, we were dealing with a programmer who thought more about his own chops than he thought about his client. As a result the site had been cobbled together as he learned new tricks. Our goal was to cut off all the dead wood, streamline the maintenance of the site, and create a codebase that facilitated both our own work, and the work of any future developer.

Finally — modularization. When significant blocks of code are repeated across multiple pages, like a common header, it makes sense to break these pieces out as "include" files. In this way, changes or repairs to these elements can be made once for the entire site instead of once per page. Other modularized elements include Dreamweaver templates, Photoshop templates and Flash templates. Each time we avoid baking in elements that are likely to change over time, we save money in the future.

None of this is rocket science to any competent web developer, but it's like flossing. Everybody knows they should do it, they say they always do it when asked, but they almost never do.