Top excuses for bad design

Roger Johansson over at 456 Berea Street has posted a really great rant on lame excuses for not being a web professional. It's a great read for any developer (of any type) who takes pride in his work.

My personal favorite excuse is the "HTML-challenged IDEs and frameworks." It always seems odd to me that back-end developers can look down on the front-end web designers as "not real programmers" and yet be utterly incapable of writing anything even close to valid markup. Sometimes they don't even seem to aware that there are standards for HTML. They have the attitude that "it's just HTML," that it's so simple as to not even be worth worrying about. "Hey, FrontPage will generate it for me, so I'll just concentrate on the important work."

This is fed by the "the real world" and "it gets the job done" excuses. The "target audience" excuse even comes into play a bit. After all, nobody in the real world worries about writing HTML by hand. Especially when FrontPage gets the job done. And since our target audience all uses Internet Explorer anyway, it's all good.

This sort of thinking is especially widespread in the "corporate IT" internal development world. For example, if Roger ever saw the homepage to my employer's "intranet," he would fall over dead, having choked on vomit induced by the sickeningly low quality of the HTML. The index.html page contains an ASP language declaration (but no server-side script in, oddly enough - probably a relic of a Visual Studio template) and a client-side VBScript block before the opening HTML element. Several of the "links" on the page are not actually links at all, but TD elements with JavaScript onclick events to open new pages. For that matter, it uses tables despite the fact that it's laid out as a couple of nested lists of links. Needless to say the markup doesn't even come close to validating against any DOCTYPE. And this was written by a senior programmer who fancies herself the "local expert" on web development.

I guess it's just a problem of mindset. Some people just want to get the project finished and move on. They don't really care about code quality, maintainability, interoperability, or any of those other little things that make for really good software. As long as the customer accepts the final product, everything is fine.

While I don't share that attitude, I can sort of understand it. I'm interested in software development for its own sake. I care about the elegance and purity of my work and enjoy trying new technologies and learning new theories and techniques. But to some people, programming (or web design) is just a job. It's not a hobby or part of their identity, but simply a way to pay the mortgage. For those people, it's probably hard to get excited about semantic HTML or the efficacy of object oriented programming. As long as they get the project done and get paid, that's really all that matters.

Of course, that's just an explanation. It's no excuse for professional incompetence or unwillingness to learn. If you're going to call yourself a professional, I think you have an obligation to at least try to keep up with the current technologies and best practices in your niche. Not everybody has to be an ├╝ber geek or an expert on the latest trend, but it would be nice if all web developers were at least aware of the basics of web standards, all CRUD application developers knew the basics of relational theory and that XML is more than just angle brackets, and all desktop developers had some basic grasp of object orientation. Yeah, that would be really nice....

You can reply to this entry by leaving a comment below. This entry accepts Pingbacks from other blogs. You can follow comments on this entry by subscribing to the RSS feed.

Add your comments #

A comment body is required. No HTML code allowed. URLs starting with http:// or ftp:// will be automatically converted to hyperlinks.