Creeping Featuritis

Problem: You want to satisfy your customers. You want to do the best possible job you can with your product, and thus win fame and fortune for yourself.

Forces: Programmers have big egos. Customers don't always know what they want. Programmers often miss the distinction between what's needed and what's "neat".

Anti-Solution: You get all of the programmers and designers together in a big room (aka DesignByCommittee) and everybody adds into the product what he wants. This process feeds off itself and everyone starts adding new features as the process continues.

Discussion: CreepingFeaturitis can begin, or continue at any stage in the software development process. It's most common in the Analysis stage, where it results in either an unending Analysis stage (see AnalysisParalysis) or in an unrealistically ambitious specification. In the DesignPhase, CreepingFeaturitis is characterized by adding more bells and whistles than were called for in the Analysis, or by trying to abstract everything before anything is ever made concrete. In the coding stage, it is characterized by coding that never ends as programmers continue to add "one more feature". -- KyleBrown with inspiration from JimCoplien

For another similar metaphor, see FeatureKarma.

Also called FeatureCreep.

For a discussion about CreepingFeaturitis in programming languages read "Growing a language" by GuySteele http://research.sun.com/features/tenyears/volcd/papers/14Steele.pdf -- MarcoMaggesi

Try this one. Start a project with the intended aim of porting an application from one language to another. As you go along, your customers complain that the application they wanted ported no longer meets the business needs of the organization. Allow a weak project management team to enforce changes against the recommendations of the project manager and the technical team. Result: a project intended to last 6 months, lasts 2 years and is only killed by being handed over to another supplier.

I need to ask whether there is any public corporation where schedules are decided upon by developers and not unilaterally hoisted upon them managers. C3 perhaps, but what about when the development has as its goal a product for sale? If anyone knows where better to relocate this topic, please do it or advise.

See CreepingFeaturitisWarStories.

I reckon most of the projects in public corporations that are in maintenance mode (i.e. past version 1.0) use some variation of the planning game, which means developers effectively decide schedules. Most of the projects that are still working on v1.0 are dealing with hoisted schedules.

This phenomenon has fascinated me for a while. Most managers believe that new projects are riskier than enhancements, and the empirical evidence is that they are correct. So the spotlight gets turned on the new projects, which means that deadlines and ambitions get published earlier and wider. Deadlines created early are inevitably less realistic, so usually a DeathMarch Project ensues, and soon more evidence is accumulated to 'prove' that new projects are risky, and the cycle repeats.

All of this is a great argument for delivering v1.0 as soon as possible, so you can get out of the spotlight and get on with delivering useful software.

Developers aren't the only source of "neat" features. I have in mind a customer who is loved by upper management -- but the production staff on his projects has about a 50% desertion rate. He finds "neat" things on web sites and demands copies for his sites -- whether or not they fit the site's mission and audience.

In my mind, the word "neat" has become an obscenity.

Perhaps you could use 'neato' instead.

Here's another fun way to get into trouble:

You work on a small team, that is itself part of a very large project. The large projects schedule slips regularly, sometimes by months at a time. Since you know there will probably be another slip (and you are well versed in the ways of ScheduleChicken) you might as well throw in a few features that got cut from the original plan.

The great thing is that on a really large project the next slip is almost never your fault, and the other 90% of the time you win. On the other hand, consider what happens if you don't add your features. You'll breathe a sigh of relief if the big slip never happens, but in the likely event that it does you end up sitting on your hands. Sure you can declare a sort of moral victory, but what's that compared to the 90% shot at glory?

In this case, don't add the neat stuff. Ask if you can help on another project. In any organization, there has to be other work that needs to be done.

Keep in mind that "you" are not a single person, but a team with 20 or 30 developers. It may be possible to work on something else, but it's much easier said than done.

What manager is going to turn his programmers over to another manager to cover their shortfall instead of grabbing glory? I don't think there is one, loosing all your power because someone else screwed up? This is all leading to ManagementByCrisis.

Also keep in mind that these features aren't nifty chrome born in the overactive imaginations of idle programmers. They're things that your customers are begging for, but couldn't be completed before Big Project's original ship date.

The original plan was to wait until Big Project v2, which was going to ship in the third or fourth quarter of 1999. Now it looks like Big Project v1 is going to ship in the third or fourth quarter of 1999. No one has any idea when v2 will ship, but you're pretty confident it's going to be a long wait. You are not sure that you'll still have any customers left by then.

When I joined TektronixInc I attended an engineering orientation where the founder of the company, Howard Vollum, spoke. After a few light comments about his long-time rival, HewlettPackard, he focused on our real enemy, creeping featuritis. I was struck by his intensity. It took me a few years to integrate his comments with the company motto: committed to technical excellence. He was right, of course. You'll never find the exquisite solution to a real problem if you are busy tending little problems of your own making. -- WardCunningham

I guess it is okay to tell the truth about people with the engineering mindset, since I am one. "Engineers are people who love to solve problems. They love solving problems so much, that, given no problems at all, they will invent some to solve." -- MichaelFeathers

The JargonFile mentions the synonym Feeping Creaturitis.

The explosions of nice-to-have features is a killer on many projects. 60% of the requirements are "discovered" during the implementation phase, which I think shows how poorly one actually can accomplish product "visualization" during requirements and initial design. As a result I try really hard to get the features prioritized into "must haves" and "nice to haves" and define a prioritized "core functionality" to use as the initial product baseline. Then you can go forward with a prioritized list of "builds" that gradually add the "nice to have" functionality. Trying to jam everything in at once gives the schedule of bizarre feel. Also when every one of a zillion things is important, then nothing is important. CorePlusElaboration? is the way to develop almost anything, especially if each CoreElement? is carefully chosen and integrated into the product. -- RaySchneider

Marketing people get paid real, actual money to do the research on what products we are supposed to build. They get paid to talk to real, actual users of real, actual products that perform real, actual work. Why, then, can't they come up with a single set of criteria to specify a new product? If we as engineers and developers don't hold their feet to the fire on hard specifications we'll be forever and ever (amen) shooting at a moving target.

Okay, I don't mind. I'm just a slimy consultant squeezing every last overtime buck I can get out of these guys. But wouldn't it be nice to create a real, actual product at the end of all this? -- MartySchrader

[ The text below is in response to an objection - since removed - that the customer may specify requirements that excessively constrain our abilities to support easily-predicted future requirements, and we should add the necessary support for these features even if not expressly asked to.]

Part of the PlanningGame is (should be) the effect our expertise has on the client's perception of what it is he really wants. Client may ask for the very bare minimum that will get the job done right this moment, but it is our duty to point out that this moment will only last for a short time. Then he may need a little bit more. Offer him an opportunity to buy into a little breathing room up front. If he takes it, great. If not, then tough toenails. The Customer Is Always Right, right? Look, if he doesn't want to use all this expensive experience and knowledge he's paying for, do you want to shove it down his throat? Nah. Let it ride.

As a side note, but completely central to this whole discussion, is the matter of separating must-have from nice-to-have. This is what we create an architecture for, people. This very thing is what we crush when we have a nice, clean architecture that says such-and-such an operation is vital to the product and so-and-so an operation would be icing on the cake. Toasters and coffee makers.

For sure "adding" features is more easy than adding features that "truly works" (i.e. that works even in "corner cases"...). The same people that love adding features often hate fixing bugs plaguing some previous feature they "added" (because the time spent fixing would distract them from doing what they love: adding more "features"). A way to regain control of a project that suffers from too many features of too poor quality is to enforce the FixBugsFirst principle. However this is easier said than done. -- JeanHuguesRobert

If you are lucky (!) and the project is in trouble, then the solution of dropping troublesome creeped-in-features is available to you. Doing so will help your FixBugsFirst strategy succeed.

Sadly, some clueless PHB or other will think that dropping core features will "help" the project along, also. Never mind that the feature being removed is central to the operation of the product or that it is already in place, save for a UI implementation. Oh, well.

See: GoldPlating, JustOneMore, FeatureInteraction, LanguageIdiomClutter

CategoryAntiPattern