YAGNI is a clever rule. It says that by doing less your are doing yourself and everyone else a favor. In some schools of Agile Thought like Lean it has become a whole philosophy (although they are more keen on some strange sounding Japanese words, mind you).

Only a decade or so ago, general approach was quite different. You’d try to make your system as encompassing, flexible and configurable as possible. You’d design your system for tomorrow’s needs.

I will give you a quick example. Imagine you need to program a feature on your website where you export some data to an excel file. In the old days, you’d analyze the problem, design your classes let’s say in a form of hierarchy where ExcelExporter and PdfExporter inherit BaseExporter class. You do not need to export data to pdf just yet, but you think you might need it some day, so you better be ready.
These days, however, you live in the present. You just program ExcelExporter. If one day you need pdf export feature, you will reorganize your classes so that both ExcelExporter and PdfExporter inherit BaseExporter class that contains some features common to both child Exporter classes so you can avoid duplication. If you never come to need this feature, you leave your ExcelExporter alone. You will implement new features as they are needed: just-in-time.

But there is a catch. In order to be able to move just-in-time, you should have a well designed, mercilessly refactored code covered with tests. Without refactoring or automated testing you are probably better of doing things the old fashioned way.
I think YAGNI is great and I try to follow YAGNI mercilessly. However, sometimes I hear YAGNI principle invoked in a way that it is clearly misinterpreted. For example “Maybe you do not need to refactor this code just yet” or “Maybe you do not need all those unit tests”. Thing is, to be able to do YAGNI, you need to have your code refactored and covered with tests. You need continuous integration and automated builds. Without these practices, once you need to implement a new feature in JIT fashion, things will inevitably start to break. One way to avoid “Maybe you do not need good quality software” kind of dilemmas is to make practices like TDD, refactoring and continuous integration integral part of your development process. Then, there is no need to think that you might leave out unit tests; since you are doing TDD these are in place already; since you refactor all the time, then there is no way to leave it out.

Remember, YAGNI applies to features, not to quality! One way to use YAGNI properly is to think about Technical Debt. Is the decision NOT to do something resulting in Technical Debt? Technical Debt has to be payed off with interest and with software rates are extremely steep. If you are getting into debt, you are not YAGNI, you are plain’ SLACKING!

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • del.icio.us
  • Reddit
  • Digg
  • StumbleUpon
  • Bloglines
  • Google Bookmarks
  • Y!GG

4 thoughts on “YAGNI is not SLACKING!

  1. Great post Dan! I had this experience with my manager, being clever on how doing things right, nothing fancy, just some good code is a waste of time. How shortsighted can you get! Uncle Bob has a take on the subject with his Sofware Craftman manifesto…

  2. Yawn. More religion. You shouldn’t design with foresight because that will cost more, you should design only for the simple case at hand because that will be cheaper. But, oh yeah, you need an awesome test suite to cover that simple case because sometime real soon you’ll be refactoring it and you’ll need to verify it still works. But, oh heavens, when you refactor you learn that a more general API needs to be different (more general) than the API for that simple case, so you have to rewrite your tests to accomodate that, and yada yada.

  3. Hi Bob,

    I used to fire up the app, pretend to be the end-user and enter the data in order to debug the application… over and over again! Then I started writing my own client apps to speed up the whole process. When unit testing frameworks appeared, I immediately understood what they are all about.
    So, besides NOT liking TDD and refactoring, what are your preferences? How do you go about programming your applications?

Comments are closed.