This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: YAGNI Revisited - Waste Not Want Not
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
I first heard the term You Aren't Gonna Need It (YAGNI) in the book XP Explained about six years ago.
At the time, I understood it to mean that building overly flexible (and usually complex) frameworks and models in your software was A Bad Thing. The idea was that since the requirements might change suddenly, and you don't have a crystal ball to predict the future, the time was probably not well spent.
This seemed especially relevant to me in terms of blue sky architectures I had encountered on previous projects that tried to solve a whole host of problems that we didn't even know were problems yet.
Since then, I've heard others argue the point as if it were some sort of Commandment:
Thou Shalt Not Covet Frameworks Until Thou Absolutely Needest Them
The rise of Test Driven Development (TDD) and Refactoring has caused even more widespread adoption of YAGNI, and even caused endless debates along the lines of:
Developer 1: Well, we should just hardcode a return value of one here, since that will make the first test pass Developer 2: Doh! That's ridiculous, we know that won't be the final solution, let's just calculate the answer! Developer 1: But this book said to do the simplest thing that could work, and the other book I read yesterday said YAGNI! All of the cool thought leaders are saying it! Developer 2: Sigh...yes, they said the same thing about pair programming.
Can we really take simplified phrases out of context and apply them to every detail of development work?
Maybe, but I'd prefer to look at the whole debate from a different viewpoint - the "Lean Thinking" one. Lean is a concept from the manufacturing world that has been slowly gaining traction in software development as the concepts are explored further. Tom and Mary Poppendieck's work is an excellent place to start.
So "Eliminate Waste" is the Lean principle that seems to apply to YAGNI and it's cousins.
What constitutes waste in software development? According to Lean proponents, it's:
Extra features: Things we build that no one asked for, and isn't likely to use. I see this happening all of the time in small ways. "Oh, we should add a calendar widget here in case the users want to see what day the holiday party is on while they are entering the invoice data".
Churn: Constant change in requirements (Make it blue...no, red...wait...green!), or constant test and fix cycles (Ok, we fixed the Calculation Bug...oh wait, we added a Storage Bug...ok, that's fixed...NO, not the Nuclear Bug!!!)
Crossing boundaries: Any "throw it over the wall" behavior, even if it's done nicely.
Lean also talks about "queues" and how anything that results in backups is considered waste. Until a customer gets a product in their hands, and it delivers the business value they are paying for, software development is just a cost without a payoff.
So, back to YAGNI. Looked at through a Lean lens, are the activities, features, frameworks and modeling you are doing adding immediate value? Or are they delaying delivery of that value?
Before I get carried away, I'll say this: waste cannot be completely eliminated. I'm not even sure that would be a good thing. I've had some of my best ideas while wasting time. But approaching software development with an eye towards reducing waste can have a profound positive effect on your process.
Previous Topic
