Return-On-Investment

<< Previous - TTM | Table of Contents | Next >> - Sellability

If the costs to produce a feature outweigh what can be reclaimed, is that a good value for money? Would your investors commend you for a sterling job? Return-On-Investment (ROI) relates to the amount of profit (over its lifetime) received from a feature. The greater the return, the more attractive the proposition.

ON PROFIT

Profit is the difference between a feature’s production and delivery costs, and the monetary return from its sale. ROI is a measure of the value investors receive from a feature.

SOFTWARE COSTS

Development costs are only one aspect of the overall costs of building software. There’s also business analysis, design (back-end, and UI), scoping, testing (functional and non-functional), deployment, delivery, and documentation costs. All of these activities add value to the overall product, but — if not correctly managed, and overdone (Overprocessing) — may also reduce ROI.

Now, before you run off and strip out all design activities from your projects (please don’t), note that it’s rarely that simple. Although some of the activities may reduce ROI if overdone, they’re often there for good reason, such as preventing the wrong thing from being built (i.e. Risk Reduction), or protecting Brand Reputation by demonstrating high quality.

Anyone who’s been in software industry for a decade or so, has probably witnessed the monolithic release process (where a heroic, but fruitless, effort is made to deliver software each month/quarter). If every release is onerous, unrepeatable, and regularly fails, then the cost of ownership is high (i.e. reduced ROI), regardless of the quality of the underlying software being distributed. And it’s not necessarily the software product at fault (although some application architectures are particularly prone to causing distribution issues), but how it’s distributed. Additionally, it’s very demoralising to work a sixteen hour day to deliver a release that no-one actually wants, or uses (Arbitrary Dates).

Like most things in life, finding an appropriate ROI is also about finding the right balance.

ALWAYS THE CHEAPEST

Beware of Short-Term Glory; i.e. always choosing the cheapest route to delivery. It rarely sits well with a longer-term business strategy and goals, and typically causes Technical Debt.

TIMING & ENTROPY

When a product is delivered also plays a role in ROI. Late deliveries, or features stuck in the manufacturing system (Manufacturing Purgatory) for unnecessarily long, all eat into potential returns (particularly if payment occurs post-delivery).

Additionally, software degrades (Entropy), as does an appetite for it. The longer it sits unused, awaiting delivery, the less valuable it is, and the greater risk it isn’t required by the time it is delivered.

FUNDING SOURCES

Investment can come on multiple forms. Some governments (e.g. the Scottish) are particularly forward-thinking, incentivising businesses to innovate by offering Tax Credits. If a business meets the criteria, a sizeable return can be claimed on any initial investment. This is a great way to increase ROI — not only are you innovating, you’re getting money back for doing so. [1]

TECHNICAL QUALITIES AFFECTED

The figure below shows some of the technical qualities affected by (or affecting) ROI.

ROI Technical Qualities

They are:

RELEASABILITY

The ability to deliver value to the customer, efficiently and regularly, has (I argue) a strong influence on ROI. When I look back at all my previous roles, it astounds me at the number of times I’ve witnessed Work-In-Progress (WIP) & Inventory clogging up the manufacturing system, costing significant investment to build, yet never finished (they all felt like they were 80% done). Consider all those dollars burned, delivering nothing. In the above case, the problem stemmed from a mixture of poor delivery mechanisms, and a very reactive business (Continual Reaction). The poor delivery mechanisms extended the lead time in the manufacturing system, whilst the business’ reactive nature heightened the likelihood of Feature Expediting; thus increasing inventory, and (theoretically) reducing cash-flow.

ROI may also be affected by the manner of delivery (Delivery Methodology). To illustrate the point, consider the Agile v Waterfall methodologies. At completion of a waterfall project, often what’s delivered is not a product the customer wants. The solution must either be reworked (one of The Seven Wastes), or discarded (often leading to legal ramifications; e.g. each party sues and counter-sues the other for breach of contract). This is poor ROI, and terribly risky.

RETURN ON WATERFALL

I’ve witnessed the inherent risk of Waterfall several times, the last being in a major project I was involved in.

The business spent months creating — what ended up being — a highly bespoke solution, to the detriment of all other work. Additionally, we were severely hampered by a number of problems including: poor delivery practices, inefficient architecture, Misalignment, and Insufficient Detail. The customer eventually cancelled the project, placing unnecessary burden on the business, and leaving us with a whole host of technical debt.

Waterfall often comes with a cost implication; i.e. initial payment is deferred until project completion, which could be months or years with no ROI.

Generally, Agile and Continuous practices align better with ROI. With each delivered feature we (should) receive payment; unless it’s undesirable, and then we’ve only wasted a few weeks of effort on it.

MAINTAINABILITY

If 40–80% of time on software is spent in maintenance mode, we must ensure a high degree of efficiency. [2] This might (for instance) take the form of clean code and design, high cohesion and loose decoupling, encapsulation, quality documentation/comments, and standardising code/APIs. Uniformity — described later —  is also an important quality associated with Maintainability.

FLEXIBILITY & EXTENSIBILITY

We may achieve good ROI by supporting flexible and/or extensible mechanisms in appropriate areas of a system/architecture (however, overusing this approach across an entire system is one of The Seven Wastes). If done correctly, these mechanisms promote a high level of change, offering ways to tailor a system to specific customer requirements (also aiding Sellability). I’ve witnessed the Pipes & Filters architecture used here to great effect.

TESTABILITY

Testability ensures quality, particularly as a regression tool. Testable software may have a larger up-front (initial) cost; however, those costs are quickly overcome with every subsequent change to the software (40%-80% Maintenance Mode). Thus quality, automated tests, with a high degree of coverage, support fast turnaround and nimble businesses.

Testability also has less obvious — but equally important — benefits. It promotes stakeholder confidence in our ability to change, which consequently, promotes more efficient working practices and innovation. A team with the Safety Net of automated tests can be more radical; i.e. bet bigger, and attempt things they wouldn’t dare to do otherwise. This, naturally, leads to more experimentation, learning, and improvement, and thus to improved overall ROI.

EVOLVABILITY

Evolvability relates to our ability to easily evolve areas of a system (or business) to improve. This might take the form of introducing a better design, technology, practice (e.g. Agile), or even a culture.

To illustrate Evolvability’s importance, consider this anecdote. I once worked with a monolithic application that suffered from poor evolvability (mainly due to Domain Pollution). We needed to evolve it to support the business’ aspirations (it didn’t scale, the technology was antiquated, it hampered our productivity etc). Yet, effort and risk (Change Friction) prevented its evolution; so... we built a new system (at a high cost). If the existing system had better supported evolvability, it may have survived longer, or sold better, and thus generated greater ROI to our investors.

Procrastinating on technology upgrades (Upgrade Procrastination) also leads to real evolution challenges and potentially a product’s early demise. The same monolith I described earlier technology upgrades were also neglected, to the point that eventually caused Big Bang Change Friction, and early demise.

PORTABILITY

Portability relates to the ability to easily port a system into other platforms/providers. This may seem irrelevant in some business models (e.g. Software-As-A-Service (SAAS)), but I’ve experienced some business strategies requiring it.

Portability is a double-edged sword. For instance, Cloud-Agnosticism may introduce additional complexity (e.g. supporting different database technologies, different distribution models, or wrapping specific vendor-selection decisions). Yet, it may also be a great sales enabler for those customers who have preferred/mandatory vendors (e.g. Vendor Bias). So whilst Portability may reduce ROI, it may improve Sellability.

REUSE

Reuse is an obvious contender for the ROI crown. If you can reuse the same solution repeatedly in different contexts, you potentially attain a significant ROI. However, be aware of the type of Reuse you’re selecting (beware of Inappropriate Reuse). For instance, whilst a Monolith of Monoliths is a common form of reuse, it’s extremely problematic over the longer term, causing scaling, productivity, reliability, and security problems — all reducing ROI.

PRODUCTIVITY

Another incredibly important technical quality (supporting ROI) is Productivity; our ability to efficiently deliver value. It’s closely related to Maintainability (the ease with which we can change existing code), and Releasability. However, it also relates (for instance) to:

SCALABILITY

Although it’s typically ranked lower on the ROI spectrum, Scalability and ROI are still related. I’ve experienced first-hand how poorly scaling systems can negatively affect ROI; parts scaled so poorly that it eventually forced the business to discard the product and replace it with a new one —  surely an ultimate form of waste, and poor ROI.

COSTS

Yes, I see you shaking your head at me! Why has it taken me so long to reach Costs?... Well, I’m mainly describing operational costs here (not Productivity, or Releasability, which all ultimately comes back to costs).

However, it’s worth noting that there are a number of costs that don’t directly relate to the cost of production; for instance, licensing costs, tooling costs, providing evidence that the product meets industry standards (e.g. ISO). Depending upon the industry, and product type, some are out-with of your control —  they’re expected Table Stakes, but still need considered.

UNIFORMITY

I’ve brushed upon Uniformity in the TTM section. Uniformity — the act of making appropriate things look or act the same — is a great way to support ROI. If things look the same, and (generally) behave the same, it’s a Known Quantity. And known quantities exhibit some important characteristics: (a) they are quick to understand (Low Representational Gap), and (b) have few surprises. This suggests efficiency. I used this approach religiously for microservices and deployment pipelines.

INTEGRABILITY

I touched upon this subject in the TTM chapter so I won’t repeat it all again here. Suffice it to say that poor integration practices can lead to additional support work (Unplanned Work), and thus costs.

CHAPTER SUMMARY

The key points of ROI are: