The first thing of course, is to spend as much time as possible on testing your stuff before its released, so that it doesn't have too many bugs in at that stage. Of course there will be some, but hopefully none that require a rushed out patch when discovered.
Next, most software projects are ongoing, they mostly don't just have single release date and then that's it. So after the first release, you have two areas of work, bugfixes and new features. Then it's simply a matter of making sure all these are clearly prioritised by the marketing bods, so you know which ones to do first. Provided you can prevent your PHB from bumping everything up to priority 1 that is. A good issue tracking system is useful here.
I've found this works really well in an iterative/incremental approach. One project I was on, we had increments of 1 month. At the start of each, we looked in the tracking system, looked at the top priority issues, estimated how many of these we could do in the next month, and that's what we did, whether they were bug-fixes or new features. We'd also usually do a bit of refactoring while we were at it, both to help integrate the new stuff, and to tidy up the old stuff.
For assigning priorities, bug-fixes usually came in low, unless they were real howlers or specifically requested by a key customer. This is of course driven from a revenue point of view. You want to work on stuff that generates the most money:
New features => new customers => lots of revenue from new orders.
Bug-fixes => keeps old customers happy => some revenue from upgrades or expanded orders. I think this is the way most companies work, even if it's not actually the most convenient way for existing companies.
Also I would say its probably counterproductive to assign developers to both maintain old projects and work on new ones. Especially if the old ones have unpredictable resource requirements, e.g. you have to be available immediately a bug report comes in. This can really hammer the planning on your new project! Also it may be harder for a developer to maintain two development environments, especially if they're largely different, e.g. compiler versions, different tools etc. It's better just to gradually reduce the workforce on the old project until eventually it gets dropped. This way also means that all developers work on both new features and on bugfixing, so nobody gets bored etc.
So, as you can guess, mostly I've only ever been working on one project, with both bug-fixing and new features in the mix, and I'd say it works well for me.
Slashdot Mirror
The first thing of course, is to spend as much time as possible on testing your stuff before its released, so that it doesn't have too many bugs in at that stage. Of course there will be some, but hopefully none that require a rushed out patch when discovered. Next, most software projects are ongoing, they mostly don't just have single release date and then that's it. So after the first release, you have two areas of work, bugfixes and new features. Then it's simply a matter of making sure all these are clearly prioritised by the marketing bods, so you know which ones to do first. Provided you can prevent your PHB from bumping everything up to priority 1 that is. A good issue tracking system is useful here. I've found this works really well in an iterative/incremental approach. One project I was on, we had increments of 1 month. At the start of each, we looked in the tracking system, looked at the top priority issues, estimated how many of these we could do in the next month, and that's what we did, whether they were bug-fixes or new features. We'd also usually do a bit of refactoring while we were at it, both to help integrate the new stuff, and to tidy up the old stuff. For assigning priorities, bug-fixes usually came in low, unless they were real howlers or specifically requested by a key customer. This is of course driven from a revenue point of view. You want to work on stuff that generates the most money: New features => new customers => lots of revenue from new orders. Bug-fixes => keeps old customers happy => some revenue from upgrades or expanded orders. I think this is the way most companies work, even if it's not actually the most convenient way for existing companies. Also I would say its probably counterproductive to assign developers to both maintain old projects and work on new ones. Especially if the old ones have unpredictable resource requirements, e.g. you have to be available immediately a bug report comes in. This can really hammer the planning on your new project! Also it may be harder for a developer to maintain two development environments, especially if they're largely different, e.g. compiler versions, different tools etc. It's better just to gradually reduce the workforce on the old project until eventually it gets dropped. This way also means that all developers work on both new features and on bugfixing, so nobody gets bored etc. So, as you can guess, mostly I've only ever been working on one project, with both bug-fixing and new features in the mix, and I'd say it works well for me.
Must be an 'aftershock' from the slashdot earthquake!