The Iron Law of Software Development
There are three important concepts used in managing a software project. These are the time it takes to complete (Time), the various things the finished software will do (Features), and how well the finished product works (Quality).
I call this the Iron Law of Software Development. The reason I use the word Iron is that you may have, at most, two of the three attributes.
Two. That's it.
You may choose Quality and Time. This is a fair choice, but one that is almost never chosen. When you choose Quality and Time you are saying that you want the product to work well and you want to met the original ship date. Since software always takes longer than management thinks this means you will not finish all the 'mandated' features. This is why it is never chosen.
You may choose Quality and Features. This is an awesome choice. Also never chosen. Management always wants to finish the work on the original schedule. This is always impossible. Quality and Features always take more time.
You may choose Time and Features. Well, no one makes this choice out loud. Nobody wants to say they are sacrificing quality out loud. This is what happens. Pretty much every time. Getting all the features done in the original time estimate always means quality suffers.
I said you could have at most two. That is the maximum. I've seen one (always Time or Features, never Quality). And I've seen zero. Sometimes that means the company goes under or gets sold at a fire sale (three times in my career).
The sensible approach is a series of releases, each of which has a set time to complete with as many features as can be done with good quality. As you near the release date you chop off any new features that won't make the release with acceptable quality. All such missed features are candidates for the next release. In thirty years of software development I've never seen this done.
There are very good reasons why most software development projects fail.
I call this the Iron Law of Software Development. The reason I use the word Iron is that you may have, at most, two of the three attributes.
Two. That's it.
You may choose Quality and Time. This is a fair choice, but one that is almost never chosen. When you choose Quality and Time you are saying that you want the product to work well and you want to met the original ship date. Since software always takes longer than management thinks this means you will not finish all the 'mandated' features. This is why it is never chosen.
You may choose Quality and Features. This is an awesome choice. Also never chosen. Management always wants to finish the work on the original schedule. This is always impossible. Quality and Features always take more time.
You may choose Time and Features. Well, no one makes this choice out loud. Nobody wants to say they are sacrificing quality out loud. This is what happens. Pretty much every time. Getting all the features done in the original time estimate always means quality suffers.
I said you could have at most two. That is the maximum. I've seen one (always Time or Features, never Quality). And I've seen zero. Sometimes that means the company goes under or gets sold at a fire sale (three times in my career).
The sensible approach is a series of releases, each of which has a set time to complete with as many features as can be done with good quality. As you near the release date you chop off any new features that won't make the release with acceptable quality. All such missed features are candidates for the next release. In thirty years of software development I've never seen this done.
There are very good reasons why most software development projects fail.
Comments
Post a Comment