Archive for January, 2010

Too Much Choice aka Featurus Overwhelmitis

Wednesday, January 13th, 2010

After Christmas Blues

The wrapping is in the recycle bin and the tree is back in storage…if you use an environmentally fake tree instead of something that gets burned after you use it for a few weeks.

How much use did the kids make of all the toys they received?  A couple of things still amaze me, even after my son’s fifth Christmas:  firstly, the generosity of his grandparents and aunties; and secondly, how little play time some of the toys get.  One can speculate that the toy designers are at fault & this is likely one of the factors.  In my son’s case, I think much of what happens or does not happen with the various toys is due to ‘too much choice’.

Too Many Toys

The fact of the matter is that he is spoiled rotten.  Hard to avoid when you are the only grandkid for four grandparents & thus also the only nephew for two aunties!  The gifts end up being either being used a fair amount over a long term, being used when mommy or daddy participate/mildly coerce, or simply not getting used.  When something comes in a really big box, the playtime with the box usually rivals that earned by the toy it came in.

Enough about kids and gifts and Christmas, otherwise I’ll start in on rampant consumerism being the downfall of western civilization!

How Does this Apply to Software?

Why did I bring up ‘too much choice’?  Well, the features of your application can end up in the same three ‘buckets’ as the toys: used a fair amount over a long term, only being used when trainers or support staff walk a user through it, or simply not getting used.  The worst of the second two classes of functions will not only not be used, they will get in the way and detract from your users’ quality of experience.  This is to say nothing of the extra time wasted in documenting, training, and supporting those types of features.

Featurus Overwhelmitis Causes

How does one get so many features in an application to cause Featurus Overwhelmitis?  For an experienced development team the reason is usually due to the higher the quality the development team, the more seemingly great ideas will be generated.  As project manager, it is difficult to withstand the constant onslaught of ‘great ideas’.  This is especially true if they are coming from your subject matter experts and you as project manager lack the domain specific knowledge to be able to separate the necessary from the beneficial but not necessary.  For an inexperienced development team, there is simply the feeling that users will see great value in an application if it has bazillions of functions.

The DraftLogic Electrical Experience

In building DraftLogic Electrical, we have tried to minimize Featurus Overwhelmitis.  On the intake side, feature requests and suggestions are carefully analyzed to determine how truly necessary they are.  Usually we can prevent low value add features from making it into the development schedule.  Where possible, we have completely integrated features into the workflow so that the user is not aware of having done anything extra, they just get the results they need.  Our fault levels calculations are a good example of this–they run anytime that the panel schedules, single line diagram, or bill of materials is run & ensure that those reports always have the most current data used in their creation (all load, protection, and feeder routines run for these reports–the user only has to call for the report).

On the development side, control is a bit harder.  Good developers will always have ideas about to do something better, take something farther, or offer another flavor of a feature.  The worst offenders (albeit well meaning) will go ahead and make extra features without clearance from the project manager.  Ever received three functions when you asked for one, accompanied by the comment ‘It was only a little extra time to do this that and the other thing so here are some great extras!’

The Repercussions of Giving In

I have to admit to occasionally succumbing to such deliveries and implementing the extra functions into DraftLogic Electrical’s menus and tool palette.  One such example are the three circuiting quality assurance routines.  Looking at them now, I wish I had sent the extra functions back and asked for the originally scoped single qa function that did it all.  I wish this so much that now I am going to have to allocate time for someone to consolidate them into one so I can get rid of the others and thus increase our usability.

Beating Featurus Overwhelmitis

So, project managers, stay strong and resist Featurus Overwhelmitis.  You can keep your development team and subject matter experts happy by adding ALL feature requests to a database or list.  When it is time to scope a new build, go through the list–when presented with cold hard choices of where to expend limited resources for development action items, a good development team will pick only the real gems for action.

Until next time for more software engineering ramblings,
Dean Whitford, B.Comm

Chief Operating Officer

DraftLogic