Technical Debt and Embracing Risk: How to find the MVP

Any good engineer constantly finds themselves asking what is the quickest and easiest way to deliver value to my stakeholder. This is commonly referred to as the MVP or minimal viable product. In easier terms it means what is the minimum I have to provide for my product to be useful to stakeholders. In fact, many engineers commonly stop and ask themselves in the middle of a project is this the MVP? However, by then it may already be too late. So, how do we solve this? We’ll examine some concepts such as good and bad technical debt, embracing risk, and the idea of what is value (and perhaps the difference between value to us and value to our stakeholders). Hopefully a consideration of these concepts can help us to examine what the MVP really is before we even touch a keyboard.

Technical Debt

Debt. Whether its monetary, time or something else, anything of value comes along with debt. For an engineer, the biggest thing of value is his time (and energy). There is commonly a bad stigma associated with technical debt but the truth of the matter is technical debt can be good. How so?

Technical debt can enable you to move faster when delivering a product or value to a stakeholder. To illustrate, typically when purchasing a car one goes into debt as they may have to get a loan. However, this allows for transportation to and from work, the grocery store, and other necessary places. This kind of debt delivers value upfront and can even aid in eventually paying off the debt. Sure one can work for a year to save up for the car but is this work really offering value up front?

Essentially, an MVP may have us take on some technical debt. Work may have to be refactored or reworked. However, value is delivered upfront to the stakeholders. It has also been my experience that technical debt can help to get some of the foundational logic in place for certain things. Code can be refactored or even changed but hopefully the behavior remains roughly the same. A word of caution though. Beware of reckless debt.

Technical debt does not mean lack of consideration. Rather the cost of taking on technical debt should be counted and considered in relation to the value returned. Back to our illustration, I grew up in a desert climate. Not a body of water around me for hundreds of miles. (Does a pond count?) Now, imagine I were to go out and get a loan for a boat. Can it really be said that the debt I took on is delivering value?

The point here is technical debt (and real debt) should not be taken lightly. Rather it should be considered, counted very carefully, and documented in some form. It also does not mean we allow bad practice to invade our workflow. To paraphrase the pragmatic programmer: One broken window and there goes the neighborhood.

It is impossible to alleviate all technical debt but, by remaining wise and considering the technical debt we take on we can create a true MVP and build a good foundation that can be iterated on. Another question to carefully consider is in addition to technical debt, how much risk am I willing to take on?

Embracing risk

I am a firm believer in the SRE handbook’s stand on embracing risk. Anything worth doing involves a measure of risk. We see quite a few examples of this in any industry (especially the technology industry) and we also see that in end nothing is a guarantee. Innovation is inherently risky. However, without innovation (and rapid innovation) a company or product will die. So, how do we balance risk and the MVP?

Look at the following illustration:

What do we notice about a skateboard as opposed to a bike or even a car? More risk may be involved. It is easier to fall off of a skateboard as opposed to a bike. Also much easier to fall off a bike than to fall out of a car. (Although not impossible). The idea is that granted each product above has considerable risk but the question once again is how much risk should we accept?

To quote the SRE Handbook: "We strive to make a service reliable enough, but no more reliable than it needs to be." The idea being that investing too much into reliability can slow production, introduce bottlenecks, and is the enemy of the MVP. So like technical debt sitting down and calculating the cost before making a decision is the correct path. Measure how available does my system need to be? What is the expectation from my stakeholders? This will require communication with stakeholders and having clear requirements from your stakeholders.

Once again, MVP does not mean throw caution to the wind but rather means weigh what is necessary for my product to be viable right now. To understand this we have to ask what is value?

Value

The question of what is value is an interesting question and a matter of perspective. Value to you may not translate as value to your stakeholder. So, how can we differentiate between the two?

In the picture above the two men have a similar objective...to get water. One of these men is concerned with the MVP and one is not. Likewise, one will survive and one will not. This illustrates the importance of figuring out what is of value and what is not and delivering that value quickly. How can this be done?

Once again communicating with stakeholders to figure out what is most valuable to them and focus on shipping just that nothing more. Get hard (and preferably measurable) requirements. Do not leave anything to chance and do not make assumptions. When in doubt ask.

The benefit of communicating clearly with stakeholders will (1) help to identify value, (2) tear down organizational silos and (3) will allow for clear feedback. Once an MVP has been released stakeholders can give feedback on what they like and what they do not like. These suggestions can then easily be included in future iterations.

MVP for the win!

The MVP pattern enables you to deliver value quickly, allows one to innovate, and encourages communication with stakeholders. It does require discipline, consideration and balance. In the end, it can lead to a good product and can help to avoid unnecessary work. So, I'll leave you with this question...why build a ketchup cannon when all that was needed was a ketchup bottle?