Adopting a “Does It Really Matter?” Philosophy

As developers, we’re naturally obsessed with details, conventions, and semantics. There are only a few professions that I know of that will take the time to avoid moderate compromises like using conditional comment hacks or failing W3C’s auto-validation services; we’re in league with stalwart saints and by-the-books building inspectors. There’s nothing wrong with that, the nature of the job requires us to be perfectionists, if for nothing else than our fear of peer criticism.

And our peers are a harsh bunch – they’ll berate us for the div tag that should’ve been a block-styled h2 tag, or for creating a layout that breaks in Iceweasel 1.05. I know this only because I do it myself and because I’ve produced work that I’m not proud to say came from the fingers typing this same article. Some take this to extremes (and again, guilty as charged). You’ll find developers arguing, with hatred and fire in their eyes, why using the text-indent method is better than the Fark method for CSS background image text replacement, or profiling JavaScript’s for function versus jQuery’s each() method on a 10-liner code block.

Do our clients and project managers care? Probably not. This takes up time, quite obviously.

And in the real-world, this time is being paid for by someone. Recently, I’ve taken on a new philosophy in the way I build sites – a philosophy built around pragmatism and real-world demands. For lack of a better term, I describe it as “Does It Really Matter?” development.

Don’t get me wrong, you’ll still see me participating in minor-in-the-grand-scheme-of-things debates like structural naming conventions, but I do so on my own time and resources, not the project’s.

The “Does It Really Matter?” Developer

A developer that should use this attitude is one that is experienced enough to know that what they’re about to do may not be the best way to do it, yet still make a confident and conscious decision, based on reasonable and defendable factors, to break or bend the “rules”. There’s a blatant difference between a developer who knowingly goes against a standard, and one that does so out of lack of knowledge and/or of laziness. A DIRM developer will choose inline CSS styles versus external stylesheets if it means improved maintainability and huge performance gains, even at the cost of best practices in separating content and style. Using inline styles is poor practice, but it doesn’t break your site.

A DIRM developer will be able to answer his or her peers when he or she is grilled about their deviation from the norm. The DIRM philosophy isn’t for those of us that are just starting out. Beginners should learn the right way to do it before they can make an educated judgment call to go another route.

In other words, you have to be a good critic of your own work, and you should be experienced and knowledgeable enough to be able to stand up for your choices when it comes down to it.

The Process

This idea of DIRM development revolves around the fact that the more time we spend on something, the fewer things we can do. You can follow this philosophy just by doing one simple thing, asking yourself: “does it really matter?” The attitude you need is one of cooperation and willingness to compromise; you need to be able to live with bending the rules where they can be bent for the sake of productivity and efficiency.

DIRM development puts pragmatism and results over semantics and negotiable best practices. The general steps, then, to making a Does It Really Matter decision is:

1. Evaluating the need for a solution (does it really matter?)
2. Figuring out your options
3. Determining the realistic negatives
4. Guesstimating the benefits and returns

At each stage, you evaluate the negligible path of least resistance. In other words, before proceeding to the next level, see if there’s a solution that stands to offer the best return at your current juncture. All of this may sound highfaluting; like it has to involve a 10-page report reviewed by two managers, like it requires meetings-about-meetings, but it doesn’t.

For the purposes of illustration, we’ll take an example: dealing with PNG transparency issues in Internet Explorer.

Evaluating the need for a solution

Questions to ask yourself: Do I need to solve this issue? If I could have my way, what would be the ideal solution?

You probably won’t be doing something that isn’t worth your time, and it will always have value (at least to you). So a better thing to evaluate is, does it matter? Let’s say you have a Photoshop design mockup that involves image transparency.

The first thing you should do is evaluate the need for a solution before taking further actions. Looking at your designer’s mockup, does it need to use alpha transparencies, or can a few minor pixel pushing remedy the issue? Peeking into your site’s analytics and client requirements: is there a justifiable need to support older versions of IE?

If the answer is yes to both, then you need to move to the next level. Otherwise, our negligible path of least resistance is either not using PNG transparencies, or not supporting IE 6 users.

Figuring out your options

Questions to ask yourself: If my ideal solution can’t be met, what are my other options?

Which of my options/workarounds is the best? Which of my options can I realistically do? You can get elaborate with this step, defeating the whole purpose of the process by spending more time than you need to be committing to development.

9.57 times out of 10, the only things you’ll need are logical reasoning, your knowledge and experience, and effective Google searches. In dealing with PNG transparencies for legacy IE browsers, you have two major options.

• Go back to your designer and request for a revision
• Use JavaScript to simulate PNG alpha transparencies (a PNG fix)

If your designer is willing to change the design to eliminate the need for PNG transparencies, you’re done, you’ve chosen the path of least resistance. You’ve come up with a solution that doesn’t need a workaround, and one that won’t break web development best practices. Otherwise, we need to move on to the next level.

Determining the realistic negatives

Questions to ask yourself: What are the realistic and high-impact negatives of my solution? What sacrifices will I be making by implementing this solution? Based on experience, you know that the user can disable JavaScript so there’s going to be a small group of people with IE 6 and JavaScript disabled that will experience your web page in a non-optimal manner if you were to go with a JavaScript PNG fix.

If your interface still works, and the issues are mostly aesthetic, then don’t spend any more time worrying about those guys and we’ll have determined that this negative is “not so bad”, making the PNG fix our negligible path of least resistance. If, on the other hand, most of our users are IE 6 users with JavaScript disabled (a common set-up for financial firms due to security paranoia and IT failing to upgrade the systems to more recent browsers), then our negative is “significant”. In this case, the path of least resistance is going back to the designer and asking for revisions because the solution has to work for IE 6 and JS off, there is no other choice. Otherwise, we should evaluate the PNG fix solution for the benefits it will provide us.

Guesstimating the benefits and returns

Questions to ask yourself: Is it worth doing?

What do I get out of it? Compared to other tasks that need to be done, where does this one stand? Now comes the ultimate question: do you have the resources and capabilities to move forward?

There’s no art or science to answering this question (and if there was, there’d be no time for that mumbo jumbo), just take a stab at it and guess(timate). You know that you’ll need a PNG fix for the design and that the real-world negatives are negligible enough to take this as your path of least resistance. If you spend 15 hours doing this when you could be working on other critical components of the project to meet a deadline, then the benefits and returns are low.

Put it on your someday/maybe list, slice it up with PNG transparencies, pretend that no one is using IE 6 anymore, and move on. The negligible path of least resistance, due to time constraints, is not supporting IE 6. Otherwise, have at it. There is a ton of solutions out there for PNG transparencies, and this route, unfortunately, is the negligible path of least resistance.

What about best practices and web standards?

Notice that there was very little time thinking about best practices and web standards: we already know that using JavaScript for styling and aesthetics is unreliable and poor practice.

In this particular scenario, it’s not going to degrade properly in IE 6 and below if the user’s JavaScript is disabled (or if their ancient browser doesn’t support alpha transparencies). Whether or not my solution is against accepted practices such as graceful degradation or Progressive Enhancement, or any other buzzwords that help improve professional writers’ and speakers’ careers, doesn’t change the fact that I need a solution, pronto. The key here is that I know the consequences of my actions, and I’m ready to defend my choice if I have to.

Follow best practices and standards when it makes sense. Best practices won’t dictate whether we go ahead with a particular solution or not, the negligible path of least resistance will.

Outcome is the name of the game

We work for/with people who care/should care about the final product.

Using a PNG fix or conditional comment hack is unimportant when juxtaposed to deadlines and financial gains. Do stakeholders care about the 1% of the users that use IE 6 with JavaScript turned off, or do they care about the 99% of the other people who will have a better experience due to the less-than-desired PNG fix you implemented? And this is where DIRM developers need courage.

It’s hard to get used to the fact that your work isn’t the most optimal solution, for the perfectionists that we are, it’ll take some getting used to. It’s gut-wrenching to know that somewhere out there, poor Mrs. Henderson with her Windows 98 isn’t going to experience the site you built in an optimal manner.

Can you learn to live with that? Then try the DIRM philosophy.

Time as a valuable commodity

As a developer or designer, one of your most valuable assets is your time.

You can be the best at what you do, but if you don’t have enough time do it – it doesn’t really matter. Your tasks take up this valuable resource, and you must wisely choose where to invest it. You can stand there and figure out whether you should use <strong><a>your link</a></strong> or <a><strong>your link</strong><a>, maybe hitting up a few forums and getting tangled up in a semantics argument, further delaying your decision and progress.

Or maybe… you can choose to figure out the answer to a very simple question. Does it really matter?

Related Content

• Feedback. The Creativity Killer.
• Why Designers Should Learn How to Code
• How to Design for Your Worst Client: You.