When you’re working with 501 developers you’re faced with a huge number of problems and your chances of entering the infinite loop of failure are almost certain.
On the other hand however, working with enthusiastic young and budding developers doesn’t always guarantee success. Of the many mistakes that even young and enthusiastic developers often make, the 'Lets-Build-This-Cool-Feature' Syndrome is one of the most lethal ones.
If you’re reading this blog, chances are high that you are, more probably than not, passionate about software development. You have this itch to create software with cool features and user interface that would have people drooling over your software and clapping out loud when they see it.
You’re probably busting with ideas and features right now as you work on your product and believe me that’s a good thing. Not a lot of people in our world have this un-ending passion for software and computers; Having said that, the 'Lets-Build-This-Cool-Feature' syndrome can cause your project to fail just as fast as the 501 folks would have caused it to fail.
I love writing code and spend almost quite a few hours doing that. For the rest of the day, my job demands that I get involved with reviewing software products built by the organization and give ideas and direction to the product teams.
Recently while reviewing a system which is supposed to help organizations develop and maintain taxonomy of their skill-sets; I came across a small feature which allowed people to add every single page in this system to their social book-marking system. It was like an ‘add-to-your-favorite’ kind of thing.
My shocked reaction may have come as a surprise to the entire team as I criticized the feature’s existence in the system heavily and questioned the team on why the product needed that feature.
The ‘Why’ was answered by a rather passionate software developer's argument which was on the lines of – ‘Why not?’
This post is about answering the ‘Why not’.
The Single Word Answer to the 'Why Not' is simple. It's called ‘You-Ain’t-Gonna-To-Need-It’; also referred to as ‘YAGNI’ in the software development world. Wikipedia defines YAGNI as:
In software engineering, YAGNI, short for 'You Ain't Gonna Need It', suggests to programmers that they should not add functionality until it is necessary. Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them.".
Simon Willison describes how he puts YAGNI to use in his blog:
You Ain't Gonna Need It states that you should always implement things when you actually need them, never when you just foresee that you need them. This is great for controlling feature creep; the moment one of us says “we might need that later” the other says “YAGNI” and we can move right along.
The folks at 37Signals are much more passionate about building features only when they are genuinely needed:
Each time you say yes to a feature, you're adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature's out there, you're stuck with it. Just try to take a released feature away from customers and see how pissed off they get.
With products like Base-camp, Backpack-It and almost all their other products they seemed to have lived up to their words:
Make each feature work hard to be implemented. Make each feature prove itself and show that it's a survivor. It's like "Fight Club." You should only consider features if they're willing to stand on the porch for three days waiting to be let in.
That's why you start with no. Every new feature request that comes to us - or from us - meets a no. We listen but don't act. The initial response is "not now." If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.
In fact, Ron Jeffries takes YAGNI to the next level. He proposes that developers should use YAGNI even while writing code:
You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because "we’re going to need it". Don’t write getters for other instance variables because "we’re going to need them".
Scott Hanselman has similar very interesting post on why every class you write shouldn’t be marked public. The post has a quote that explains what can be otherwise described as a You-Ain't-Gonna-Need-It practice:
Scotts [sic] philosophy and that of many people at Microsoft (and many component vendors - Infragistics being another great example), seems to be to mark everything as internal unless someone gives them a reason to make it public.
I do understand almost all of us who feel passionately about software development, feel this yearning desire to build that feature which will have our users drooling and clapping, but 'growing up' as a developer, also means understanding that it’s equally important to resist the temptation of building cool features or writing more code, especially when the features or lines of code can't justify their own existence.
While asking yourself if you want to build that feature, write that piece of code, write a setter for that variable or mark a class as public, answering the 'why-you-need-to-do-it' becomes much more important than just blatantly asking ‘why not?’. Answering the ‘why not’ is easy: it's usually 'because you probably aren’t doing to need it'.
Unless you can answer the 'why' easily, that feature you’ve been thinking of building and have been very excited about is just another ‘cool feature you probably aren't going to need’.