Feature Creep: The Silent Killer

by debianjoe

bar

 

I have to credit a friend for the quote, but I have been revisited by this subject on numerous occasions as I’m what you might call a “minimalist designer” and I wish to bring it up again.

Don’t let feature creep overcome simplicity. I see this all the time — “How can I make <simple tool> do everything <readily available complex tool> can do?” Or the feature requests end up turning <elegant simple tool> into just another <bloated slow complex tool>. In my mind, you’re building a bicycle, not an SUV. Bicycles are the most efficient transportation system ever invented. – Pidsley

I really cannot express how accurate this is, and it’s one of the most destructive things for a FOSS project.  The Unix philosophy is “Do one thing well.”  Too often, once we accomplish this goal of doing one thing well, we start trying to do other things well from the same platform.  After some time, rather than doing one thing well, we are doing lots of things as well as possible.  This slows down our entire implementation for the original goal because now we’re loading up all of the tools to do all of the things that we want to support, which leaves us now doing the thing that we set out to do a little bit less efficiently than it started out.  Generally, though, it doesn’t stop there.  We add “just one more feature” or “just one little change” until now we’re getting errors and issues from all of the little additions that can totally break our project for some users.  For those people, we’re not even doing the one thing at all anymore.

This grows and spreads over time.  Everybody wants that “Just one more thing” added in until there are hundreds of things stacking up, and more things going on is equivalent to more potential sources of bugs.  More bugs require more fixes, and more fixes for things that were never the original goal is more pointless upkeep.

When designing a project, and I don’t care if it’s just a simple bash script or a huge compiled C program, always look carefully at what your goal is.  If something doesn’t help you achieve that goal, then trash it.  It’s often hard to toss out an idea that seems cool, but if it doesn’t add to the project directly, then it needs to go.  By doing this early on, you’re saving yourself a huge amount of headache over the life of any project.

Advertisements