When YAGNI Is Confused With YRGNI
A couple of weeks ago I wrote about The Semi Myth Of YAGNI. The message of that post was that there are cases where trying to anticipate the future evolution of the product is the best approach. In those cases, doing the simplest thing possible today without analyzing where the product is going is also a bet. A bet you better not make.
Let’s explore a simple application of this conclusion. Don’t try to pronounce it, but I call it YRGNI (You Are Gonna Need It… but not just yet).
Here’s the thing. You’re working on a component and you really don’t want to over-design it. You know that in a month this component will have to do a couple of things. At the same time the first couple of iterations don’t require all this functionality. They only need a subset of it. Isn’t that the classic YAGNI case?
In an Agile spirit you start working on that component. You really don’t want to make things more complicated than they should be. So you design a very simple interface for the component. The interface you design reflects only the subset of functionality needed for the first iteration. And everybody’s happy.
Then, comes along the second iteration. The new functionality is now required, so some refactoring is in place. So, you change the interface. A couple of weeks later, you change it again. And again.
The problem starts when you realize that other components in the system should interact with your component. With every change to the component’s interface there is a danger that some other component will break. True, you are trying to continuously integrate all components. But the whole point of continuous integration is to succeed in it. Breaking the component’s compatibility is certainly not the point.
This is a common example where YAGNI is confused with normal and anticipated evolution of the product. You know you are going to need the new functionality. You know you’re going to change the interface. Even if you don’t know that for sure, there is a high probability you will. The cost of changing the interface one step at a time is in breaking the component’s compatibility and messing up the integration (and confusing a couple of developers). In fact, this is not embracing change – it’s creating change with our bare hands.
When you are going to pull out the YAGNI rule, stop for a moment and think: are you really not going to use it? Maybe, just maybe, you know you are going to use it but not just yet. In such cases (and especially when you consider the published interface of the component) don’t hesitate: go ahead with a longer-term design.
When done consciously, this is not Big Design Up Front. It’s just good design.
July 5th, 2006 at 8:51 am
Very nice post. Shame no one has commented yet. Maybe it’s just too sensible to provoke any response? At any rate, it is nice to see someone out there vocally tempering the advice of the Agile aesthetes with some common sense limits. There are many people are far too ready to accept guideline as gospel. They can use these kinds of corollaries.
I guess in short, simplicity of implementation is a goal, and a good one. But it doesn’t necessarily trump all others, and it’s not the only place where simplicity is beneficial. Simplicity of integration is also important. And as Mr. Wyssocky has pointed out, there is usually a trade-off between immediate simplicity of implementation and near-term simplicity of integration. Rather than forsaking one for the other, we should strive for balance.
July 5th, 2006 at 12:46 pm
Thanks for the feedback WaterBreath!
Lidor
July 5th, 2006 at 10:13 pm
I’ve found that in many cases all the methodology rule-sets (like Agile, XP, et. al.) are actually superfluous; they can all be reduced to a single guiding principle:
Don’t be stupid.
Unfortunately, those who are capable of actually carrying out this rule tend to be far enough along as programmers that they don’t really need to memorize a lot of rules to get their jobs done ;-)
July 5th, 2006 at 11:30 pm
I agree with the primary focus of this post. It does, however, assume a couple of things. First, it assumes you know your component is going to be doing something else in the future (or expanded functionality). That is sometimes elusive information. Second, it assumes that you are going to be the one doing the repeated changing later. If you aren’t, then you have to weigh the cost of doing it now (with your presumably superior knowledge of the problem space) against letting someone else (possibly less informed) do it later. If you aren’t going to be around (short contract, taking another job, this project is being sold to another company, etc.) and you aren’t sure how things are going to go in the future (will the component change in a predictable way), maybe *You* aren’t going to need it, even if someone else might. And while I am all for doing what’s right for my employer, sometimes there are more pressing matters that must be finished before you go.
July 6th, 2006 at 12:29 am
Hi Joshua,
You are, of course, right. Your observations stress my point: this decision (like many others) is context sensitive.
I am not suggesting that one way is better than the other. I just argue that you have to consider both options on a per-case baiss.
As Apoch hinted: use common sense. Don’t follow any rule blindly.
Lidor
July 6th, 2006 at 4:23 am
Why do you keep changing the interface? Why don’t you extend it, or create a new interface, or a new component? Or an adapter?
July 6th, 2006 at 7:16 pm
A particular case came to mind where YRGNI can happen quite often: data warehousing. Of course YAGNI happens often there as well, but the post was about YRGNI ;)
Anyway, in data warehousing it can often be the case that waiting to add a feature until it is “needed” equates to a huge increase in implementation effort down the line. Large databases are notoriously rigid, even when well-designed. And that means that making things easily extensible is much more difficult. Or worse, waiting means that the feature won’t have the necessary historical source data to start with.
For example, if the feature that we “might need” in the future is a certain summary report of data that is not currently kept in a backlog…. Say it’s January now. And in June a decision will be made whether the report will be needed. Should we get the backlog in place now, even though the report it is for may not be implemented? Well, that depends on the user requirements. It may be critical that, if the report is implemented, data is available for the entire year. In that case, if we wait to put in the backlog till the report is green-lighted, the users won’t really be getting what they need. So the prudent choice may very well be to put the backlog in place and start collecting data now, even if it may never be needed.
Probably not the greatest example, but it’s a lot more concrete for me since a data warehouse is my primary responsibility at the moment.