Technical Debt and UI

Technical debt (also known as design debt or code debt) is a neologistic metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. [Source: Wikipedia]

Way too often than I like. The HTML markup (UI) is overlooked due to the perception:

“HTML is easy. There’s no need to plan or care about the HTML markup. We can rewrite/build the entire UI from scratch in no time.”

This is partly true. But something we often forget is; we’re now in web2.0. We don’t have static “hard-coded” web pages any more. Now-days we have UIs that interact extensively with back-end system(s) via AJAX.

And if you don’t already know. It is mission-critical to have valid HTML markup; otherwise you can expect some really weird behavior from your JavaScript code – that’s provided that code does manage to run without throwing an exception.

The above is just the tip of the ice berg and most noticeably the most important too. But there are many more aspects we need to consider. Like for example:

Cross-browser support

To provide support for multiple web browsers AND web browser versions (not just talking about Internet Explorer here!).

Search Engine Optimisation (SEO)

Search Engine Optimisation/Support has become part of the standard package of any website build.

Usability and Accessibility

Along with SEO, usability and accessibility have joined the standard requirements of any website build.

Semantic Markup

Semantic web is what HTML5 is all about (if you’re a coder!). If you’re not using the new tags correctly. You midas well not use the new tags at all and just stick with the classic DIV and SPAN tags.

Flexibility to change

There’s not a single project that I’ve worked on that haven’t had its requirements / UI tweaked during the development phase.

So next time you write a piece of HTML. Don’t just look at the small picture. Look at the bigger picture. You are not just dealing with HTML. You’ve also got to work with both JavaScript and back-end rendering logic too. Which means, not just rewriting the UI, but also rewriting JavaScript and back-end code to accommodate a change – regardless of how big or minor the change is.

Here’s a few tips to help you on the way:

  1. use CSS for styling (preferably an external CSS file) – avoid element attributes.
  2. use external JavaScript files for JavaScript code – avoid writing inline JavaScript or attaching JavaScript event handlers via markup.
  3. don’t use html generators – especially Microsoft Word.
  4. less code is always better. (I remember the old days when I had double the amount of markup just to have rounded corners. Persuade your colleagues / managers / clients / stakeholders to adopt the Progressive enhancement approach.)
  5. manually validate your markup if your IDE doesn’t already do it for you. (W3C HTML4/XHTML1 – http://validator.w3.org/. HTML5 – http://html5.validator.nu/)