Opportunity costs in software development


Recently I was asked to give a talk at the local university on the challenges of software development. After thinking long and hard about what the central theme should be, I distilled everything into one point.

I borrowed the term opportunity costs from economics. Opportunity costs arise whenever there is a trade-off between two options. For example, one of two things can be done, A or B. If you decide for A, then B’s advantages 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. Say we have a data science problem to solve. Should we use Python or Java as the programming language? With Python, our developers would be five times faster for this particular problem, but we don’t have Python programmers on the team. Are we hiring? Train existing staff? Provide on-the-job training? Or do we go for Java after all, despite the drawbacks?

Another example: should we use a software library or write the code ourselves? A software library brings a lot of functionality, but we have to learn how to use it and adapt our code to it. Writing the code ourselves carries the risk that other requirements will come in later, and in the end we would have recreated the entire library.

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

Communication opportunity costs

I’m sure everyone has noticed that when a software project kicks off, a first working prototype is built in days or weeks, while the full product takes months or even years. This is due to the additional requirements of an enterprise level tool, summarized in the Pareto principle: 80% of the costs are needed to implement the last 20% of the product.

But there is another moving effect: communication costs. A programmer can code eight hours a day. Ideally, they should stay focused during this time. But what does a normal day really look like? A half-hour Scrum meeting at 9 a.m. Afterwards, the developer barely has time to start thinking about the problem posed before being interrupted at 10 am by a meeting on an architectural detail that will impact everyone. From 11 a.m. they start thinking about the problem again, write a few lines of code – at 12 p.m. it’s lunchtime. Day after day, the whole development process is interrupted and the eight-hour days are essentially reduced to one to two hours of actual work. Communication has huge opportunity costs.

Yet lack of communication also creates opportunity costs. We’ve all seen projects fail where each individual member has made good progress, but in the end no product has come of it. I was really shocked at the kind of speed of development I was able to achieve in my own business compared to when I was employed. About five times faster.

Risks are opportunity costs

Another mistake I often see is forgetting to assess the risks inherent in choosing option A or B. Using my example above of Python versus Java, train the team to use Python has risks. After the training, developers will be junior developers for Python, regardless of their experience in Java. The risk of creating suboptimal code is enormous, and the development speed will be slower. Both are due to the lack of experience in Python.

Will developers love Python and be highly motivated? No one knows in advance. Have we mistakenly assumed that the product can be built in Python more efficiently, simply because there has been no prior experience with Python and its drawbacks in other areas? Hard to say. If we choose Java, the risk is low. We know what awaits us, we are sure how much 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 be associated with a probability. How long does it take to build in Python? One week. In Java? Two months. How confident is the team that this statement is true? 50 percent.

The decisions

What happens quite often in projects is that the team doesn’t make any decisions based on facts. If the pros and cons of choosing A or B were indisputable, the question would not even arise. The problems with choosing an option lie either in different estimates of costs, risks and side effects, or in long-term versus short-term impact.

We have to resolve this one way or another. Listing the pros and cons of both options takes a day and usually accomplishes nothing substantial. So we’re trying to dive to a deeper level to understand why people have different points of view. Maybe a lack of knowledge on one side or the other? Different hypotheses or understandings? Five more days spent dealing with these issues. As this seems like a fifty / fifty decision, maybe adding the product management’s thoughts on the long-term perspective will bring the team towards a decision? This only serves to involve more people who need to be aligned at the end of the day, which makes decision making even more difficult. In this case, the smartest decision would be to make an arbitrary decision and just start working instead of agonizing over the decision and not accomplishing anything. Imagine: a lion is chasing us, should we take the left or right path? Someone says, “Follow me, we’ll take the one on the left!” Are you sure you want to question the decision and wait to be eaten? Realizing the potential of this approach requires courage from the development manager.

Unfortunately, no matter what you choose, people will find something to criticize. If you are using Python in the example above, once the project is complete, some people will inevitably say that they were right from the start: with Python it was more difficult to implement enterprise level software, the code has been rewritten several times due to lack of experience, and with Java none of this would have happened. If the decision had been Java instead, other people would have pointed out that the same code could have been written in Python in days instead of weeks due to the powerful data science libraries.

There is no definitive proof whether the decision you didn’t make really would have been the best. Therefore, assigning a probability factor to statements is often useful.


What is the solution to all the problems I have posed? Drum roll, please: there is none. Every project is different. People are different.

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


Sam D. Gomez