Featuritis

by Krishna on February 25, 2007

“Featuritis” is a term used to describe the condition when the software product undergoes multiple rapid changes in functionality that were not anticipated during the initial stages of the project. This happens very frequently for in-house projects, but by means restricted to them only – any software product development may exhibit signs of featuritis. The typical scenario goes like this:

  1. The software project starts with the intention of solving a few simple problems.
  2. The development team gathers and analyzes the requirements. They come up with a development and rollout plan.
  3. As the product shapes up, end users are requested to look at the product and provide feedback.
  4. If there are many suggestions and complaints, the team is now forced to include some of the high-priority ones in the rollout.
  5. This affects the original plan and also sometimes plays havoc with the design and logic assumptions in the product.

It goes with saying that most development teams usually get really upset and frustrated with changing requirements. Just when they thought that they had a good handle on what and when they were going to deliver, the rug is pulled under them.

Even worse is the fact that some suggestions may actually conflict with the original assumptions or requirements on the project. For example, the original requirement was “We just need one address for a contact – just the permanent address.” Now that changes to “We should have multiple addresses per contact.” Such changes can require extensive rework on the application.

Here are some common suggestions regarding how to avoid featuritis and what I think are their limitations.

  1. Say “no” to changes until the current plan is fully executed: This may work out well for the development team, but it can be very detrimental to the company’s marketing efforts. Some new features are driven by competitors. Even when the product is only used in-house, the value of a certain unavailable feature may make a lot of difference to the company’s bottom line.
  2. Design for changes in the system: For instance, in the earlier example, what is stopping the team from creating a DB design that allows 1-to-many relationships between contacts and addresses. The problem is that anticipating and designing for all such changes can expand the development effort considerably – this translates into greater expense.
  3. Design a flexible system: The plethora of application frameworks is a testament to the failures of developers to build code foundations that can support any change. It is very difficult to build a system that is completely flexible – simply because of the fact that humans build them and they cannot anticipate what the future holds.
  4. Do a better job of collecting requirements: This is a good way of ensuring that some basic wrong assumptions don’t get written into the system. However, sometimes, even with good prototyping, end users don’t really know what they need until they actually use the system. The reason is that when people actually have to use the system to solve their problems, there is a fundamental change in their attitude towards the software. They are much more demanding and passionate about missing features.

I think that one way to this problem is to expect change and embrace it when it happens. As a development team, do not get emotionally attached to a particular design or project schedule. Make the development process dynamic by constantly revisiting the planned tasks and their priorities.

This requires a fundamental shift in the outlook of the development team. Instead of working towards a complete system on a certain date, there is an indefinite development cycle where each feature is prioritized and done. By doing this, the project plan becomes subservient to the interests of the end users, which can contribute significantly to the success of the product.

People familiar with Agile methodology will definitely see the similarity here. I am not advocating a wholesale migration to Agile or rejecting the other suggestions (1 to 4 above) outright. They have their place. It is sometimes necessary to reject some features as not meeting the project goals. It is important to do a good job of requirements and design for change. But all this should be done without rejecting the reality that change will occur, no matter what.

Comments on this entry are closed.

Previous post:

Next post: