There's no room for Ego or Zealotry in Software (especially on the web) #
For the last several years, there’s been a lot of talk about why web standards are generally a good thing. And I agree with the vast majority of it. Writing clean code that sticks to a widely accepted standard is a very good way to help the future programmers who will invariably be touching your stuff once you’re gone (or yourself fixing a bug next month or year later.) In this sense, web standards are a sort of “kindness in coding.”
However, as with the OOP zealotry that started 20 years ago and is still going strong today, this set of very useful guidelines has turned into a movement. It has gained enough followers and momentum, and in many cases, seems to have become and End In Itself.
Movements are like organisms. They survive because the cells that make them up all continually and unthinkingly chant the mantras and make the arguments. Ideas can be good. Critically examining them is good. Being passionate about a good idea is good. But movements, more often than not, become problematic.
Software is the most complicated thing that humans build, and we haven’t really figured it out. You could even make the argument that we probably never will fully figure out how to create software in a way that doesn’t suck to some degree. That’s not to say we don’t create some great software, great websites, great programs, etc. But there are always bugs, and delays, and general chaos along the way, and I believe that there always will be. The process involves an unknown number of unknowns. Software is more complicated than the human brain can handle, and that’s the only kind of brain that we have.
So, how do you solve a problem when you don’t know all the factors, and only have a vague idea of what success looks like? It’s like climbing a mountain when you can’t see the top. You can still see the slope, and can occasionally get glimpses of where you’re going, or at least, you know that it’s higher up. If we are to approach quality software, then we must treat this exceedingly complicated problem in a manner that at least approaches quality heuristically, perhaps organically.
Software is a process of making decisions, and then codifying and saving those decisions. Bad decisions must be pruned ruthlessly, and good ones must be recognized and reused. In a general sense, this is the heuristic that leads to quality software (or quality anything for that matter.) The question of what makes a decision “good” or “bad” is itself a decision that needs continual evaluation. And that’s where movements get into trouble.
It’s easy to say, If it conforms with the w3c’s (or Microsoft’s or whoever’s) standards, then it’s good.
I think that this might be a good start, but it’s basically an argument from authority. The w3c is a group of humans. So is Microsoft. Humans make mistakes, and have plenty of limitations; that’s why we need a heuristic in the first place.
It’s also easy to say, If it loads fast and looks right, then it’s good.
Sure, but how easy is it to debug it when it doesn’t work as expected? Can new developers add to it easily? Is it expensive to maintain or re-purpose?
Or, even worse, This was written in (Rails, VB, Django, PHP, C#, valid CSS) so it’s good.
I think that a lot of the worst examples of Microsoft horrors were the result of a fanatical attachment to Visual Basic. I’ve seen (ok, “written”) some terrible CSS that was, nonetheless, technically “valid” according to the W3C’s validator.
Sadly, most developers judge decisions based on their feelings rather than any kind of objective analysis. I wrote this, and it’s clever, and it makes me happy, so it’s good.
There is no surer way to end up with a pile of garbage than this approach. It’s hard to let go of something that you worked on, and coders are certainly not the only culprits. I’ve seen execs spend countless hours on a deal that never yielded any value for the company, and designers fight tooth and nail for a visual approach that just didn’t work. Hell, we all have a relative or two with a recipe for something that they love, but which everyone knows is terribly bland.
It’s really really hard to let go of this emotional attachment to work. The reason we feel good when we succeed is that our emotions are attached to our work. It’s why I get up in the morning. But it’s better to attach your feelings to how harsh you are on your code. Understand that we all write terrible code, but that the difference between bad and good is that good coders recognize this fact and deal with it.
Because of the incredible complexity in software development of any kind, there simply is no room for mindless zealotry or attachment to a movement. Every project, every site, every module is a little different, and has a slightly different standard of quality. (Even the rule “always head upwards” doesn’t work for climbing all kinds of mountains.) Keep the goal in mind, and think about the best way to get there. Sometimes it’ll be the accepted standards, hell most of the time it probably will be, but sometimes it might not. It’s our job to know the difference.
Every once in a while, take a moment to re-evaluate your methods for evaluating the quality of your code. You may have to let go of something comfortable, and it may sting, but in the end, you’ll be better at what you do.