Beware! Feature Creep Has Downsides!

Feature Creep: The misguided notion that somehow, more is always betterToday, I want to talk a bit about feature creep.  First off, let me say that I’m going to be performing my own voluntary feature creep in this post by adding a podcast version and a video one.  Take a look at the next post once it’s up and I’ll do a vid for the both parts (I was just getting long in the tooth by the end of this one).

Feature Creep

My programming friends, as well as most engineers I know, already understand the concept, but bear with me.  Feature creep is a situation in which a scope document was created with requirements before the project started.  Once underway, however, someone (usually at a higher level, or even a customer level) requests a new feature to be added.  It may be fairly innocuous, or potentially larger in scale, but in the end, it is another feature that was not included at the beginning.  One new feature really can’t be considered “creep”, now can it?  Ok, so the creepiness comes from the fact that it’s not one, but generally, many new features requested, not included in the original scope.

Who Cares?  That’s What We Pay Them For!

True, you (managers) pay your engineers to complete projects that need to be done.  And also true, that those features must be super cool if you’re asking for them to be done.  There are some problems with feature creep though, namely:

  1. More time is required to implement new features.  This sounds like a “duh” kind of statement, but for some reason, managers don’t seem to understand that fact.  Obviously, the engineers are inflating work estimates anyways to get some more time for browsing the internets (yes I pluralized that for fun).  I have found that in the majority of estimates, these kinds of inflations don’t occur.  Engineers design the plan and work the plan, basing their estimates on what they really believe they can accomplish.
  2. More time is required to implement new features.  Yes, I repeated myself, but this point is slightly different.  When new features are requested, the engineer generally NEEDS more time.  This means that the time-table of the project SHOULD be extended.  I have had so many situations in which features are requested that will take an additional week of work, and the project managers say, “We can’t push the date back.”  If you go to the store and have just enough money to buy your deodorant, if you pick up a container of ice cream too, some milk and cookies (I’m feeling sweets right now), walk up to the counter and plop it down, the cashier will NOT let you take the items with only enough money for the deodorant that you likely forgot on the way to the ice cream!  Just because you want more, does not mean you can have it just because you ask.
  3. More requirements equal more money spent.  Let’s assume that you can push the date out slightly for the new features.  That’s great, but what are you really doing?  You’re increasing the cost of engineering time, obviously, but you’re also increasing testing time too.  Sometimes, seemingly innocuous feature additions can have some very interesting bugs attached to them.  So not only are you increasing the engineering time for development, but also testing, bug fixing, and not to even mention documentation of the new features (I’ll assume your customer would want to know how to USE the new feature).
  4. More requirements can impact system design and robustness.  Not always is this applicable, depending on the scope of the implemented function, however, systems are designed to perform the tasks they need to perform.  If you need a simple system that accepts employee hours and comes up with summaries for year-end reports, your design will be MUCH different than if you need a system that will be scalable to incorporate plugins for new functionality that may be needed in the future.  Or, for example, if your system needs to handle a small amount of traffic by users, it will be designed with one particular database technology.  If, halfway through, you decide you want to deploy it on a massive scale with millions of hits an hour, that database technology may be insufficient.

Are there more implications to feature creep that I haven’t mentioned?  I’d love to hear your thoughts!

Update: Check out the sequel: The Dangers of Feature Creep