Everything Has A Cost

September 9, 2017

In our lives and business, we have finite resources. These resources can be natural such as wood, coal, or oil. They can be less material such as time and money. They can even be quite abstract like focus, inspiration, and motivation. Because they are not infinite, these resources need to be consumed wisely. All too often, we lose sight of this fact when writing software and designing systems.

As the stewards of software, we make lots of decisions that have potentially large impacts on the businesses we work for. We choose the languages to write the code in and the databases to store company assets in. We decide how much of the cloud to utilize and how much we should host ourselves. And on and on. All of these choices have a variety of costs and benefits that come with them. There are a number of questions that need to be answered to understand the total impact of a choice. Let’s look at choosing between a new technology or an existing one for a new feature. Perhaps you’re trying to determine where to store some new data. Should you use a relational database like MySQL or PostGres? Or maybe a metrics database like Druid or Influx? The pros (benefits) and cons (costs) need to be understood to make the right decision. Here are the questions you should be asking and answering.

Cost Questions

These are the questions often overlooked or underestimated. They should be taken seriously because they are real costs.

  1. How much time will it take to deploy the new technology to the staging and production environments?
  2. How much time will every developer have to invest to learn how to use and work with the new technology?
  3. How much time will every developer have to spend to get it installed in their local environments? If it isn’t going to be installed locally more questions are raised. How much effort will there be to make sure the interaction with local development will work with the remote development installation? How will the interaction be tested? How will every developer stay out of each other’s way?
  4. Is the new technology completely replacing another technology? If the answer to this question is “yes”, congratulations, you get to skip the next question.
  5. How much time will be spent maintaining this additional technology? Updates are inevitable. Crashes are likely, especially with technology the team doesn’t have any experience with. Troubleshooting features that use the new technology will require another set of skills to find the problem.
  6. If/when you have to scale the new technology, how much effort will that be versus the current technology?
  7. When you have to hire another team member, how hard will it be to find someone with this additional skillset?

Benefit Questions

Now that we understand the negative costs associated with bringing in a new technology, let’s look at the benefits we get out of the deal.

  1. What benefit is the new technology bringing that existing technology is not? Is the new tool easier to work with? Is it more performant? Note that the only positive chips that get to be added here are the difference in benefits over the currently used technology.
  2. How much (if any) time will be saved by using the new technology? Is it easier to write the queries you need for the new feature with this database? Is scaling the new technology easier? Is it easier to troubleshoot or maintain the new tool? Perhaps the new technology is so performant, it will save you time scaling existing technology.

Resolution

The answers to the cost and benefit questions have to be quantified somehow to achieve resolution. This is the hard part. The answers are frequently gut feelings but I find it helpful to attempt to find a number qualifier for each question. Chips on a balance provide a nice visualization. Remember, every chip does not have to be the same size.

Once this is done the decision is easy. If the pros outweigh the cons, bring on the new technology with a clear conscience. If the cons win out, or the return on investment (ROI) won’t be realized for 10 years, it’s probably best to let the shiny new thing go.

RDD (Resume Driven Development)

I came up with this acronym years ago because I had seen so many decisions made that were so unbalanced on the cost/benefit scales that there must have been another factor in play that I did not consider. The only question that I could find that must have been asked was:

How good will this look on my resume?

It is my opinion that this question does not belong in the consideration of how to spend somebody else’s resources. Side projects are a great way to satisfy RDD. Please keep it out of the software your customers and your business depends on. I believe doing otherwise is irresponsible.

And Finally

Whenever we have a decision to make on a piece of technology, which database to use or what language to write a new service in for example, we often don’t consider all of the costs this decision comes with. As such, bad choices are frequently made by us for the business.

I am sensitive to waste. I don’t mind spending resources, I do mind wasting resources. You have to spend time and money to get anything done. But when these resources are being diminished and no progress is being made, the course must be corrected. It is our responsibility to understand these costs, weigh them against the benefits they provide, and make the right decisions that will spend the business’s resources most effectively.