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.
- 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
|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
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
- List requirements: only pick the requirements that you are going to support in a near future, do not pick any uncertain requirements
- Choose 2 to 3 levels: pick the levels relating to your decision (the following example chooses higher levels)
- List your options: describe your options with diagrams
- Count dependencies in each level for the options
- Summarise your overall dependencies
- 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.
- Choose the least complex option