Published on April 14, 2010 by Steve Thomas in Web Development
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.
One of my favourite pieces of advise I have heard in the last year or so is that when someone wants you to change something about your product, start with no.
Just because one person asks for a feature, and even if it sounds in theory like a sound idea, it doesn’t make it a worthwhile idea to implement.
Instead you listen for the most frequently suggested features, and apply a filter culling off or modifying anything that deviates from your core product purpose. In other words, you make a feature work hard to be implemented.
This not only works for the frontend design that your clients interact with, but applies all the way down the line to programming and server administration.
A great example of this rule in action is to consider how a firewall should operate – start by allowing nothing, and allow access on a case by case basis, and only when absolutely necessary, allow something through.
As far as programming is concerned, don’t require everything just because you can’t be bothered building a decent function/class loading methodology. Start with nothing, and require additional code pieces as they are needed. It will pay big dividends when your load and application size increases.
I think we can all agree that there is way too much crap “out there” and that making aspects of our projects work hard for implementation ultimately results in a more clear, more simple end product.
It’s such a simple idea its almost stupid, and yet in the software industry at least, adding bloat is easy – producing something truly simple is infinitely harder.
Credit to the authors of Getting Real for this practical way of dealing with your audience.