Managing Programming for CEOs Part 3 – Features Kill

Everyone knows about the “killer features” which propel software products or websites to stardom.  Much more common are the unneeded features which destroy schedules and kill development projects. Evslin’s Law #1 is that the time required to complete software is proportional to the square of the number of features.  Law #2 is that schedule predictability decreases in proportion to the square of the length of the project.  Quite literally, a project with too many features will never be completed.

To get software projects done with a modicum of predictability, make three lists:

• Priority One are those features without which the product couldn’t possibly ship – printing for a word processor is a good example.

• Priority Two are highly desirable features.

• Priority Three are nice-to-haves.

At the end of the list-making you will have four lists because Priority Zero will have risen spontaneously and been populated.

Throw away the Priority Three list.  Be sure to empty the trash after throwing it away; you don’t want it to resurface.  Save the Priority Two list for the next version.  Now make a schedule for the Priority Zero and One features.  This schedule won’t be achieved either but you can manage to it.

On many projects the done date is the most important feature.  It may be the only feature specified by the CEO.  If the completion date is the most important feature to you, you have to act that way which means being willing to sacrifice every other feature that gets in the way of getting done.  Cutting features is usually the only way to rescue a development schedule which has fallen behind.

If you are managing version 1.0 of something, it is particularly important to hold the line on features and get the software out to your users fast.  Why?  Because you don’t know what features are important until you get user feedback.  The bell or whistle you thought was so cool that it would be blow users away will end up never getting used.  Something nobody ever thought of will turn out to essential and you won’t find that out until real users – not beta testers – have the product.  Then you can hustle and get that real must-have into version 1.1 before your competitors know what’s happening.

Remember I said that you should save the Priority Two list for the next version.  The purpose of that is mainly to show you how wrong you and your team were about what is important.  When you make the priority lists for the next version, Zero and One will be populated by those things your users, tech support, and marketing people discovered AFTER version 1.0 shipped.  Stuff that was on the Priority Two list for version 1.0 will end up on the Priority Two list for the next version as well.  Priority Three features, of course, will be long forgotten.

The law that says the length of a project increases with the square of the number of features has a scientific basis.  Each feature has the potential for interacting with every other feature. Good programming techniques minimize the interdependency at the code level but it is still there.  So the number of potential interactions is proportional to the square of the number of features.  The number of scenarios that should be tested (note that I said “should” and not “are”) also goes up proportionally with the square of the number of features.  Each feature that breaks during testing has to fixed creating a very real danger that something else will get broken in the process of the fix.

Microsoft’s success is, in large measure, a testimony to Bill Gates’ skill in managing development projects.  Even Bill, however, had a feature-related fault, at least when I was at Microsoft.  Bill did not like to hear about the ship date of products slipping.  However, no sane manager would hide a slippage from Bill so there were some very tense meetings.  Sometimes Bill’s wrath could be allayed by agreeing to add features that he thought the product should have had anyway or that he could be convinced were cool.  The ostensible logic was that, given slippage in some critical path component, the other teams would have extra time to add more features. Wrong! Inevitably, more features meant more delay.

Part 1 of this series is a phrase book of programmer-speak.

Part 2 is the meaning of “done” and how to know when you’ll get there.

Part 4 is about great debuggers.

I’ve also blogged on how programmers can manage CEOs.

Part 1 is on managing non-technical CEOs.

Part 2 is on the even harder job of managing technical CEOs.