A Quick Example of YAGNI / Simplest Thing Possible in Action

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.  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).  Here’s the equation in my mind:

  1. 5 minutes to do the naive <table><tr><td></td>……. business to complete the feature that is in play today and has to be done in order to sell the product, or….
  2. Spend much more time working with a javascript layout engine or absolute positioning with CSS in order to make the layout extensible for a later set of features that we might never actually build

 Let’s throw out some other facts / hypotheses shall we?

  • I don’t know what the actual requirements for layout extensibility really are right now.  Any additional work beyond the simplest solution could easily be wasted effort
  • By no means does a naive solution prevent us from switching to a more robust solution later when we know exactly what that more robust solution needs to be
  • The naive solution frankly isn’t going to be hard to just toss off into the trash can
  • It’s easier to correct an under engineering problem than it is to correct an over engineering problem

 

This is a small example, and we’re talking about saving 1-2 man hours of effort tops, but this type of scenario happens hundreds of times on a sizable project.  Potentially saving hundreds of hours of effort is probably worth a change in your attitude towards design.  The power of YAGNI and “The Simplest Thing” is that it enables you to reduce the risk that the project totally fails by allowing the dev team to focus on the most important aspects of the system before tackling “nice to do” items.

 

But, but, but, what if I really do need it later?  Two answers:

  1. It doesn’t hurt to throw away a bit of simple code.  The value proposition of YAGNI / The Simplest Thing is that the possible cost of reworking naive solutions is less than that you might incur by overengineering through speculative design or getting bogged down in analysis/paralysis.
  2. Intelligently follow that S.O.L.I.D. stuff everyone is suddenly talking about and just plain good design as a matter of course to increase the Reversibility of your code base to keep in limber and able to change to take on additional requirements (TDD/BDD helps here too).  Code in such a way that it’s cheap to delay design decisions and infrastructure to a later time.  You need to be able to build for now in an efficient manner without screwing up tomorrow’s development.  Jeff Atwood and Joel Spolsky are completely wrong about the relative importance of code quality (I think Atwood’s biggest mistake was in conflating “quality” as an end that only developers care about as opposed to a means to efficient software delivery).  Well structured code helps a lot to enable the development team to deliver, and continue to deliver, on the business vision of the system — and that business vision is a moving target too.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://twitter.com/sk_tajbir Sk. Tajbir

    Very helpful :)

  • http://www.sohbetchat.gen.tr Sohbet

    thank you

  • http://www.sohbetguzeli.net Kameralı Sohbet

    really this is a nice web thank you thanks admin good post super messege

  • http://www.sohbete.org sohbet

    Thank you.

  • http://www.birincikuvvetmillettrhaberi.co.tv revizyon ile organize matbaacılık brnckvvtmllttrhaberi

    thank you

  • http://revizyonileorganizematbaacilikbrnckvvtmllttrhaberi.bloggum.com revizyon ile organize matbaacılık brnckvvtmllttrhaberi

    thanks for all

  • http://www.sohbete.org sohbet

    thank you, great.

  • Luke

    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: http://c2.com/xp/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.

  • http://jaychapman.blogspot.com/2009/03/yagni-abuse.html John Chapman

    http://jaychapman.blogspot.com/2009/03/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.

  • John

    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.

  • http://www.ircask.org sohbet

    sohbet sitesi uzerinden sohbet ve ask odalarında
    sohbet edilebilir

  • BJM

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

  • Joe Chung

    What a bloody awful example of YAGNI.

  • Nick

    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.

  • http://weblogs.asp.net/bsimser Bil Simser

    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.

  • Chris

    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.

  • http://martinsantics.blogspot.com Martin Evans

    Good post. It got people thinking and talking.

  • liviu

    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….

  • Ed C.

    Maybe we should call it “YAGNY” – you ain’t gonna need it… yet.

  • Joe B

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

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

  • http://leedumond.com Lee Dumond

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

    http://leedumond.com/blog/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.

  • http://encosia.com Dave Ward

    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.

  • http://leedumond.com Lee Dumond

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

  • SteveJ

    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.

  • http://www.ircask.com Sohbet

    I bet everyone will just nitpick about the CSS decision
    http://www.ircask.com
    instead of the message being delivered.” Right again.

  • Thomas

    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.

  • meisinger

    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

  • http://www..brandnewwebsites.net Brent Hoover

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

  • http://www.jphamilton.net J.P. Hamilton

    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.

  • Chris

    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.

  • Brian

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

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

  • http://home.infusionblogs.com/kszklenski/default.aspx Kyle Szklenski

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

  • Chuck

    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.

  • http://vladan.strigo.net Vladan Strigo

    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

  • Tom Philip

    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!

  • Mihai

    Or you could just use http://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

  • Steve Py

    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.

  • Brian

    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)

  • http://jopinblog.wordpress.com JohnOpincar

    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?

  • Chad P

    @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.

  • Chris

    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

  • El Architect

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

  • Martin Clarke

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

    @Ryan – +1 for comments on accessibility.

  • Jeremy Gray

    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. :)

  • Wes

    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.

  • http://www.matthidinger.com Matt Hidinger

    @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?

  • http://wizardsofsmart.net/author/riles/ Ryan Riley

    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.

  • http://www.mknopf.com mknopf

    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.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Matt,

    Fine then, let’s call it CSS vs. using a javascript layout framework + the extensible layout that isn’t used. I still call YAGNI.

  • http://www.matthidinger.com Matt Hidinger

    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)

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

  • http://chadmyers.lostechies.com Chad Myers

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