In our previous post on Set based Concurrent Engineering and Software, we discussed how the trick in Set based Concurrent Engineering (SBCE), is to realize what decisions you can defer and what you must take now as well as how risky or difficult would it be to change a decision later. We also discussed how good design should keep options open, and how this in turn helps us to be flexible and quick to respond to challenges. One approach that many people use [in Agile, Lean and even Waterfall] is You Aren’t Gonna Need It. Like other aspects of Agile and Lean, the concept is simple. Yet, understanding and implementing it can be very difficult. This is because, the concept is against the traditional way. In this case, foreseeing and predicting the future and planning for it has been considered the hallmark of great teams. However, the concept of YAGNI and Do The Simplest Thing That Can Work (DTSTTCW), suggest that its not as much foresight of what will happen in future, but ability to respond effectively to what will happen that separates the really good teams from the average ones. In terms of software, we have always tried to design for “any and all eventualities“, while following practices that do the exact reverse. This is because, we are not designing the architecture for “any and all eventualities” but what we consider to be “any and all eventualities“. If the events unfold exactly the way we want them to, everything goes nicely. The moment there is a deviation, things go astray. In contrast with this elaborate Big Design Up Front, sometimes deferring a decision making to when you have enough information is the best thing to do.

YAGNI is a XP practice which states that “Always implement things when you actually need them, never when you just foresee that you need them.” XP actually takes it a step further and says that even if you’re totally, totally, totally sure that you’ll need a feature later on, don’t implement it now. However, to start with if you have any doubt about “whether you will need it” you should not add that feature. This is because you *might* need the feature in future, but you *might not* either, even if you are very sure right now. If you build the feature, only to discard it later - it would be waste of effort. You might actually need the feature and implement it, but you might need it in a different format and hence, would need to do some work to add to it anyways. Some other disadvantages of doing “what is not needed right now”, right now are:

• The time spent is taken from adding, testing or improving necessary functionality
• The new features must be debugged, documented, and supported
• Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later
• Until the feature is actually needed it is difficult to fully define what it should do and to test it. If the new feature is not properly defined and tested, the unnecessary feature may not work right, even if it eventually is needed
• The software becomes larger and more complicated
• Adding the new feature may suggest other new features. If these new features are implemented as well, this may result in a situation where you don’t know where to draw a line

As you can see the above are pretty serious issues. And we take them on in a software architecture/ project on the *promise* and *premise* that it would be useful down the road.

The above said, you can religiously follow the letter of YAGNI and yet miss the spirit of YAGNI. The idea of YAGNI is not only to not commit to decisions as late as possible but also do the minimal that could work now. If following YAGNI means that you are actually doing more work “now”, you are not following the spirit of YAGNI. Similarly, the idea of YAGNI is to keep the code simple. If doing “YAGNI” makes your code more complex, you are not following the spirit of YAGNI. For instance, committing to a database is a big decision and you would like to keep the decision open till as late as you can. However, if you already have a database persistence mechanism, not using the same and writing your own file based implementation simply because your feature “does not need it”, would only add chaos. Although, your feature does not need it and probably the feature would take more time using the database persistent mechanism but maintaining two sets of persistent mechanism has two different implementations for same work. We said that “YAGNI is simple” yet “it can be difficult to implement”. For instance, “You aren’t gonna need it” is not about making a method private because “no one will use it, never”. It’s about not putting a pluggable generic templating mechanism for different kind of outputs if your requirement just state “show static HTML”. It does not ask you to be lazy or stop thinking about a requirement. It asks you to consider if you “really need” to write you code in this way or you can simplify it can use it only for the purpose of “this requirement”. The difference is enormous.

Some of the arguments against YAGNI have been that sometimes you have to implement a certain feature, you should factor in that at present. Everything has a cost of doing right now and also the cost for not doing it right now. If the ratio is high, it would be a waste to do these features right now. If the ratio is low [i.e. cost of not doing it now is high], then in all likelihood, the requirements should be prioritized and clear your way in doing something right now. So, lets say you talk to your customer and conversation goes like this:

• Team: We see you have this requirement down in iteration 2. We think that this requirement we are doing in this iteration should factor in that requirement as well and if we took a bit of time to define the interfaces well, we would save a bit of time in iteration 2.
• Customer: Ok, how much time would you save?
• Team: Umn! Maybe 4 hours.
• Customer: And you will need to write that interface anyways?
• Team: Yes.
• Customer: Good! Tell me, if I chose not to implement this feature in iteration 2 but iteration 6, but pick these apparently related requirement from iteration 3 in iteration 2, would the work you do still be useful.
• Team: Umn! Probably yes!
• Customer: So can you code in a way that all the requirements in future iterations are taken care of right now because I don’t know what might need to be done when. Maybe, iteration 2 is pretty stable but not so sure about iteration 3 onwards.
• Team: Yes, we can. We can simply code for iteration 1 right now and not commit either to iteration 6 or 2 feature requirements right now
• Customer: Cool! Would that be YAGNI?
• Team: Err, Yeah!

This is a slightly simplified example, but the crux is that if something has this huge advantage of doing right now, then it should be a priority anyways. The above conversation could probably end with customer asking the team to do it now if the question the team posed was, “whether we should write the comments as we go or later” or “can we commit to a coding architecture right now”. This is often presented in what is called “Opportunity Cost Argument” i.e. loss of cost from other opportunities by choosing to go with only one opportunity. This can be balanced by sometimes asking “what is the cost of not choosing this opportunity right now”.

YAGNI is not a standalone concept and must be used with common sense and following good design principles, good testing framework and continuous refactoring. We like to think of YAGNI as a question and not the answer. The answer has to be provided by you. The secret is to use your brain and not reply on the letter of what the concept says but the spirit as well. This is where Agile separates itself from other processes anyways. The concept does not ask you to be blind. It only asks you to be not be a soothsayer.

Popularity: 31%

Posted on January 12th, 2008 by admin
Filed under: Business Alignment, Collaboration, Introduction | 1 Comment »