Decide to change destiny

This is a study of a decision. Analyzing it. Breaking it down. Making the right decision.

“Crying is all right in its way while it lasts. But you have to stop sooner or later, and then you still have to decide what to do.”

― C.S. Lewis

The Decision

Whether to make the switch to a new database for our software product. Can be reframed as: How best to future-proof the product?

Goals

  • Support our customers in all possible ways
  • Contribute to customer success by addressing their pain points
  • Adapt to new technology
  • Future-proof the product

Sunk Cost Analysis

  • The team has put in a lot of work into the product using the current database.
  • Many developers have learned these skills and helped grow the product.
  • However, many breakthroughs in software have happened by discarding old code. So, it may not be advisable to continue the inertia.

Decision Tree

Decision Tree

Choices, Dependencies & Outcome Risks

  • Keep the current database (Revenue: $30 mil. Potential loss in 5 years: $20 mil)
    • There are no major complaints from customers
    • The product continues to function well
    • Also, the current team of developers are highly skilled and knowledgeable. They make sure the current system continues to work very well
    • Risk is that the product may no longer be up to date with the latest trends
    • Another risk is at some point in the future, customers may start switching to competitors’ products who have the new technology
  • Buy a third-party database (Cost: $4 mil. Potential revenue in 1 year: >$30 mil)
    • A one-time investment of $2 million is committed to buy third party database
    • Best database for our purpose is selected from a range of competing systems
    • Commit a small Tiger team to work with the third-party developers and integrate the database
    • Commit to retrain our developers with the new skills required to work with the third-party system
    • Commit to sign a service agreement with the third party company for their support
    • Risk is that the third party database may not be fully adaptable to our product architecture, necessitating some architecture changes
    • Another risk is in case the third party company goes out of business, we will no longer have their support for the new database
  • Build database in-house and slowly replace the old database (Cost: $1 mil. Potential revenue in 2 years: >$30 mil)
    • Commit a small Tiger team for about one year to come up with the infrastructure needed to make the switch
    • Commit a set of developers (called the A team) chosen to train with the new skills required to work with the new infrastructure
    • Plan for the product to have both databases in place
    • Plan for existing features to continue to run on the old database
    • Choose a cut-off point, after which, new additions will only be made in the new infrastructure
    • Slowly over one more year, the A team will replace the existing set of features to work with the new infrastructure
    • Inevitably, there will be some backward incompatibilities introduced. These should be well documented and communicated to the customers
    • Customers should not realize any difference in performance or stability
  • Build database in-house and make the switch in a couple of years time (Cost: $1 mil. Potential revenue in 2 years: >$30 mil)
    • Resources have to be committed to retrain developers in new skills at some point in future
    • Commit a small Tiger team for about one year to come up with the infrastructure needed to make the switch
    • Commit to train rest of the team with new skills
    • In one more year’s time, the full product should be converted over
    • Inevitably, there will be some backward incompatibilities introduced. These should be well documented and communicated to the customers
    • Risk is that the newer code may not be stable because of the drastic switch
    • Another risk is customers may end up not liking it right away because of the drastic change

In the end, the choice to build the database in-house and slowly replace the old database seems the best in terms of:

  • costs
  • long term revenue
  • risk management
  • future-proofing the product

Post-script

The change agents in this case are the stakeholders who try to predict the future in some way in order to keep the product marketable.

Among the risks I wanted to take into account, included the risk of product architecture change necessitated by introducing third-party components into the system. I think this is a real issue which many engineering teams face, but may not anticipate beforehand. So, I tried giving a value to this risk scenario.

Thinking about what could be cut out while working on this task reminded me that I had taken the availability of resources for granted. On many occasions, one needs to work with constrained resources in terms of money, time and labor. So, I will definitely keep this in mind going forward.

I also need to consider the positioning of this proposal for not only this product, but also the product line and the organization. Of course, there are may other aspects of this product itself, only one of which was considered in this proposal, which contribute to its overall success. I suppose I am biased because my responsibility has been the database portion of the product. It may help to add a section on a broader perspective of the product including its many other aspects.

I think, taking into account the limited resources available, spending extra money on the third party option may not be feasible at this point.

On decisions

When making any decision, as human beings, it seems that we tend to overestimate its success.

One tends to assume that the decision will work out and eventually everything will go as planned.

However, on many occasions, one may not have thought out all the consequences. As a result, when the outcome does not work out or when something bad comes about, one gets frustrated and disheartened.

It seems that if the outcome is good, one is elated and if the outcome is bad, one is disheartened.

karmaṇy-evādhikāras te mā phaleṣhu kadāchana
mā karma-phala-hetur bhūr mā te saṅgo ’stvakarmaṇi

A rough translation is:

You have a right to perform your prescribed duties, but you are not entitled to the fruits of your actions. Never consider yourself to be the cause of the results of your activities, nor be attached to inaction.

As Krishna advises Arjuna in the Bhagavad Gita (chapter 2, verse 47), one should not confuse two separate things:

  • making the decision
  • the outcome of the above decision

The only aspect of the process under one’s control is the action itself.

While making the decision, keeping in mind that the outcome is usually not under our control, it is useful to slow down and break down the decision into smaller components.

Building a tree and assigning values to each component of the decision is a very helpful guide to making any decision. Especially for important and complicated decisions which carry substantial risk/reward, such an analysis can be helpful.