There are four major forces at play in the development of any software solution: budget, time, quality, and scope. While all four limits are typically expected to be fixed, often the reality is that eventually one of them has to give for the others to be met. When developing free software, think of the budget as your energy. Instead of the traditional time and money expenses, you’re spending time and energy on your project. Time and budget are usually directly related to each other, and are fixed. In our case, if our development drags on for too long without results, our enthusiasm for it will eventually run dry. Clearly we do not want to compromise quality, so we’re left with only one variable force: scope.
In chapter 3, I pointed out that projects fail when they do not deliver on what they promise, and that it is better to do simple well, than complex badly. The same theory applies here. Adjusting the scope of your product between releases allows you to deliver quality pieces of software that are on time, and on budget. Again, as I pointed out earlier, people will hardly have much to complain about if you’re honest with your claims, and deliver on them accordingly.
If quality is fixed at maximum, and budget is linked to time, what is a good time limit to set ourselves? Well, the answer to that question is the answer every client wants to hear: as soon as possible. Instead of seeing a deadline as a point in time where all features must be completed, we should look at it as the time period in which we have to get as many features done as possible. By first releasing a functional product with the absolute minimum requirements implemented, your software can be ready for testing and feedback at a very early stage, and can serve as a solid foundation for every new feature you add. Unlike other fields of engineering, we have the convenience of being able to release product updates to every one of our clients with the simple click of a button. We should appreciate how powerful this benefit is, and use it to our advantage.
Taking all of the above into account, have another look at your product wish list, and try identify which item(s) absolutely must be implemented for your project to be usable. Don’t sweat the small stuff here, you should aim for just one or two baseline features that will take your product from nothing to something. Now start rearranging the list in order of priority from top to bottom. The top being your minimum requirements, followed by items of decreasing importance as you approach the bottom. If you have trouble deciding the order of some equally important features, I suggest arranging them in the order of how much research will be required from lowest to highest. This will allow you to build up some momentum on the more familiar tasks before hitting the more difficult ones.
That’s it, your release schedule is ready. As you complete each item on your product wish list from top to bottom, you should be able to release a new, fully-functional version of your software. Incrementally releasing your hard work is an excellent way to keep your enthusiasm up, as well as to allow you the opportunity to move on to another project when you feel you’ve learnt enough.