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.