Complexity is a multiplier

If there were one sort of interaction I wish I could take back from all my time as a software consultant, it would be every time I nodded my head at a client when they asked me to add one more feature, knowing full well that its addition would be costly and that the client should place their assumptions about its benefit under more scrutiny.

Considering my title of Digital Product Consultant, you'd think I was up to the task. But a point I think deserves being driven home is how we consultants are paid to increase revenue and decrease cost, even though sometimes we act as though we're paid to follow directions.

The fact is, someone who pays money for custom software isn't necessarily going to be aware of the ongoing costs of maintaining a specific software feature. And these costs, depending on the architecture of a given system and its dependencies, can balloon exponentially. That's because added complexity to a software product multiplies cost.

When your application has a single button that, when pressed, shows a predetermined text string on-screen, you've built a simple program. When you make the button show a bit of randomly selected text from a list when pressed, you've built a slightly more complex program.

With each new feature we add to a software program, the resulting complexity increases. It's easy to assume the increase in complexity (and therefore, the inversely correlated decrease in ease of understanding) is a linear progression. But each feature actually increases complexity exponentially.

This means that for each new feature, it's likely you're going to multiply—not add to—the overall cost of maintaining your software.

Therefore, it's prudent to consider the long-term ramifications of implementing a feature. The real cost center is not in its implementation, but in its continued support. How does the new feature play with existing ones? What happens if we later want to remove it? How will our users react?

What are some ways consultants can help their clients better understand the ramifications new features could have on their ongoing maintenance costs? And what are some ways you can protect yourself if you've hired a consultant but are unsure whether you next feature request will balloon into a Great Expensive Ball of Doom?

Is it additive or foundational?

Does the new feature sit beside or on top of other features in a way that doesn't stand to negatively impact other parts of the application? Is the feature orthogonal, meaning it neither creates nor propagates side effects to other parts of your application? If so, the chances are lower that implementing and shipping the feature will result in regressions or service outages. This is what I call an additive feature.

But if your feature involves widespread changes to fundamental components of your application that are in production, mission-critical, and costly should they malfunction, then you're implementing a fundamental feature. In this case, you ought to spend more time analyizing the costs and benefits of building it.

Performing a cost benefit analysis

If you've identified that your new feature will likely have an impact on existing mission-critical infrastructure, you'll want to do a bit of analysis before you give the thumbs-up to have it built.

List the potential externalities that could arise when shipping the new feature. Could it disrupt orders from being processed? Is there a chance that users won't be able to sign in for a brief period of maintenance time? Will you need to perform an intensive migration on your database that could cause downtime and/or integrity concerns?

List each of these and attempt to quantify the best and worst case scenario you can imagine, in terms of the costs to the business.

For instance, if you think there's a chance you could see some downtime to your sales pipeline for 10 minutes up to 1 hour, and on a typical day you see $24,000 in sales, you stand to lose up to $1,000 in sales as a result of implementing the feature. You'll also want to account for the opportunity cost associated with the hours (or days) your team spends resolving the regression.

In addition to the lost dollar value, you should also consider intangible costs like costs to your brand's value, customer perception, and team morale. While these costs are not necessarily measurable, they have a profound effect on your business over time.

When you spend the extra time coming to terms with the potential externalities of implementing a new feature, you'll increase the reliability of your product and reduce stress resulting from outages. While new features stand to make your product more valuable and stand out among your competition, carefully considering how they will affect your existing featureset can save you time, money, and headaches.