“Feature Creep” is the tendency for extra, unnecessary features to gradually “creep in” to the basic requirements of a product. It is frequently cited as one of the top reasons why software projects become bloated, run late, and fail.
Who is to blame for feature creep? As developers, it is tempting to blame indecisive clients, or project managers eager to please their bosses by promising new functionality. I would argue however that many common behaviours of developers are equally to blame, and that it is our responsibility to alter our bad habits with either self discipline or by advocating for systematic changes in the workplace.
The three key patterns in developer behaviour which I believe contribute to feature creep are:
- Boredom, or the tendency to want to work on interesting problems rather than necessary work
- Perfectionism and needless attention to detail
- Fear of asserting their own knowledge and expertise
Most developers I know, including myself, would rather work on interesting technical challenges than mundane tasks. A passion for the difficult can sometimes be a benefit, but often this desire to work on complex tasks or new technologies can bias a developer’s judgement. Sometimes the tasks which are most important to the success of a project are the boring ones such as implementing business logic or adding widgets to the GUI.
The obvious way to combat this behaviour is to practice disciplined self-reflection. When considering working on some complex algorithm, ask yourself : “Is this really necessary to the success of the project? Or do I just think this is cool?”
This solution may be unsatisfactory for some people. Perhaps they believe that it is impossible to squash a programmer’s natural intellectual curiosity, or that it would be bad for employee morale to always prioritize the boring-but-necessary tasks. An alternative solution for these people might be to see if your workplace is open to the idea of compartmentalizing this curiosity.
Many companies (most notably Google) are known for adopting a practice they call “20% Time“. This is where employees are given a small percentage of their work week to work on whatever tasks related to the company that they feel like. The benefits of this policy are twofold: Firstly, employees are more amenable to doing some of the boring-but-necessary bits of software development, as they now have breathing space to explore more interesting technical challenges in their own time. Secondly, If something an employee is working on in their 20% time does turn out to be valuable, the company can reap the benefits.
Perfectionism and Procrastination
The flip side of my previous point is the tendency of developers to get bogged down implementing frivolous or needless features. The most notorious example of this is a developer’s tendency to add “Performance” as a requirement in projects which have little to no performance constraints.
Steve McConnell tells an entertaining anecdote regarding this behaviour in his book Code Complete. He recalls a time when he was sent in to fix a software project which was long over time and budget, but still not even providing basic functionality. Upon demonstrating his completed version of the project to the old engineering team, a senior engineer criticised his implementation for taking over twice as long to run as their original implementation.
At this point, McConnell quipped that the difference was that his system actually worked. If he was to relax that constraint, he could deliver a product that ran in zero seconds!
The point here is that developers will often subconsciously add their own set of requirements without considering their benefit to the main aims of the project.
A systematic way to combat this behaviour is to introduce a technique from the Scrum methodology known as Sprint Iterations. This is where software iterations are broken down into small – usually weekly – focussed tasks. In contrast to gradually implementing features over a long period of time, this technique makes it more difficult for developers to drift onto unnecessary features, as they have a clear short-term goal to deliver by the end of the sprint.
Having the backbone to say what you know
Even with the most competent, focussed developers in the world, people still often work in an environment with clients who are constantly suggesting “one more feature” and project managers who are eager to please by over-selling what can be done in the time available. Many developers I have spoken to believe these to be “the facts of life” and that there is nothing that can really be done about this. I don’t think this is entirely true.
In my time working as an intern at Amazon, I was exposed to a lot of their philosophy. One term which came up time and again was the concept of “Learned Helplessness”. The premise of “Learned Helplessness” is that even though developers are frequently in the strongest position to give advice on how difficult a new feature will be to implement, or how likely it is that the current workload will be finished on time, they will often not speak up because of a few bad experiences dealing with management in the past.
The developers at Amazon were determined to not let this happen to them, and made a point of actively “Pushing back”. “Pushing back” was their term for joining together as a group and actively resisting management requests for additional features when they thought that they were unnecessary.
This was perhaps one of the most successful working environments I have experienced because developers had just as much decision making power as the management. This allowed both groups to feel comfortable sharing their relevant knowledge and expertise.
Developers in all workplaces need to have the courage to speak up when they think that the project scope is running away from them, and shed the notion that “The customer is always right”.
Feature creep is a force that has been responsible for a multitude of project failures, and is often attributed to indecisive clients and failures on the part of management. However, I have hopefully convinced you that we developers often behave in ways that subtly contribute to feature creep. Developers need to be disciplined, take personal responsibility for these behaviours, and campaign to make changes in their workplace which discourage others from contributing to the creep.