Some say that Feature Creep was born into this world when the creator lost focus and forgot to write tests, and as a result our universe is doomed to a perpetual buggy pre-alpha status.
In the menagerie of software development metaphors, Feature Creep is among the most terrible of beasts. A great, many-headed serpent, with poisonous fangs made of manager’s whiteboard markers and a barbed tail forged from endless unmerged git branches, Feature Creep strikes fear deep into the hearts of developers everywhere.
It never sleeps, never tires, and has an endless, terrible hunger for one thing only: your time and productivity. With each member of a software team it devours, helpless and screaming, it grows another five heads and begins the hunt again.
“But those are just legends!”, many fledgling developers claim. “Feature Creep hasn’t been seen around these parts for an age! My methods of time management are flawless, I can forget about Feature Creep and will always deliver bug-free code on time!”. Statements like these only serve to tempt Feature Creep forward from the shadows, and quickly your team’s efforts will be so diluted fighting the beast, your project will wither and fail.
But don’t despair! I have done battle with Feature Creep before, and yet emerged triumphant. The beast can be repelled, and though it will always linger in the corner of your eye, your project can be spared by following carefully some simple steps.
Start using version numbers as early as possible
Your project is especially vulnerable to Feature Creep when it is young, fresh, and particularly juicy. In order to keep things on track, it is essential to put milestones in place, and enforce a cutoff point for new features before every release.
The best way to stick to milestones is to use a versioning scheme, it doesn’t really matter how you do it, but if you make sure you’re always working towards the next number and not a vague “pre-alpha status” or “initial release” you’re already halfway to fighting Feature Creep. Semantic versioning has become quite popular, but many other schemes exist and there’s nothing stopping you making up your own. Lots of people start off a project thinking that they will start versioning when there’s a bit more code to speak for, but soon you’ll lose sight of the important, core features and you’ll be easy pickings.
However, just putting numbers to releases isn’t enough.You need to set development milestones, with lists of features for each software version. Whether you’re working by yourself or in a team of a hundred developers, you need to sit down before each version and work out a list of features for the next release. With large teams to co-ordinate, it may be necessary to give a short time period where you’re allowed to add features to the list – but be very careful! If you don’t be strict and enforce your feature freeze, your project will pay the price.
Implement a development methodology
A software development methodology is a way of organising work and time so that it becomes easy to know what you’re doing now, what you’re doing next, what your buddy should be doing, and what you’re all working towards. It doesn’t really matter, in my experience, whether you use Agile, Waterfall, Spiral, Extreme Programming, or just Basecamp and Trello, finding something that works for you is the important step in managing the exponential growth in complexity of managing something as involved as a software project.
And that complexity is what the monstrosity will take advantage of to rend your project apart from the inside out. It thrives on the entropy of a disorganised team, and feeds on the essence of developers that get distracted because they don’t know what they should be doing next. The time spent wondering what to do will be time spent dreaming of features to add and new frameworks to try out. When you start losing your focus, you’ve sealed your own doom.
Do one thing, and do it well
Making your project the epitome of this, the Unix philosophy is a sure way to arm yourself against your foe. Apps that are large and complicated, that stick their fingers into too many pies and come out too messy, are not user-friendly and end up doing things improperly.
You should plan well ahead, and focus on the core features and use of your application when you decide what to work on next. If you always keep the core mission of your app in mind, it’s impossible to stray and make yourself vulnerable to the ever-circling predator of your productivity.
If your app is a ToDo list, you should not start thinking about adding an image editor and a media library for when your user wants to attach an image to a to-do. Instead, make a separate image-editing program and integrate it with your ToDo list. If your application is designed to provide a graphical interface for managing databases, it may be tempting to write a rich text editor so that users can use your program to store documents in databases. Wouldn’t it be much better to let the user choose their own text editor, and instead make your program interoperable with text editors that already exist?
Adding too many features can make your app intimidating and annoying to users, and can make it lose its focus. Your program should be a “short, sharp tool” that people can easily integrate into their lives. Feature Creep is best defeated with short, sharp tools that are precisely designed to defeat Feature Creep, so by following the Unix philosophy your team can remain focused on what matters.
Feature Creep has long plagued software teams, stunted the growth of startups, and even felled software giants. It can strike at any time, and exists wherever work is undertaken. Some say that Feature Creep was born into this world when the creator lost focus and forgot to write tests, and as a result our universe is doomed to a perpetual buggy pre-alpha status. If you employ the knowledge imparted in this article, you may not share the same fate. But be always aware of the beast lurking in the shadows, ready to devour your project at the first chance it gets, and remember that no-one is safe.