The (Semi) Myth Of YAGNI
Welcome back to the “Only Part of the Story” show. In today’s episode, we are going to revisit one of the most common Agile statements, which seems to make a lot of sense. But as you can guess, it’s only part of the story.
We will do that with the help of this blog post by Simon Baker from the Agile In Action blog.
“By focusing on only today’s needs you write less code and that can only be a good thing in my mind. It’s quicker to write less code, and coupled with a simple design and merciless refactoring, it keeps the implementation small and testable while reducing the opportunities for defects […]
Focusing on today’s needs also applies to the architecture. I favor evolving an architecture over Big Design Up Front.”
Simon Baker’s post describes the already well known concept of YAGNI (You Aren’t Gonna Need It), which does sound extremely reasonable: why worry today about things which might be needed tomorrow. A lot can change by then. Implementing or designing a feature today, when you are not sure it will be needed, is a bet. In most cases, Simon Baker claims, this is not a bet you should take.
Well, as always, reality is somewhat more complex than that. I can easily accept the idea that we should not implement features which are not yet needed. We should certainly focus on delivering the features needed today. However, when it comes to architecture and design, a slightly different approach is required.
Let me start by saying it clearly: I do not favor Big Design Up Front (BDUF). I really don’t. Working on each and every detail of each and every future feature is not only a bet in most cases, it is also quite tedious. However, you cannot create the basis for a good architecture when considering only the features that need to be implemented in the next couple of days.
Refactoring code is one thing. But changing the architecture, or even the smaller scale design, every week is far from being cost-effective and safe. It confuses everyone involved: designers, developers and testers. And it doesn’t matter how well they communicate.
Architecture and design is about looking into the future. At least to some extent. There are a lot of things we don’t know in terms of the product’s evolution. But let me assure you: an experienced architect does know a lot about the potential evolution of his product with high probability. He has to.
Based on his experience and on the ability to ask the customer the right questions, an architect can build an architecture which has a good chance to be a solid basis for the product’s evolution. He shouldn’t try to anticipate every little detail. But he should set the framework (the boundaries) for the product to help the developers, the customer and himself move forward in the right direction.
No one says that this is a clean bet. But it can be a calculated and safe bet. And if it is a safe bet, it is by definition more cost-effective than planning one day at a time.
The thing is that making no bet is also a bet. It can be proved to be “wrong” just like any other bet. The goal should be to minimize the surprise effect, and this can be done at the architect level using common sense, experience and communication with the customer.
When it comes to architecture and design, the meaning of YAGNI is not as clear as it is with code. In some cases, trying to plan for the future after in-depth calculated analysis is more cost-effective. The architecture will still evolve. Changes will still happen. And unknowns will always be part of the game. But these facts should not lead you to giving up on the attempt to anticipate the product’s evolution. Wisely.
June 12th, 2006 at 6:20 am
[…] An excellent post questioning whether the oft heard Agile zealot cry of YAGNI is always justified. Lidor doesn’t say YAGNI should be abandoned or that BDUF is the way to go. He says quite pliantly that although YAGNI makes sense on the surface, “reality is somewhat more complex” and sometimes making the bet to invest in the future based on experience and the context you are in is a good bet and is the right thing to do. […]
June 13th, 2006 at 7:40 am
This is so obvious that there wouldn’t even be the need of mentioning it, had not the Agile warmongers brainwashed the rest of the community. Any thinking person should realize that following any single methodology to the extreme will not pay off in the end. It’s the law of moderation!
September 4th, 2006 at 5:47 pm
It occurs to me (coming back to this a while later) that, if YAGNI is a good argument for code, it is an equally good argument for the comments in the code. Most comments are written for the hypothetical person who’s reading the code some months from now, not the person who’s writing it today or tomorrow.
I think this constitutes a reductio ad absurdum proof that YAGNI is not always justified.
January 12th, 2008 at 4:32 am
Nice post. However, it might be useful to take YAGNI as the question and not the answer. The best architectures evolve but if your project adds value by deciding on an architecture upfront - its always useful to go for it. Thats not “always” the case but not to say that can’t be the case. Any which way, if you are making a decision right now, you would always have a solid case for why you are doing it right now. The solid case generally comes from cost-opportunity argument. If something has a solid argument backing it, it would always be a top priority and you would need it. As you would need it, it would be YAGNI :)
February 5th, 2008 at 9:47 am
Communication - Key to Effective Parenting
Exasperated parents often tell child counselors that they have almost no communication with their children. Once a child feels that she is growing up, especially at the onset of adolescence, she will start to distance herself from you and begin to talk…