Adopting a “Does It Really Matter?” Philosophy

Jul 20 2009 by Jacob Gube | 30 Comments

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.

Adopting a "Does It Really Matter?" Philosophy

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

30 Comments

Jeff

July 21st, 2009

Great Article! I have been thinking about this a lot lately for exactly the reasons that you discuss. Time needed to make it perfect vs. deadline approaching. So “Does it Really Matter”?

Thanks for putting words to the thoughts I have been having.

takizo

July 21st, 2009

“Does it really matter”, the quote always apply on my daily functions :)

Tyler

July 21st, 2009

I think you pointed out a very good point here. The client doesn’t care, they want a website.

Webdesigner

July 21st, 2009

Hm… I am too much a kind of perfectionist for the “does it really matter”-thing… I guess. But does it really matter :)

Jacob Gube

July 21st, 2009

@Jeff: I think that sums it up well. In the Utopian world, we can spend all the time in the world figuring out and solving trivial matters such as, supporting the Iceweasel browser. But for 95% of us out there–the regular folks that don’t get multi-million dollar contracts or who write/speak about our profession for a living–we don’t have that sort of luxury. So I’m proposing to not sweat the small stuff and focus on outputting a product that excels in its core purpose/feature.

ZigPress

July 21st, 2009

Amen to that. I’ve been using this philosphy for years. There’s no point risking missing deadlines, losing contracts and money for the sake of extreme perfectionism and bragging rights among one’s peers.

pm

July 21st, 2009

Doesn’t evaluating if “It Does Really Matter” could, sometime, take as much time as doing the right thing?

Phil Sturgeon

July 21st, 2009

Have to agree with this approach, so long as people know what they are doing.

Many new developers write quick-fixes and hacks purely because its the quickest way without thinking about the consequences, while other new developers spend hours faffing about with semantics when they could be developing something of use.

Split it right down the middle and work out when its ok to skip corners. I skipped a few on my last site launch iphone-upgrade.co.uk and I could not care less that it looks a bit funny on IE6.

I will not be losing any sleep over Mrs. Henderson’s browsing difficulties at all.

Janko

July 21st, 2009

Results and pragmatism over rules – I couldn’t agree more on this, Jakob. Working on large scale projects for enterprises made me realize how true this is.

Jacob Gube

July 21st, 2009

@Phil Sturgeon:

Split it right down the middle and work out when its ok to skip corners.

Spoken by a true developer, well said.

Parallax

July 21st, 2009

Excellent article, Jacob. Now, if I can work with “DIRM clients” every day, I’ll be totally zen.

Kevin Quillen

July 21st, 2009

I used to be Bobby Ballbreaker when it came to XHTML validation and CSS validation.

For internal/personal sites, I prefer as close to perfection as possible.

When a deadline and money is involved, you need to do what you can do to finish the project without losing money. If that means no PNGs, so be it. If that means the HTML markup is less than stellar, thats okay. All the client cares about is if the site works and looks good. They don’t care if you used a extra div or h2 instead of an h3. That is very trivial in the real world.

There is no such thing as “Perfectionist” when you are trying to meet the requirements and scope of contract. For those of us working with web applications, we can’t have someone spending days playing with HTML and CSS, because that is coming out of the bottom line.

Tom

July 21st, 2009

Finally I can sleep at night. I work with a really anal retentive developer. The difference between me and him is that I finish my projects. I make it work. He on the other hand is weighed down by the minutia. The very nature of web development is imperfect (the browsers, the users, the network). The sooner you accept that the easier life becomes

migabora

July 21st, 2009

Great technique make the live soooo simple ,

James

July 21st, 2009

Very interesting. I don’t think I’ll ever adopt this approach though; it screams: “profit above pragmatism” … Remember, we’re not business people, we’re developers! If we don’t uphold the standards on which the industry is based then it’ll eventually go down the proverbial toilet!

Not to add petrol to the fire but you mention in your article that JavaScript’s “for” is a function; it’s actually a statement.

I have no problem with people adopting this approach, as long as they know what they’re doing. This is dangerous territory; many people take your words as gospel… This is not exactly a good approach for developers still in the process of learning.

ZigPress

July 21st, 2009

James said: Remember, we’re not business people, we’re developers!

Oh dear James… if you’re a professional developer, you’re a business person, and if you don’t have an eye for the bottom line, your company should fire you as quickly as possible.

Paul C. Shirley

July 21st, 2009

Great article Jacob, and a great attitude to be able to have.
I agree with what you’ve said – there is quite often a toss-up between doing things correctly and doing things efficiently.
The trick is to know how to make the right choice between the two, or to find a compromise.

Kevin Quillen

July 22nd, 2009

“profit above pragmatism”

You have to be deft enough to work fast enough to achieve a project without sacrificing a lot of quality. On the same coin you can’t be wasting hours and hours making it perfect, because its never going to be perfect.

In this economy, we have to place profit above pragmatism, thats just the way it is right now. It’s always nice to be ‘by the book’- but its also nice to pay the bills and have a job too!

This doesn’t mean we’re going back to phpnuke systems and table layouts and by no means does it mean to cut corners. Don’t fret over trivial details, see the bigger picture and complete it.

Malta

July 23rd, 2009

I think it matters, especially when using DIVS. DIVS are better than tables. It also effects SEO.

Mohamed Jama

July 23rd, 2009

Excellent article, I worked with both kinds of developers and I concur with you, as long as you making a decision that based on your targets and client needs you do have the right to bend a rule or two!

Dror

July 23rd, 2009

Thank you for the great article. I’ve been thinking about this quite often lately. Still love to dig in small issues when I can, so much fun… :)

Wizely

July 26th, 2009

Brilliant article!
It’s not like the standards are that good anyway – there’s not true separation of content from styling and a woeful lack of semantics. So many sites proudly display ‘valid’ markup but are a mess or use tons of hacks or limit their functionality to make sure 10% of their audience get exactly the same experience.
Best practice in any business means cost-benefit analysis. And, to paraphrase Churchill:
“Break any of the rules sooner than do anything outright barbarous”

ErisDS

July 26th, 2009

My favourite quote of all time is:

“In theory there is no difference between the theory and the practice. In practice there is.” – [i]Yogi Berra[/i]

I never realised quite how much this applied to web development until I started working full time.

The key point is that in order to be able to provide a practically perfect solution, you must first understand the theoretically perfect solution, then apply this to the practical situation & circumstances and see where you may have to make compromises. It should be a thought process and a decision, not an accident. As you say if you can argue why you made a particular decision to do something that breaks “the rules” then you probably have a good reason to.

Is it really worth using conditional comments when your css contains one underscore hack?

As long as a decision is taken for good reason and not laziness or lack of knowledge then surely the clients are in good hands.

Alex

August 31st, 2009

“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.”

Or at least this helps you sleep at night. Traitor! Lol, JK :)

…mostly :|

Iqbal

December 31st, 2009

“Level of abstraction”

Focusing on your target needs the practice of abstraction.
Final output is more important then digging into the lower directions of different supporting solutions.
yes does it realy matter? approach can help you to achieve your goals in timely manner.

Anne

June 7th, 2010

You bring up great points. I’m very much against being a square, pegged into a square hole – this applies to my chosen profession as much as it applies to anything else in life.

Breaking the rules, when you do it with forethought, as you mentioned, and with some know-how and experience behind you, is not such a big deal.

There’s always two ways to skin a cat, and when it comes to real-world projects (i.e. paying jobs) you do your best, of course, but sometimes, it is necessary to take that little short-cut to get something done.

It doesn’t have to mean that your work is not standards compliant, or that you’re being lazy or incompetent. Using an inline-style on the odd occasion and when circumstances call for it, is really not a sin punishable by an “oh what an amateur” type of attitude by the die-hards in our industry. Just my take.

Ant

June 8th, 2010

If someone using IE6, that should be user problem, not developer.

Alan Savage

August 7th, 2010

The keyword here is balance. I’ve worked with developers that will hack code to get it out on time and then handoff to others to fix and others that miss deadlines because their div’s don’t line up right in IE5.
I try to remember the IT businesses we all look to (Amazon, Google, Microsoft etc) got where they are for knowing how to make money out of a good idea in the business world-not by developing websites/applications that conformed perfectly to standards.

Young

August 16th, 2010

you get F– for using the word “guesstimating” :)

Moses270

January 25th, 2011

philosophy is a rose of life’s accomplishments

Leave a Comment

Subscribe to the comments on this article.