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."[1]. |
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’.
Still it's precious, for it involves exchange of thoughts, exchange of visions, exchange of desires, exchange of expertise and so many other things.
But.......when you ask "Why YES?", you at the same time also mean "Why not NO?". :) They are always twinned. Things are not always as they look to be, things are as you want to see them.
As for YAGNI, it's true. You need to focus, focus on needs first. You need to learn to control temptations, b'coz it's endless. You need to know what to do and what not to. That's a very thin line, but is a life saver at times...worth following. We all do because it unarguably makes processes successful.
But ain't it that an Innovation is a child of creativity? That's why we hear of companies giving "paid" time to their staffs for their own creative projects (things that company hasn't seen yet, don't need either....but still they care for).
The world will not end if new innovations are not born. The world is running & it will. People will take birth, people will live happily ever after, and they will die to rest in heaven. But we have innovations to ease our life, to make it a li'l better, a li'l easier. We never needed iPOD, we enjoyed listening music on a heavy, fat & ugly looking gramophone player. But then we saw evolutions. And now, iPOD is in everyone's wish list. I can't help commemorate the statement, "Needs are created". That's another exciting topic to argue :)
Taking out one line from my own blog site: "When you ask others 'why?', ask Yourself 'why not?'. Most of the questions will be answered automatically."
Still, needless to say that "Why vs Why Not" is always useful, for everyone. Because that helps, helps grow.
Cheers,
The 'Why not?' guy :)
Comments are closed.