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