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.