Old Houses

Legacy software, in some ways, is like an old house. There are features that one might consider defects, errors or poorly implemented designs. A badly hung door. A sink in the wrong spot. Not enough outlets in a room. But the inhabitants adapt, cope and even harness utility out of the malfunction.

They implement patches, fixes, and add-ons to address the *issues*. But they never truly fix all of it. Instead they run more extension cords, tighten the hinges every month, or modify their behavior for washing, cooking or cleaning. They work with the old house, and the legacy software….accepting it as incomplete and adequate enough. A sort of perfection in imperfection.

Just as with software, houses have features that are too costly to fix, too embedded within the culture to remove, and too risky to replace. Is this acceptance of mediocrity or recognition of reality?

The plateau of legacy software is marked by this adaptation and acceptance of what is. There is no more striving for a better, greater product; there is just a kinship with the present. The power user rules this lifecycle. He or she knows the tricks, short cuts, bugs-but-also-features, and data rules of the product. They become one with the development team and a common bond forms.

Old software is the stock of the enterprise IT shop. Reliable, if only because we know how it doesn’t work. Dependable, if only because we know how and when it will fail. Usable, if only because we’ve learned to accept its flaws.

Advertisements

Software Feature Dilution

Introduction

Business analysts, requirements managers, and project managers will find the greatest interest in this article.

Software Product Planning

It occurred to me last week during one of our weekly iteration planning sessions that one of the most esoteric methods around product planning is deciding which requirements to turn into software features.  The more rigorous approaches look at the cost of the feature, the potential impact to ROI ( assuming there is one ), and the demand.

What’s wrong with this approach is that it considers the features and resulting requirements in isolation from one another.  By not considering how each new feature affects the existing product as a whole teams can and do end up with products in which the original feature set, that made the software successful, become diluted.  Those of you who’ve worked with me know my favorite example is CA’s Remedy product, but I think one could find other examples: the Microsoft Office suite of products may be in this camp.

Feature Dilution:  A Formula

So how would one go about constructing a measurement for feature dilution?  First – some assumptions:

  • You know or can retrieve the cost associated with the original marketable software release.
  • You know or can calculate the benefit ( ROI ) for the original marketable software release.
  • You have an estimated cost and benefit associated with any potential new software features.

Ok, so knowing these let’s construct a model for software feature dilution.  We’ll adapt a formula from the world of finance.

V – Value of sofware after Feature dilution =

((O x OP) +(N x (∑ IP1, IP2….IPn))) / (O + N)

where…….

O = original number of features

OP = Current NPV of product ( could use ROI too )

N = number of new features to be added

IP1, IP2, IPn = NPV of each new feature.

If you run this formula through some examples in time what you’ll find is that as a product matures new features need to continually generate greater returns to justify value to the original product and ultimately diluting the existing feature set.

This is exactly what should happen if we want to avoid the fate of an overly complex and unmanageable software product.  Just like stock market share dilution the product management team needs to justify that further feature dilution will grow the value of the product in terms of existing functionality…..not just that it will add to revenue.

Summary

Simplicity in software design has always been something great software architects knew yielded great products.  With this formula I hope I have provided at least a start to measuring simplicity in software.