My musings about .NET and what not

A Really Bad Example of YAGNI

In his recent blog post, A Quick Example of YAGNI, Jeremy Miller presents what is quite possibly the worst example of YAGNI I've ever read.

First, let me say that I really admire Jeremy and value his opinions. I read his blog fairly regularly and have learned a lot from it, especially in regards to Agile software development. But, with all due respect, I think he blew it on this one. Hey, even Superman has a bad day once in a while.

In, Jeremy writes in part the following:

If you've ever worked on an Agile/XP team you've surely heard something in the lines of "Let's YAGNI that. (YAGNI == You aren't gonna need it)"  You've probably also heard the phrase "do the simplest thing that could possibly work."  Both of these sayings are an exhortion to developers to avoid overdesign and analysis/paralysis by focusing on the here and now instead of getting caught up in designing for a conjectural need.

So far, I'm on board. I'm actually big believer in YAGNI. I've seen far too many developers waste far too much time writing far too much code to accommodate far too many nonexistent requirements. The YAGNI principle is especially important to independent developers and consultants, where failure to reign in feature creep can make the difference between making a living and losing your shirt on a project.

But then, Jeremy goes on to offer this example:

I called YAGNI on something today.  We're enhancing (redoing) the dashboard page on our product.  The new design calls for a 2 x 2 arrangement of mini-panels.  I said just use a table driven layout (5 minutes of typing) and get going.  A colleague threw a fit and screamed that we needed to use something more sophisticated because we're eventually going to allow customization of that page (and oh yeah, the world will end if we don't use CSS layout instead).

Sorry, but this where I get off the bus. In my opinion, to offer this as an example of "You Ain't Gonna Need It" is to exhibit a less-than-firm grasp on the meaning of the word "need," especially when it comes to web usability.

To all you web devs who feel perfectly okay with this, I'll tell you what. Go put yourself in the shoes of a blind person for a day. Install a screen reader, cover your eyes with duct tape, then spend several frustrating hours trying to fuddle through your quick-and-dirty table-based layouts. Then come back and tell me "you ain't gonna need it," okay?

Several have left comments supporting Jeremy's example, and I have to say, some of them made me shake my head.

Here are portions from a couple of typical ones:

...Better is better, but DONE is best, and if table-layout is what you know then do it...

...I use [sic] to be a zealot about crap like that - then I got over it because it really doesn't matter as long as the job gets done and the people paying your check are satisfied.

Well, I guess that all depends on what you consider "done." To many (far too many) developers, "done" means you got paid and the check cleared.

Let me make my feelings on this really clear:

As far as I (and in my opinion, any truly conscientious developer) is concerned, any public-facing web site where such disregard is given to accessibility is far from "done".

Let's take this out of the realm of web development for a minute, and look at this from the point of view of building development instead.

Developer: "Hey, the building is all done!"

Client: "But, where are the wheelchair ramps?"

Developer: "Ramps? Ramps? We don't need no steenkin' ramps! See, my legs work perfectly fine! And so do yours! What's the problem?"

And this, my friends, is what this post is really about. It's not about YAGNI per se, and it's certainly not meant to bash my friend Jeremy. It is only to decry the sad fact that, after all these years, so many web developers are still so cavalier about shoving the accessibility issue to the back of the bus.

If you read software development blogs with any regularity, you know there have been a lot of bits spilled lately over SOLID and Agile and TDD and Design Patterns. But do you really think that the user who has the misfortune of having to deal with your lack of concern with accessibility -- you know, the one with impaired vision, or deafness, or limited motor skills -- gives a rat's patootie whether you used the Respository Pattern or the Active Record Pattern in your data access layer?

Look, like I said, I'm not against applying YAGNI where it fits. But to toss aside the struggles of those who have to deal with barriers like this every day is not YAGNI.

Here are a couple more head-shakers from the comments:

... use CSS as much as you can EXCEPT to control the positioning of items on the page, this is where Tables are best.

... If you just want some output in columns and rows for a diagnostic panel, then why bother with CSS?  They probably spent more time arguing about it than it would take to implement using tables... a waste of time.

I cannot even begin to speculate whether these are simply displays of profound ignorance, laziness, lack of compassion, or all three. Good Lord, people. Is this where we still are as a profession? Haven't we learned anything about accessibility and usability? What will it take to make the people who build the web care about this stuff?

Anybody who posts a web page on a public server would be well served to keep the following in mind:

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

The author of that quote is none other than Tim Berners-Lee, Director of the W3C and Inventor of the World Wide Web.

I was glad to see the following from commenter Ryan Riley:

Tables are for tabular data. If your data is tabular, sure you can use CSS markup to make it snazzy, but an HTML table element is the right tool for the job. If, however, your content is just laid out a certain way, you don't have tabular data and a table element should not be used. Think "accessibility."

Hey... maybe there's hope after all.

(P.S. If you're interested in learning how to write a good accessibility statement for your site, check out this blog post.)

Subscribe to this blog for more cool content like this!

kick it on

shout it on

vote it on

Bookmark / Share

    » Similar Posts

    1. Balsamiq – It’s Not Just For Salad Anymore
    2. Open Source or Die – The *Real* Future of Graffiti?
    3. I'm a .NET Developer, and Yes, I Love My iPhone.

    » Trackbacks & Pingbacks

    1. You've been kicked (a good thing) - Trackback from

      A Really Bad Example of YAGNI — February 21, 2009 10:02 AM
    Trackback link for this post:

    » Comments

    1. Martin Evans avatar

      Hi Lee,

      I stumbled on your blog from Jeremy's post. I agree that in designing a forward facing public site, accessibility to content is the key factor. However I think the instance he was referring to was a commercial web app that served a business purpose.

      While he may have screwed up on the context, I think in the circumstances he was describing, I think he was right to do what he did.

      Ironically, any time saved using the table option was probably taken up reading all the comments!

      Martin Evans — February 19, 2009 3:13 AM
    2. Lee Dumond avatar


      By "public-facing" site, I essentially meant any non-intranet application. A commercial app could still be used by anyone, including someone with disabilities.

      The only cases in which I think this could be justified is in building an app for a small group of known users behind the firewall, where one can be certain that accessibility won't be an issue.

      Lee Dumond — February 19, 2009 8:25 AM
    3. Ian Chamberlain avatar

      Wether anything is made accessible or not is a customer decision, not a developer decision. It is up to the business what priority they place on that requirement. Until then YAGNI.

      Ian Chamberlain — February 19, 2009 8:38 AM
    4. Lee Dumond avatar


      Interesting take. I, for one, don't feel that accessibility should be treated as an extra "add-on" feature, but should be built into any web design as the "default" standard. Perhaps it is up to developers to step up and make the commitment to do the right thing from the get-go.

      Lee Dumond — February 19, 2009 9:09 AM
    5. Martin Evans avatar

      To be fair, Ian makes a good point. I once floated the acessibility issue to my then commercial director when putting a site together for them, only to be met with complete incredulity.

      I've also the director of another firm sing my praises for getting their site customised to use Browse aloud properly,

      At the end of the day, we as developer's we can't preach to the customer on accessibility issues, only advise.

      Peace out..

      Martin Evans — February 19, 2009 11:18 AM
    6. Lee Dumond avatar

      @Martin -- point taken. Yo do have to draw a line *somewhere*, and you can't really force a customer to accept a bunch of fancy accessibility features they won't pay for.

      That said, I would also point out that for a competent dev, it should take no longer to implement an accessible CSS/div layout than it would an inaccessible table-based one. Just doing that goes a really long way.

      Lee Dumond — February 19, 2009 11:40 AM
    7. Rachel avatar

      Just a tad harsh maybe?

      Is yagni a new yoga technique?


      Rachel — February 19, 2009 10:35 PM
    8. Arduijn avatar

      How about judging it in context?

      For example, if it's a photo or video web site, the quick-and-dirty table solution is probably just fine, especially for a dashboard page.

      Arduijn — February 21, 2009 1:22 PM
    9. John Sheehan avatar

      Accessibility is nice to have, but I think you should argue from the quality of code standpoint. YAGNI (in my understanding) means don't write code you're not going to need. It doesn't mean write crappy code to get things done. In the example, tables very might well have been the appropriate markup to use and Jeremy encountered an overly-dogmatic CSS proponent. But either way, the decision should be to write the best code you can that works and nothing more.

      John Sheehan — February 21, 2009 11:16 PM
    10. Lee Dumond avatar

      As long as developers continue to view accessibility on the web as nothing more than "nice to have," then I fear this selfish attitude will never change.

      To a person who can walk, entrance ramps on a public building are "nice to have." To a person in a wheelchair, they are *absolutely* necessary. All I am asking is that some of you give some thought to those less fortunate than yourselves. Is that really so hard to understand?

      Lee Dumond — February 21, 2009 11:34 PM
    11. John Sheehan avatar

      What I meant is that accessibility is immaterial to YAGNI in this discussion. The dismantling of Jeremy's post should be about code quality.

      I agree with you that in most situations accessibility should be a priority. And proper HTML/CSS/separation of concerns/progressive enhancement, etc is the best way to achieve that. No argument from me there. Apologies for implying otherwise.

      John Sheehan — February 22, 2009 12:10 AM
    12. Lee Dumond avatar

      > What I meant is that accessibility is immaterial to
      > YAGNI in this discussion. The dismantling of
      > Jeremy's post should be about code quality.

      This reinforces my assertion about this being a poor example of YAGNI. How does one compare CSS vs. tables in terms of pure "code quality"? Is table code of "higher quality" than CSS code, or vice-versa?

      I'm not sure it really makes sense to think of YAGNI *only* in terms of "code quality". As this case shows, "quality of result" matters too.

      I really do appreciate the thoughtful and engaging feedback from you and everyone else. There are a lot of interesting points to think about here...

      Lee Dumond — February 22, 2009 9:48 AM
    13. Thomas Clancy avatar

      Okay. I think I understand what you have written. But I don't know if it makes sense--still mulling it over. However, although the YAGNI example might be a bad example (I don't think it is), I think something in the argument is missing. Requirements. The building example you give, for example, doesn't mention building codes. If the requirement for a public building states that it requires ramps for the disabled, then we build ramps. However, a ramp doesn't need (and this is contrived) a sign pointing to the ramp stating "ramp". If the requirements are written well, then we build what we need, eschewing what we don't. Using your example of a blind person, if the web site needs (requires) that the site should be accessible to the blind and/or the deaf, then the requirements should reflect. I do agree, however, about the meaning of need. What is really needed. And if a web site decides to not provide accessibility to the deaf, chances are the site is a music site or a podcast site, although in this case having transcripts of podcasts could be argued as a need in this case.

      Thomas Clancy — February 22, 2009 11:56 AM
    14. Joe Brinkman avatar

      I am going to be a bit contrarian here... but why do we give the developers who write screen readers a pass? We force hundreds of thousands of web developers to use tools which are in many cases inadequate for easy cross browser development. CSS is still years away from being equal to many of the tasks that devs use tables for, mainly due to browser incompatibilities. It would seem to be a much easier problem to solve to have screen readers differentiate tables used for layout from tables used for tabular data. That is something that doesn't require the agreement of the W3C, MS, Google, Apple, Mozilla and hundreds of thousands of developers to fix. It requires at most a couple hundred developers working on half a dozen screen readers to greatly improve accessibility.

      This to me is more in keeping with "do the simplest thing that could possibly work" philosophy. In the meantime we'll keep trying to get MS, Apple, Google, Mozilla, Opera, the W3C and web devs to start designing for accessibility - but don't hold your breath that it will happen anytime soon.

      Joe Brinkman — September 23, 2009 4:43 PM
    15. Lee Dumond avatar

      Thank you Joe. That's a very well-thought out take on this.

      My only concern is that you may be taking the problem of differentiating tables (layout vs. tabular data) a little too lightly. Screen readers parse markup, and to my knowledge there is no way to identifying a layout table or tabular table by parsing its structure.

      It would therefore involve peering into the actual content of each table and making a subjective judgement of the purpose the table is serving on the page. Not as easy as it sounds!

      Lee Dumond — September 23, 2009 5:02 PM

    » Leave a Comment