The ROI Variable



The ROI Variable

George Malamidis

EvERy dECiSion WE MAKE FoR ouR pRojECTS, be it technology-, process- or people-related, can be a viewed as a form of investment. Investments come associated with a cost, which may or may not be monetary, and carry trust that they will eventually pay off. Our employers choose to offer us salaries in the hope that this investment will positively affect the outcome of their venture. We decide to follow a specific development methodology in the hope that it will make the team more productive. We choose to spend a month redesigning the physical architecture of an application in the belief that it will be beneficial in the long run.
One of the ways of measuring the success of investments is by rate of return, also known as return on investment (ROI). For example, “we anticipate that by spending more time writing tests, we will have fewer bugs in our next pro- duction release.” The cost of the investment in this case is derived from the time spent writing tests. What we gain is the time saved from fixing bugs in the future, plus the satisfied customers experiencing better-behaved software. Let’s assume that currently 10 out of 40 working hours in a week are spent fixing bugs. We estimate that by devoting four hours a week to testing, we will reduce the amount of time spent on fixing bugs to two a week, effectively saving eight hours to invest in something else. The anticipated ROI is 200%, equal to the eight hours we save from bug fixing divided by the four hours we invest in testing.

Not everything need directly translate in monetary gains, but our invest- ments should result in added value. If, for our current project, time to market is essential to the stakeholders, maybe a bulletproof architecture requiring a lengthy upfront design phase will not offer ROI as interesting as a swift alpha release. By quickly going live, we’re able to adapt to audience reactions that can form the deciding element for the future direction and success of the project, whereas not thoroughly planning can incur the cost of not being able to scale the application easily enough when the need arises. The ROI of each option can be determined by examining its costs and projected profits, and can be used as a base for selection from available options.
Consider architectural decisions as investments and take into account the associated rate of return; it is a useful approach for finding out how pragmatic or appropriate every option on the table is.
George Malamidis is a software engineer working for TrafficBroker in London. Before that, he was a lead consultant and technical lead at ThoughtWorks. He has helped deliver critical applications in a variety of domains, from networking to banking to Web 2.0.