So I have a program I’m worked on back in 2011 and all through 2012, but the last release was in December of 2011. I’ve been actively working on it, but feature creep lured its ugly head and now it is filled with tons on unfinished features.
The bad part is that as I implement a feature, a new one creeps in. What can I do to avoid feature creep in the future so I can actually get a release out in over a year?
The project is based around iOS and used to have releases around each iOS version update, but the last one was back with 5.1 (2011). I would like to be able to get that steady release cycle back, but it has proven too difficult.
8
In my experience, it’s easiest if you can have a development and release cadence that doesn’t get in the way of what you want to get done. Here’s how I’ve done it:
- Write the features down, and give them a rating that reflects how much you want to work on it and how much you think it will benefit the user (it may be possible to engage actual users for this). Then write them in that order.
- Before you check in/push a feature, make sure you have a stable, deployable build (strongly consider a CI system to facilitate that).
This way, you can just push a release after each feature if you want… or wait for a rollup that offers the value that you want a release to have.
Note:
- A feature can never be given a higher priority than the one you’re working on (or it can, but it can’t interrupt the one you’re working on). It can come next but never now. That means that when you go from now to next, you’ll have the opportunity to cut a release build if you want.
3
The answer is trite and frequently impossible: refuse to add additional features.
In more depth, the answer really comes down to what makes a new feature fall into the feature creep bin? If we assume that features that creep are those that are added to a project despite the fact that their functionality is only tangential to the intended use of the project and that the creeping features are useful, not superfluous, the answer is to move them to separate, but related tools. Use the Unix philosophy of building orthogonal tools and gluing them together.
From a project management standpoint, the answer is comparable. Decide how much time you are willing to devote to the next release and set a deadline. Estimate the features and cut enough to make the deadline. If there are stakeholders involved other than yourself, make them choose what matters most to them.
A good overview on Scheduling can be found on Joel on Software:
http://www.joelonsoftware.com/articles/fog0000000245.html
1
One of the most important lessons in development is knowing when its time to stop.
What typically happens is a developer adds a features. That in turn inspires more ideas. So more features get added. That is, as you said, one of the ways a project becomes vaporware. The developer never sees the project as ‘finished’, so it never gets released.
The habit you want to get into is to stop thinking in terms of a release/version as a ‘finished’ project. Rather, look at development as a long-term process. Think of releases as milestones along the path to what you one day hope the program will be. Thus, a release/version is just a snapshot of where you are in the longer term process… a snapshot thats been well rounded out and tested.
What you can do, on the practical side, is sit down and spec out your next release. It doesn’t have to be terribly thorough. Write down the 3-5 new major pieces of functionality you believe are essential for the next release. (actual number of features may vary depending on the type of app, not counting bug fixes or minor gui changes) Work on those. If you come up with other ideas, thats fine… just make notes and implement them in the following release. When you get those 3-5 items done, your release is ready for beta.
When I start a new application, I typically think about the final ‘vision’ for the app. That, to me, is what I want in version 3 of the app. With that benchmark, I have an idea of what will make solid version 1 – just the basics.
Summary:
Each release does not have to be the finished ‘vision’ of the project. Just a milestone towards that vision.
0
Use a version control system in which it is cheap to create a branch for some idea, and keep it out of your release path. For instance in git, you can “creep up” some idea, and then git stash it away. Later you can review these stashes and cherry pick them in whatever order seems interesting.
For larger features, make a real branch (so you can do multiple commits). Case in point: when I wanted to add generational support to the garbage collector, I made a branch. Stashes capture the distracting little stuff very well. Big features can start as stashes, then turn into branches, and then finally merge when they are ready.
With stashes and branches, you can take stock of your ideas, prioritize them and establish a scope for the releases of your solo project, just like a managed team project.
Look, when you get an idea, it has to go somewhere, and the best somewhere is code: the repo. Creeping features is better than forgetting good ideas. But of course, if you creep all your features into the same mainline, it will keep delaying release, unless you cut untidy releases full of half-done stuff that users have to be warned not to use.