Is there a common programming term for the problems of adding features to an already-featureful program?

Question

I'm looking for a commonly used programming term to describe a software-engineering phenomenon, which (for lack of a better way to describe it) I'll illustrate first with a couple of examples-by-analogy:

Scenario 1: We want to build/extend a subway system on the outskirts of a small town in Wyoming. There are the usual subway-problems to solve, of course (hiring the right construction company, choosing the best route, buying the subway cars), but other than that it's pretty straightforward to implement the system because there aren't a huge number of constraints to satisfy.

Scenario 2: Same as above, except now we need to build/extend the subway system in downtown Los Angeles. Here we face all of the problems we did in case (1), but also additional problems -- most of the applicable space is already in use, and has a vocal constituency which will protest loudly if we inconvenience them by repurposing, redesigning, or otherwise modifying the infrastructure that they rely on. Because of this, extensions to the system happen either very slowly and expensively, or they don't happen at all.

I sometimes see a similar pattern with software development -- adding a new feature to a small/simple program is straightforward, but as the program grows, adding further new features becomes more and more difficult, if only because it is difficult to integrate the new feature without adversely affecting any of the large number of existing use-cases or user-constituencies. (even with a robust, adaptable program design, you run into the problem of the user interface becoming so elaborate that the program becomes difficult to learn or use)

Is there a term for this phenomenon?

• SJuan76: It seems like you are asking two questions here: one about the difficulty of maintaining a badly designed system and other about the feature creep that Michael Borgwardt identified (complex UI as a result of increased number of features). In fact the expression "even with a robust, adaptable program you design you run into ..." seems to acknowledge that there are two different issues. Your question is about the second one, but your metaphor of the Los Angeles subway is related to the first one.
• Jeremy Friesner: A bad design definitely exacerbates the problem, but even with a good design, things eventually get "crowded" and therefore more difficult to modify or extend without stepping on someone/something's toes. I'm looking for an expressive shorthand for that; maybe creeping featurism is it. (I wasn't necessarily intending Los Angeles to be an example of a bad design, rather a non-trivial, long-established, heavily-in-use, 'crowded' design)
• Jeroen Vannevel: Bloated is a term I see often in this context.
• david.pfx: Creeping featuritis we used to call it.
• Giorgio: If your design cannot integrate new features easily, I would say it is rigid (the opposite of flexible).

Answer 1

Feature creep or creeping featurism:

1. Describes a systematic tendency to load more chrome and features onto systems at the expense of whatever elegance they may have possessed when originally designed. See also feeping creaturism. "You know, the main problem with BSD Unix has always been creeping featurism."

2. More generally, the tendency for anything complicated to become even more complicated because people keep saying "Gee, it would be even better if it had this feature too". (See feature.) The result is usually a patchwork because it grew one ad-hoc step at a time, rather than being planned. Planning is a lot of work, but it's easy to add just one extra little feature to help someone ... and then another ... and another.... When creeping featurism gets out of hand, it's like a cancer. The GNU hello program, intended to illustrate GNU command-line switch and coding conventions, is also a wonderful parody of creeping featurism; the distribution changelog is particularly funny. Usually this term is used to describe computer programs, but it could also be said of the federal government, the IRS 1040 form, and new cars. A similar phenomenon sometimes afflicts conscious redesigns; see second-system effect. See also creeping elegance.

-- From the Jargon File, a compendium of the (originally) 1970s MIT and Stanford hacker subculture. So yeah, you could say that it's an established term...

• Arseni Mourzenko: I also thought about feature creep, but I don't think it is the appropriate term here. In Los Angeles example, there is no feature creep: there is a basic requirement, which is confronted to a large amount of constraints. An example of feature creep here would be: "I want to build a subway, and I also want to use the tunnels for merchandise transportation, and I want to have restaurants in every station, and trains should be able to pass from line to line at every station, and the rails should be able to support any type of trains currently in use in the world."

Answer 2

Based on your two examples - this is simple program extension - and that's all it is - it doesn't matter if your program is simple (Wyoming) or complex (LA), in both cases you've identified a business need for new features and are going to design them in. Feature creep would involve features of questionable value - or possibly involve features better implemented by separate software.

I don't know if there's a specific phrasing to describe extending an already complex software - but this would be where documentation (blueprints) and code/project management will start to be really useful. Regression testing (no real analogue to subway construction) would be extremely useful here, too.

Answer 3

Gold-plating: from wikipedia continuing to work on a project or task well past the point where the extra effort is worth the value it adds (if any).

http://en.wikipedia.org/wiki/Gold_plating_(software_engineering)

Most of the gold-plating I've seen/heard about isn't an exact fit for the scenario you give (extending a simple subway to LA), but is a good definition.

Answer 4

Technical Debt is commonly a cause of this phenomenon. What worked on the small project, the steps that you skipped or were able to cheat or brute force your way through, are likely to be the safe guards and QA checks that are required to manage larger projects. As your project scales you may find that previous pragmatic decisions, however justified or practical at the time become impediments to future improvements. This applies equally to reusing a code base that worked for 10 concurrent users and finding out that it doesn't scale at all, or the effort and costs required to scale to say 10x were exponential, lets say 100x or 1000x, not linear as may have been originally expected.

Scope Creep certainly comes into this, but that more refers to underengineered or poorly managed implementations where features are added without proper due diligence or where the original focus has been obscured and you evolve the requirements beyond your ability to recover costs for your effort.

Answer 5

I sometimes see a similar pattern with software development -- adding a new feature to a small/simple program is straightforward, but as the program grows, adding further new features becomes more and more difficult, if only because it is difficult to integrate the new feature without adversely affecting any of the large number of existing use-cases or user-constituencies.

That is the evolution described by Moore's law until faces the uncertainty principle and it is probably the most accurate definition of done (DoD) from agile methodologies.

Moore's law is the observation that the number of transistors in an integrated circuit (IC) doubles about every two years. Moore's law is an observation and projection of a historical trend. Rather than a law of physics, it is an empirical relationship. It is an experience-curve law, a type of law quantifying efficiency gains from experience in production.

The uncertainty principle, also known as Heisenberg's indeterminacy principle, is a fundamental concept in quantum mechanics. It states that there is a limit to the precision with which certain pairs of physical properties, such as position and momentum, can be simultaneously known. In other words, the more accurately one property is measured, the less accurately the other property can be known.

According to Conway's law the complexity it is caused by the system designers.

Conway's law describes the link between communication structure of organizations and the systems they design.

[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

according to wikipedia.