My take on YAGNI

Recently there has been a long going post on the Extreme Programming newsgroup (http://tech.groups.yahoo.com/group/extremeprogramming/?yguid=198635929) about YAGNI. For those of you who do not know what YAGNI means please read this: http://c2.com/xp/YouArentGonnaNeedIt.html. Basically it started when some guy said that he thought XP got some things wrong and one of them was YAGNI. This of course caused lots of people to inquire/question him and out of it came several good posts. I sent some of these posts to an old colleague and he thought some people were over zealous about YAGNI. I do not doubt that people can become over zealous, no matter what you are talking about, but in this case I think the opposite is the larger problem.

Let me start with a story. At work a project came up that was for the CEO, and thus had high priority,vague requirements and an unmovable deadline! I pitched tackling this problem in an iterative fashion (Agile is becoming such a buzzword that I rarely use it in public anymore). The IT lead agreed and off we were. The team was me and a colleague (new to agile techniques and principles but liked all he had read). We couldn't dedicate much time to it as we had 2-3 other projects that had to take larger chunks of our time during any given week. We didn't have a prioritized list yet (customer was working on it with the CEO), but we did have the notion that the important thing was the landing page (the CEO doesn't like to click unless compelled). In our first working session we set up the project and hooked it up to a test page and viola we had a landing page...what next. We knew the whole point of the project was to display data and this data was coming from multiple sources (some internal, some external and some typed in) so we thought database. Then we asked, do we need it? One day yes, but not now. So we created a class and hard coded all the starting values in the code behind. This was obviously throw away code as the data must come from a database, but we got a landing page with real data in from of the team lead for direction in 2 hours spread over 2 days. He loved it and seems willing to stand up to the political forces that want us to design it all up front!

The moral I choose to draw from this story is that not doing something now even though one day, maybe even tomorrow, you will do it is a powerful tool. One reason is that software developers love to get ahead of themselves. My colleague came into my cube yesterday with a technical solution for a problem that we don't have yet. It was good that he was excited, but his (and mine) tendency is to solve the problem we sees coming because the problem we imagine is somehow more romantic than the problem right in front of us.

Our manager, not in line with the IT lead, did not feel comfortable with our approach, even though we are the two best developers in the company, because he wanted us to have solved all problems he could envision. Forget the fact that the customer wasn't even sure what he wanted...lets go solve "the problem he should be asking for" and ignore what he needs right now. It is hard to fight these forces, but knowing the technique works gives us stength to resist and carry on (I hope :-)

I am not saying that you should be blind of the future. You should always use your best judgement with the best information possible. I am just saying, and I think YAGNI is saying, be careful of your tendency to solve tomorrow's problem when today's problem can be just as challenging. In fact our last working session my colleague (the agile neophyte) re-directed our task list because I was focusing too much on back-end data issues on not enough on giving the customer value. I loved it! Our next set of tasks is still database free. It's coming...but we don't need it yet.