It’s Not Microservices, It’s You
By: Oskar Uit De Bos
Tags: Software Development, Software Engineering, Microservices

It’s Not Microservices, It’s You

Microservices are just one example of a technology trend that has been hyped up to be the answer to everybody’s problems

Photo by You X Ventures on Unsplash

The hype creates a dynamic of inflated expectations and excitement with business representatives and software engineers alike. In companies and teams where decision pushing is commonplace this often leads to rushed decisions, which likely ends in frustration and disappointment.

Business representatives, software engineers and other technical specialists should be freely exchanging ideas, discussing risks and doubts as well as challenging each other with strong mutual respect. Creating this culture takes effort, a sense of personal responsibility and proactiveness from all involved. And I can guarantee you, no architecture or new technology will create long term success if the culture within the company is dominated by a small group of individuals who don’t understand that being a leader is to listen.

Teams that rush into microservices can get burned in many different ways. When re architecting an application into smaller, loosely-coupled pieces of software that communicate with each other over a network, teams suddenly have to deal with the fallacies of distributed computing and decentralized data management. There’s a multitude of articles that explore these complexities in greater detail, so I won’t replicate that effort. I can say that underestimating these complexities often results in fragile architectures, scaling issues and substantial rework. Mastering them takes preparation, planning and experience.

We cannot overcome the fact there will be a learning curve, as there really is no substitute for experience. That being said, the chances of success can be greatly increased through the right preparation and planning. A key aspect in that regard is estimation.

In this blog I want to share an estimation technique that I’ve found to be helpful to channel the excitement around technology trends and break through unrealistic expectations by providing clarity on effort as well as associated complexity, risks and unknowns. This enables the right conversations between business representatives, software engineers and other technical specialists about trends like microservices before committing prematurely.

How to do work estimation right

No matter how hard you try, estimation will never be perfect. We cannot predict the future and foresee what we don’t know. The fact that we cannot be perfect when estimating, does not mean it doesn’t have value.

Complexity, uncertainty, and risk are all factors that influence confidence and therefore also influence the estimated effort. But most estimation techniques whether it’s hours, ideal days, story points or t-shirt sizing, only focus on the effort and don’t provide means to also express confidence.

Which is a shame since it’s a big part of the value that is achieved through estimation. Because work that the team doesn’t feel confident about is much more likely to cause problems. One way of making confidence transparent having the team that will be delivering the work perform range estimation. A range estimation technique I’ve had good results with is the 50/90 estimation technique. When using 50/90 estimation, every piece of work is estimated twice:

The first estimate represents a “aggressive, but possible” (ABP) estimate where there’s 50% certainty of completing the work within that time.

The second estimate represents a “highly probable” (HP) estimate where there’s 90% certainty of completing the work within that time.

A narrow range, with the ABP and HP estimates being fairly close together, means the team is confident in the work. A wide range, where the ABP and HP estimates are far apart, means the team is not confident in the work based on current information and knowledge.

When dealing with a wide range, the team should discuss the complexities, risks or unknowns they foresee and if these can be reduced or mitigated. Some examples it’s lead-time, dependencies on other teams, known bottlenecks, development complexity of technologies that are not known. When these things are outside the span of control of the team, they’re still relevant. Doesn’t mean it becomes their responsibility to fix, it’s their responsibility to make it transparent so it can either be acted upon or explicitly accepted.

There are three additional rules that ensure you get the most value out of the estimation process and the decision making process:

Make sure that the estimation is done by the engineers that are performing the work. Involving others with prior expertise is certainly valuable, but they should assume a role where they use their experiences in a coaching capacity with the goal to eliminate blind spots in the estimations.

Prevent estimations performed by one person to reduce cognitive bias and in a group setting make sure everyone involved provides input. Which can be challenging in groups with very vocal or overpowering individuals if not addressed. A simple trick often applied in story point estimation is having everybody present their estimates at the exact same time to eliminate the possibility of people being influenced. This is crucial to reduce the cognitive bias of individuals and extract the best out of the team by sparking the right conversations.

Communicate estimations in bandwidth form, with the identified risks and possible follow up actions to reduce or mediate risks. The 50/90 estimation technique offers a formula for compounding all the range estimates back into a single number.

With the estimation results available, it’s time to decide what to do with the identified risks. Often it is possible to reduce or mitigate them. A common example is building a proof of concept to better understand a particular problem or challenge. The improved understanding or reduced blind spot should improve estimate accuracy. Investing additional time and resources in reducing or mitigating risks might not always be possible or worth the effort. This is fine, as long as residual risks are explicitly accepted.

Preparation is half the victory

Instead of telling you if microservices are the right choice I shared a technique that enables your team to come to their own conclusion. Which is how it should be as nobody understands your circumstances better.

A key takeaway is that estimation is just a tool. The real goal is using that valuable information to bring everyone together and have honest conversations about the value and the realistic cost of applying/using microservices. Doing so gives a much better starting point than someone who watched a few tech talks on how Netflix migrated to microservices and feels that success can be replicated overnight.

It’s very possible that some teams come to the conclusion they don’t need microservices or that they don’t feel confident enough given the complexities and learning curve when viewed in context of time constraints. Companies and teams often have multiple improvements going one in parallel so priorities have to be set.

In that case, consider starting with a monolith that is designed to be modular. This enables that application to be broken up into microservices later if their situation changes and the additional complexity of microservices can be justified. This upholds the KISS and YAGNI principles and avoids over engineering while also being mindful that the situation might change in the future.

Those who have completely disregarded monoliths would do well to remember that Netflix started as a monolith before transitioning to microservices at a later stage. And while we all have the belief that we are building the next unicorn with massive scale requirements just around the corner, it’s likely that some of us are wrong.