Opportunity Costs In Software Development

I borrowed the term opportunity costs from economics. Opportunity costs occur whenever there is a tradeoff between two options. For example, either one of two things can be done, A or B. If you decide for A, then the benefits of B cannot be realized. These lost benefits of B are the opportunity costs of choosing A.

Such decisions have to be made constantly in the development process. Let’s imagine that we have a data science problem to solve. Should we use Python or Java as a programming language? With Python, our developers would be five times faster for this particular problem, but we do not have Python programmers in the team. Do we hire some? Train the existing staff? Offer training on the job? Or do we go for Java after all, despite the downsides?

Another example: Should we use a software library or write the code ourselves? A software library brings a lot of functionality, but we must learn how to use it and adapt our code to it. Writing the code ourselves harbors the risk that more requirements might come in later and, in the end, we would have recreated the complete library.

There are tons of these decisions in every project – and there’s more.

Opportunity costs of communication

I am sure everybody has noticed that when a software project starts, a first working prototype is built in days or weeks, yet the complete product takes months or even years. This is due to the additional requirements in an enterprise-grade tool, summarized in the Pareto principle: It takes 80 percent of the costs to implement the last 20 percent of the product.

But there is another effect in motion: The costs of communication. A programmer can code for eight hours a day. Ideally, they must remain focused for that time. But what does a normal day really look like? A half-hour Scrum meeting at 9am. After, the developer has scarcely enough time to start thinking about the problem at hand before being interrupted at 10am by a meeting about an architecture detail that will impact everybody. From 11am onward, they start thinking about the problem again, write a few lines of code – at 12pm, it’s lunch time. Day in and day out the entire development process is interrupted, and eight-hour days are essentially reduced to one to two hours of actual work. Communication does have huge opportunity costs.

Yet, no communication at all also creates opportunity costs. We all have seen projects fail where each individual member made good progress, but at the end no product came out of it. I was really shocked about what kind of development speed I was able to achieve in my own company compared to when I was an employee. A factor of about five times faster.

Risks are opportunity costs

Another mistake I often see is forgetting to evaluate the inherent risks of choosing option A or B. Using my above example of Python versus Java, training the team to use Python involves risks. After the training, the developers will be junior developers for Python, regardless of their experience in Java. The risk of creating sub-optimal code is huge, plus the development speed will be lower. Both are due to the lack of experience in Python.

Will the developers love Python and be highly motivated? Nobody knows in advance. Did we falsely assume the product can be built in Python more efficiently, simply because there had been no prior experience with Python and the downsides it has in other areas? Hard to tell. If we choose Java, the risk is low. We know what lies ahead of us, we are certain about the development time it will take. Is the risk of choosing Python worth it?

When making such decisions, the list of pros and cons should always have a probability attached to it. How long does it take to build in Python? One week. In Java? Two months. How certain is the team this statement is true? 50 percent.

Decisions

What happens quite often in projects is that the team reaches no fact-based decision. If the advantages and disadvantages of choosing A or B were indisputable, the question would not even come up. The problems of picking one option lie either in different estimations of costs, risks, and side effects or in long-term versus short-term impact.

We must resolve that somehow. Listing the pros and cons for both options takes a day, usually accomplishing nothing of substance. So, we try diving in one level deeper to figure out why people have different point of views. Maybe lack of knowledge on one side or the other? Different assumptions or understandings? Another five days spent dealing with those questions. As this seems to be a fifty/fifty decision, maybe adding product management’s thoughts about the long-term perspective will bring the team towards a decision? This only serves to involve more people that have to be aligned in the end, which makes reaching a decision even harder. In this case, the smarter move would be to make an arbitrary decision and just start working instead of agonizing over the decision and accomplishing nothing. Just imagine: A lion is chasing us, should we take the left or right path? Someone says, “Follow me, we’ll take the left one!” Would you really question the decision and wait around to be eaten? Realizing the potential this approach has takes guts on the development manager’s side.

Unfortunately, no matter what you choose, people will find something to criticize. If you go with Python in the above example, after the project is finished, some people will inevitably say that they were right all along: With Python, it was harder to implement enterprise-grade software, the code was rewritten multiple times because of lack of experience, and with Java, none of that would have happened. Had the decision been Java instead, other people would have pointed out that the same code could have been written in Python within days instead of weeks due to the powerful data science libraries.

There is no definitive proof if the decision you didn’t make truly would have been the better one. That is why assigning a probability factor to statements often helps.

Solution

What is the solution to all the problems I laid out? Drum roll, please: There is none. Every project is different. People are different.

Scrum (agile development), if used properly, is a wonderful tool for software development. The rest is leading the team by example and being aware of the pitfalls. Most important, however, is a small team size for each individual component that has to be built.