Thank you for submitting this cool story - Trackback from DotNetShoutout

"threw a fit and screamed"?  Also, if you've ever tried to embed a table into the middle of a CSS-based div float layout, you would know that it's not quite a 5-minute task.

Hmm, I call YAGNI on quite a few things, and absolutely *despise* over-architecture, but I have to respectfully disagree with this particular instance.

I don't know your CSS background but this sounds painfully like someone who isn't really familiar with the technology. "JavaScript layout engine", or "absolute positioning"?

It will take only a little bit more markup to achieve (what I believe are your requirements)

<div id="top">

  <div class="col1">

  </div>

  <div class="col2">

  </div>

</div>

<div id="bottom">

  <div class="col1">

  </div>

  <div class="col2">

  </div>

</div>

.col1 { width: 50%; float: left; }

And I agree with Chad above, trying to mix table layouts with real CSS layouts is a highly annoying and frustrating task.

And of course, this markup is much more ready for change and integration with the rest of a (hopefully) CSS site in the future.

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

All, in my experience of working with both All CSS driven and table driven layouts (as well as a mix of both) I have always come to the exact same conclusion: a mix of both is always best (I know most of you may disagree but I've worked on hundreds of web applications and this is in fact what I have discovered).

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

I must respectfully disagree as well. For one thing (and maybe I'm missing the point), you're focused on a presentation decision and not following presentation rules. 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."

Yes, I know I'm probably toeing the line to the Kool-Aid, but I would think that this would be an important message in the midst of Agile projects failing because of a lack of high coding standards. Accurate markup is a must, and throwing tables around willy-nilly should never have surfaced in the first place.

@mknopf,

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

Is this sarcasm?

The point of YAGNI is, focus on the task at hand, and provide value (for the customer.)  If the customer wants a completely skinnable site, then go with the CSS, it should be part of the design.  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.

Six comments (from humans) so far. One arguing against the 5 minute estimate, one showing a div-based alternative, one arguing that tables are okay, one arguing that tables are only for tabular data, one commenting about sarcasm, and one about this being wasted time. Six out of six all recommending different things. Put all six in the same room and ask them to engineer the solution and you'd end up with a massively over-engineered compromise, not to mention a tonne of time spent reaching that compromise, all to support a requirement that is not yet even confirmed.

I doubt I've ever seen a better case for invoking YAGNI. :)

This discussion reminds me of the meme: www.giveupandusetables.com

@Ryan - +1 for comments on accessibility.

"Potentially saving hundreds of hours of effort is probably worth a change in your attitude towards design".

Wouldn't this decrease your number of billable hours? This is surely not cost-effective. Also what about the extra hours of maintainance you could charge?

Jeremy, I appreciate your yearning for simpler designs, but more money is made by making simple things complicated.

a css layout would take the same amount of time as a table layout in my opinion. (both 10 -20 mins)

However, the css approach would be prefered

Using depricated technology (tables for layout) coz you havent got up to speed with css layout (which is just as simple as a table once you are used to it) isn't YANGI

@Jeremy Gray I disagree with your point.  I think if this team had someone who knew CSS then this task would just get handed to them and there probably wouldn't have been a debate at all.

The only reason I'll agree with the YAGNI call on this is because it's obvious you didn't have someone with a firm grasp of CSS layout technique.  This probably meant a decision of 5 min table layout vs. half day for someone to learn CSS for layout.  

It should have been a 5 min task using either technique... of which CSS is the "correct" answer.

I know the gods of CSS will frown on this comment.  But for certain layout tasks, CSS always seems like a big PITA compared to tables.  I've spent countless hours studying CSS and I'm not a stupid guy.  Maybe my brain is just hard-wired for tables versus divs.  Heck, the name div doesn't really make sense compared to table to me.  The funny thing about Matt's comment above is the "col1 { width: 50%; float: left; }."  I'm sorry but that's just not as simple as the TABLE based solution.  Why do I only have to manipulate col1?  If I want 3 cols, then what do I do?  The table solution is so simple and so obvious even little kids could get it right.  How many little kids could figure out the DIV solution?

Go YANGNI!

If tables work for you - don't feel 'pressured' by us (former in my case) W3C/CSS zealots to use div's and write proper markup - we get anal sometimes and just blow them off!   Do what works best for you!

Sure some of will spout off about maintaining standards and best practices of the industry and writing pages that are easier to maintain because your not mixing layout regions with regions for display data and using CSS (because in-line styles are expensive to change), and maybe reference some ISO standard or plethora of books; but I wouldn't worry about it - I use 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.  

Personally I do what I feel is best and look for areas to improve (follwing that whole PSP (Personal Software Process)), but trying to force people to change - ain't worth it - tell you're co-worker to just worry about self-improvement.

Also @Josh -

'CSS always seems like a big PITA compared to tables'

>tables and CSS are complimentary not opposites, I think you mean tables compared to divs (the designer in me - sorry)

All I'll say is that this div vs. table argument is missing the forest for the trees. Yes, yes, CSS based layout is the best thing since cream cheese (although my personal experiences with debugging CSS-related issues with layout & browser compatibility certainly hasn't lowered my WTF/minute rate compared to table-based layout.) but the point is *if* it is simpler to add table-based layout for a new element in a page  than re-design the page to use divs and CSS, then table-based layout it is.

And as for "El Architect's" comments about making simple things complicated... You *must* be a contractor/consultant, much like a few I've worked with in the past. However, your claim is wrong. I quote a job based on value to the customer. If I quote something taking 2 days and it only takes me 1, that's profit and a buffer for future work/complications. Over-complicating software just to lock-in and extort your customers may pay off, but it's by no means a sign of professionalism. I do factor in a bit of "Scotty's Law" into my quotes. Coming in a bit ahead of schedule ensures you get a quality product out on-time. = happy, repeat customers.

Or you could just use www.blueprintcss.org it's a css framework and doing what you needed would have involved writing 5 or 4 div's depending on what you wanted ;) try it, you'll probably get a kick with it

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #389

YAGNI's a great way to reduce the amount of time spent on writing code now and maintaining in the future but I think best practice for using html markup is a better choice in this case. Table-less layout will give a flexible, semantic and accessible layout with about the same effort. There'll be less html to write and maintain and you can always use a css framework like 90 Grid (just for this sort of problem) or other css frameworks like Hartija, WYM Style and blueprint that do a bit more. It's the other agile principle about the wheel!

Jeremy,

While I do agree with you to some extent, I do have questions in my mind about YAGNI/Simplest thing now vs. SOLID.

In my mind and knowledge, going with CSSable here (maybe not javascript engine, that sounds like an overkill, but fully cssable *nice* solution, div or tables...depending on requirements) is implementing SOLID (OCP comes quickly to my mind by only having good CSS setup)...only on the level of HTML output?

What I am pondering in my mind generally is how far SOLID goes *against* YAGNI/Simplest thing now, and vice versa. Some things we do today because of experience and understanding of SOLID'ish things in our industry go right over YAGNI. For example, most of the times on my projects I don't get explicit requirements as to quality of the code provided to the client, but I can judge how maintainable my team needs to make it by seeing how big the project is, how long its lifespan will be, etc...the decissions made there at that point have been known to go right over YAGNI (not explicitly knowing we will need it, but suspecting it), and especially over Simplest thing now...balancing these two *worlds*, in my mind has proven to be tricky to say the least.

What are your thoughts on this?

Vladan

Jeremy - thanks for this reminder. I started to spend 30 minutes laying out a table-less design, and wound up killing a morning over it due to my lack of knowledge of CSS (beyond the styling).  I wish I would have seen this yesterday just for the simple reminder YAGNI.

"Jeremy, I appreciate your yearning for simpler designs, but more money is made by making simple things complicated."

I have to believe you were being sarcastic here, El Architect. I don't want to rationalize your position, but this is possibly the stupidest thing I've EVER heard, and I'm a consultant! If you make your designs more complicated, that makes them much more likely to fail, and suddenly you're not only not making any money, you're probably being sued for breaking the timelines in your contract, or if not that, giving much of the money back as time goes on. Neat!

YAGNI, though it is a stupid name (even written out), is a fundamental guiding light for me, and I think I can say that objectively, my designs are so much better for it. On a recent project, we were struggling with one piece of functionality that was quite annoying. I realized we were overcomplicating the problem considerably, so I asked to drive and in five minutes had made the design so simple that we could actually continue coding, instead of focusing on fixing the mediocre solution we'd come up with until then.

Man, it was almost like I predicted the future or something!  

What I tell ya Jeremy - us zealots are all over!

I don't know if it is a good idea to use an old way of doing something just because you aren't familiar with the new way (at least, according to web standards). Using semantic code is more accessible and supposedly better understood by search engines.

The first thing I thought when I read this article is "I bet everyone will just nitpick about the CSS decision instead of the message being delivered." Right again.

Using tables for layouts is not the best solution, in fact its a crappy one, and I say that from spending years debugging table-layouts that collaspse like a house of cards when missing an obscure </tr> somewhere. However, today is today and you know what you know and stopping in the middle of a project to try and master a new technique is rarely a good idea. I think I would prefer an experienced table layout to a newbie's CSS (especially someone who doesn't even really have a clear grasp of what css layout would mean, no offense). So as far as calling YANGI on the project in the here and now. Better is better, but DONE is best, and if table-layout is what you know then do it. It's not like someone will not be able to decipher your code. You don't stop in the middle of a client project and try to learn a significant new skill. But it does make me think that this is a red flag that at least someone on the team needs to be a CSS ninja. Even if you think CSS is a joke and a fad, it's a client requirement on many jobs nowadays. Get the job done now but make sure next time you aren't ill-equipped to do it "better" at the same pace.

I say this because this is a common pitfall of mine and I need to have someone call YANGI on me many times. "Yeah this WOULD be better done with LINQ to Entities" but the project has been 90% done with LINQ to SQL and that Programming Entities book seems pretty thick. Put 'Learn Entity Framework' on your list and finish the project.

Jeremy... thank you for this post

what i think this really brings to light are the requirements and customer needs.

if you are building a UI that adds fluff to the requirements (e.g. movable panels when the requirements don't state that they need to be) then you are feature creeping yourself

in other words... you should have already had the conversation that would have introduced the need for movable panels, sortable column headers, etc...

and if you are really in an iterative process these requirements may be brought up during the feedback cycle.

but if you add movable panels and sortable column headers prior to any feedback then not only are you breaking the process but you are stating that you know more than your customer or stakeholders do

in any case... KISS and YANGI (in my mind any way) support an iterative process and verifiable requirements

Remember that YAGNI means finding the apporach that solves the problem the simplest but no simpler. Are you targeting a single browser? That IMO is key in answering whether the use of tables is the simplest solution. If right now, the project targets a single browser (or single class of browsers), then using tables is probably the simplest solution. However, in my experience, I have had far more trouble dealing with rendering issues across browsers with tables than with CSS where I have far more control. If multiple target browsers are in the equation, then tables are too simple to solve the problem.

I bet everyone will just nitpick about the CSS decision

http://www.ircask.com

instead of the message being delivered." Right again.

The end problem with YAGNI is that most of the people I've worked with see throwing away code later as wasted effort.  This is where you get the 100 line commented out blocks in the code "Just in case we need it again".  Yikes.

With all the alternatives, I would have made it into a competition.  These three guys all say they can do it in 5 minutes with their solution?  Fine, get me the lowest bidder, if he finishes on time, great, else he's buying beer for the team.

I think this is probably the WORST example of YAGNI I have ever read.

Do me a favor -- put yourself in the shoes of a blind person. Install a screen reader, cover your eyes with a scarf, and try to fuddle through your quick-and-dirty table based layout. THEN tell me "you ain't gonna need it".

One of the comments here reads in part: "...Better is better, but DONE is best, and if table-layout is what you know then do it."

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

As far as myself (and any conscientious developer) is concerned, any public-facing web site where no concern is given to accessibility is far from "done".

At this point, the CSS vs. Table issue is really a matter of expertise (and practice).  CSS is far from perfect, but it works well, helps to dramatically clean up your HTML, and separates concerns in the presentation layer.  Using a Table layout is about as ugly as having inline javascript:alert() attributes on your elements.

I'd be curious if you would support the YAGNI argument for incurring obvious technical debt if it were something like TDD or DI that was on the table (har har) instead of HTML layout.

I just posted my take on this on my own blog:

leedumond.com/.../a-really-bad-example-of-yagni

Certainly not a slam on Jeremy, just my feelings on the underlying accessibility issues and some of the comments offered here. I'd welcome your feedback on it.

Simple is good.  But I agree this is a bad example.    

Save YAGNI when some dude wants to introduce dependency injection for no reason.

Maybe we should call it "YAGNY" - you ain't gonna need it... yet.

Pingback from  A Really Bad Example of YAGNI : LeeDumond.com

YAGNI is valable exactlye for examples as the one you gave.

Microsoft is using YAGNI for its Entity Framework and it simply drives everybody mad.

YAGNI is not for  framework developers. YAGNI is for programmers that deliver to end users, not for programmers that deliver to other programmers....

Pingback from  igorbrejc.net &raquo; Fresh Catch For February 19th

Good post. It got people thinking and talking.

tend to agree with this being a very bad example of YANGI

I am trying to think of another scenario where the author would advocate using a depricated technology because it is the one they understand and will get the job done

it just wouldnt fly

and it shouldnt here.

RE: The value prop of YAGNI and this scenario. Like you said, this may be say an hour of "extra" work to do the CSS layouts vs. the table ones. I concur. However this could happen hundreds of times, hence hundreds of hours.

So given these conditions and let's say I'm the screaming CSS guy screaming "down with tables". Is there really value in YAGNI if we're doing this over and over again? At the end of the day sure it's say only an hour (heck, let's say 15 minutes) but it happens hundreds of times. I wouldn't say it would be 15*100 but let's say it's some factor of 15 like 40 which is 10 hours. Now I've got a situation to handle where I can spend an hour now or 40 later to rip out my "simple solution" and replace it with all the instances of the more elegant one?

Okay, don't know where I'm going with this but I couldn't fit this on twitter. I believe in YAGNI, I really do. I struggle though with scenarios like this where yes, it's YAGNI in the spirit of things but when it boils down to brass tacks and the cost is figured out, common sense says to do the *right* thing rather than the *minimalist* one.

Anyways, maybe something to share over a beer. This and the BDD aspect of having to determine context is bugging me now. Must go and think.

All this'd be sorted out if there were an easy way to make a grid in HTML. Why there isn't I don't know.

What a bloody awful example of YAGNI.

OMFG Jeremy, did you *really* have to use a CSS-vs-tables example? These are highly flammable :)

What started as a personal goal to motivate me to post more frequently has reached a milestone – one year! Looking back I realize that I never quite explained what these posts have been about. The intention of the Weekly Web Nuggets was twofold – to share

<a href="http://www.ircask.com" title="sohbet" target="_blank">sohbet</a> sitesi uzerinden <a href="http://www.ircask.com" title="sohbet" target="_blank">sohbet</a> ve ask odalarında

<a href="http://www.ircask.com" title="sohbet" target="_blank">sohbet</a> edilebilir

Doing the simplest thing possible in every circumstance would lead to an architectural morass.  I'd say do the simplest thing consistent with the overall design.

jaychapman.blogspot.com/.../yagni-abuse.html

YAGNI can sometimes be abused when it's used against an argument for an approach which is actually cleaner and superior, but you are not familiar with.  That being said, if you're writing the code, it's ok to use what you know at the time.  We can't all know everything about everything after all.

I realize that the central message is not about CSS vs tables for creating web layouts, but it does illustrate an example of where YAGNI doesn't apply.  I'm on the side of the colleague who "threw a fit" about using tables in the described manner because it violates accessibility *standards*.  

"The one exception that I would make to [YAGNI] is consistency with standards. For example, if I have a standard that I always provide a getter for any setter, I will add it immediately, even if I don't need it now, lest someone trying to maintain the class later assume that I really intended the attribute to be write-only." -- Russell Gold,  Source: c2.com/.../YouArentGonnaNeedIt.html

If you've ever listened to a screen reader's rendering of a web page with nested tables  you'd take pity on that poor visually-impaired user and never even think of using tables again to lay out the elements of your page.

"The medium [ WWW] is designed to be accessible.  If your web pages are not accessible, you're doing it wrong." --Unknown

In my experience HTML markup and CSS is one programming technology that doesn't always easily refactor; you're better off getting it right the first time.  In many cases I find it easier to start over (or roll back to a previous incomplete but working version) than fix or refactor layouts.

thank you, great.

thanks for all

thank you