I ride my bike to work everyday and, unfortunately, punctures are a regular hazard. In fact, it seems like I am forever buying new tubes. To try to mitigate this in future I have now bought myself a set of tyre liners. These are a nifty little product which sit between the tyre and the tube and are supposed to prevent any foreign objects that penetrate the tyre from puncturing the tube. Of course, as with any solution to a problem there is always a down side. The down side with the tyre liners is decreased performance.

What does this have to do with software development? Well, I see a very clear parallel in software development which is generally known as "feature creep". Feature creep is a term used to describe the gradual inclusion of new features which were not originally requested and can often result in time and cost budget blow-outs.

It is very easy to fall prey to this problem. I often find myself thinking "hey, wouldn't it be cool if the software did xxx?"; And it usually would be cool but I then have to ask myself what the impact of this new feature would be. Apart from the aforementioned budgetary concerns there is also the possibility that the addition of a new feature will impact on the performance of the software, introduce new bugs or problems into the software or decrease the usability of the software, none of which is obviously desired.

However, just because a new feature was not previously considered does not mean that it should not be added. So then it becomes a case of stepping back from the coalface and looking at the situation and evaluating, objectively, the usefulness of the feature and assessing it in terms of its likely impact on the project.

How do you avoid feature creep? There is no simple solution to this question as there is no way that every eventuality can be considered prior to commencement of a project. But there are steps that you can take to help mitigate its impact. The first and most obvious of these is clear documentation of the project prior to any work being done. Along with this documentation should come sign off from the client that what has been documented is what they need and require. Once you have this then any addition of new features becomes a simple evaluation of its usefulness and impact followed by renegotiation of project timelines if necessary.