Stay Objective in Technical Discussions

In my last post, I mentioned that longstanding discussions and arguments are one of the biggest wastes in software development. I described a way to structure your “pros and cons” in technical discussions. However, if people keep expressing themselves subjectively, we’ll still suffer in endless arguments.

Today, I’m going to describe a framework that helps people focus on objective aspects when we compare technical options.

When should we apply this framework?

In my previous post (Best Time to do Technical Pre-design), I described that the time spent in discussions is not worth if the problem can be solved by just coding and refactoring easily. So this framework should only be used on the unavoidable discussions for complex problems.

For example:

• Technical Vision
• Aligning technical solutions with other teams
• Technical solutions at the beginning of a project

It is not for choosing technologies such as a language or a type of database.

Before we dig into the framework, let’s have a look at the requirements.

Requirements are keeping changing

It is one of the always-true statements in software development. The requirements we think are important at the beginning might not be implemented after many years. Unexpected requirements come all the time. And the understanding of a requirement also changes over time.

So the stability of requirements looks like this:

Requirements change over time

Because of that, it is impossible to guess future requirements right at the beginning. It means changes are inevitable and unpredictable. So It is very important to maintain your systems in a state that easy to be changed.

Changeability

However, maintaining changeability is not easy.

Clean Architecture in Math describes that the smaller scope a future change lands, the smaller effort the change requires. And also, the fewer dependencies we have in our architecture, the less chance that a change lands in many places. (If two systems are tightly coupled, they likely need to be changed together.)

fewer dependencies, easier to change

In an organization, normally we have 5 levels of scope:

• Organization level: a change requires multiple Verticals involved
• Vertical level: a change requires multiple Domains involved within one Vertical
• Domain/team level: a change requires multiple systems/components involved within a Domain
• System level: a change lands to a system including databases
• Code level: a change requires only code changes in a system

organization structure

So by reducing the higher level dependencies, we can reduce the scope of changes.

There are two types of dependencies:

• Data dependency: the consumer needs to understand the data mastered by the provider, vice verse
• Function dependency: the consumer needs to call the provider to fulfil a requirement

The Framework

Now we know that to keep your systems changeable, we need to reduce the higher-level dependencies as much as possible.

We can compare technical options by visualising the dependencies and calculate the complexity of each option so the least complex solution can be picked to keep your system changeable.

The steps:

1. List requirements: only pick the requirements that you are going to support in a near future, do not pick any uncertain requirements
2. Choose 2 to 3 levels: pick the levels relating to your decision (the following example chooses higher levels)
3. List your options: describe your options with diagrams
4. Count dependencies in each level for the options
5. Summarise your overall dependencies
6. Calculate the complexity of each option: you can simply triple the complexity of higher-level dependencies because the changes in higher levels are much much harder than lower levels. You can also adjust the factor based on your context.
7. Choose the least complex option

The table for the comparison looks like this:

If the difference of each option is small, then means it doesn't matter which one to pick.

Summary

Staying objective is one of the key aspects to keep discussions valuable. This framework is trying to give you a way to pick options with data instead of arguing. It helps you to calculate the complexity by Math of each technical option instead of talking about extensibility or flexibility by feelings, so teams can reach an agreement without valueless arguments.

Structure your “pros and cons” in technical discussions

If an argument can not be solved in 5 mins, it can not be solved forever unless you bring some data. Uncle Bob mentioned this in his book <Clean Coder> in 2011.

However, after 10 years, most people are still used to use only “pros and cons” in technical discussions. Different roles (developers, BAs, QAs, product owners) bring their “pros and cons” from their own perspective with their own language. They list everything they can think of whatever it matters in the discussion or not. The more people are involved, the longer list is. It ends up with a table like below:

options with pros and cons

How much does the table help you to choose one of the options?

Problems of “pros and cons”

• Subjective: pros and cons listed by different people are from their own perspective, mostly they are not comparable
• Ambiguous: the same point sometimes can be a pro in some context and a con in others
• Lack of visualisation: the option with more pros or cons doesn’t mean better or worse
• Not friendly to readers: readers have to read everything to understand each option
• Time-consuming: the writer needs to type a lot of words

As we know, everything has pros and cons, so just listing them without a structure that allows people to compare options easily wouldn’t help to reach an agreement. It normally ends up with the tyranny of the majority or blind belief in authority.

Structure your “pros and cons”

The intention of “pros and cons” is to ask people to listen and understand others’ opinions. Get everyone to align on the following things during a decision-making process/discussion:

• the aspects (make it objective as much as you can) matter to this decision
• priority of the aspects
• data or agreed rate on each aspect for each option

All of them can normally be extracted from the original “pros and cons”. The final structure looks like this:

options comparison

The table visualises things we care about and the trade-offs of each option. The discussions should focus on getting agreed on each cell in the table instead of listing more “pros and cons”. Once the content of the table gets agreed on by the participates, an aligned decision is normally reached.

Summary

Technical discussions are one of the biggest waste in software development nowadays. So stop wasting time arguing “pros and cons” with your colleges. Start visualising them with others so that you can improve your efficiency in your decision-making process.