- 20% of the features are responsible for 80% of the headaches of software development, and;
- 20% of the features are responsible for 80% of the value of the software to its users.
Are those the same 20% of the features on your project? If not, why not?
I cannot decide if that is a rhetorical question or not, so here’s my answer:
At the beginning of a project, the two are unrelated. What happens to them during the project largely determines its success.
A good team quickly notices which features cause more headaches. They will ask if the expected value of these features is great enough to justify the pain. If not, they throw those features away. The longer the project lasts, the more aligned the values of the features are to the pain they cause.
There are at least two ways to fail in this. First, the team may not notice early enough that a feature is painful. When they do notice, the pain of an alternate path may have grown beyond the expected pain of finishing and maintaining the feature.
Secondly, the team may be unable or unwilling to choose an alternate path. They have a contract or a boss or a mindset that tells them to finish the software the way it was originally planned.
Unfortunately, in most projects I have participated in, there has been little overlap between the painful and the useful features. I believe the same holds true for the industry in general.
A word of warning. If you think this is an argument for agile development, think again. If you think this is an argument for waterfall development, think again, too.