Functional decomposition

Designing an architecture by inspecting the required functions. Functions comes first in functional decomposition. This is discussed in Juval Löwy’s course on #Righting software about how not to design software.

It’s the easiest way to build software and therefore also the most common, but worse it’s also partly why any other procedures is more or less unknown.

Prevents reuse

This may seem contrary to what functional decomposition is actually meant to solve. “By grouping each function, we split up the code and can reuse the functions from the different services” -said the naive architect.

The problem lies in the integration. You implement the functions and start adding integrations between them, thereby locking in the feature-sets. As a result when you need to use a feature from one of the services, you either need to add some bad spagetti integration between them or you duplicate the features.

Worst-, and most common case, is that some circular dependencies starts popping up. When this happens the project could easily be declared dead, and any further progress made on it will just keep on putting nails into the coffin of a rotten corpse that is the project.

To strengthen the argument, we can look at:

the comparison of Designing software vs hardware#,
an example of Stocks trading service using functional decomposition#,
or how using functional decomposition enforces Locking in to vendors#.

Technical dept

There are many phrases to describe projects that are in bad shape.

Code rot
Technical dept

But they are all essentially the result of functional decomposition.

Due to functional decomposition, projects turn out so bad that the developers say:

We won’t have it no more! We need to rebuild it

And then the manager does not (but should) answer:

But you messed it up the last time…

References

J. Löwy (January 27, 2021), “Righting Software - System Design” [Workshop], NDC London 2021.

2021-01-28

#No one understands they are killing projects
- Features are to be implemented. At least, that’s the spirit of when designing by #Functional decomposition. But persuing functional decomposition essentially kills the project before the first programmer even sets their fingers to work.
#Issues with repeating design misstakes
- Designing by #Volatility decomposition is supreriour to desigining by #Functional decomposition. And yet, we fall into this trap again and again.
#Volatility decomposition is no guaranteed win
- Fighting #Functional decomposition in favor of #Volatility decomposition gives you a fighting chance. It will be tough, and it will require you to toil with learning and practicing; but it makes it possible.
#Issues with the manager
- Designing from volatility-based decomposition takes time. Much, much longer time than #Functional decomposition, especially when you start out.
#Locking in to vendors
- The work that has to be put in to switch a library vendor usually means having to visit all your services, given you’ve followed #Functional decomposition during the design process.
- Isolating the use of the vendor would resolve this, but this is very difficult as long as you still follow #Functional decomposition.
#Stocks trading service using functional decomposition
- By using #Functional decomposition to design a stocks trading service, in let’s lay a microservice architecture, then you might end up with the following architectural diagram:
- To be more clear: This is yet another case where #Functional decomposition fails.
#Allure of the free lunch
- Doing #Functional decomposition is equivalent to the olden alchemists, and is therefore why it will be increadibly difficult (if not impossible) to convince your teammates that functional decomposition is bad.

Getting good at volatility decomposition
- Designing by #Volatility decomposition is miles more difficult than designing by #Functional decomposition.
- The biggest issue you will have is your Issues with the manager#. You will have to fight the manager, and your coworkers, with designing the system in any other way than #Functional decomposition.
Designing software vs hardware
- Common argument for designing the architecture differently for software vs hardware, such as using #Functional decomposition which is rarely ever used in hardware architectures design procedures, is:
- If we apply the invalid techniques used today to build software, namely #Functional decomposition, then we can notice some somewhat amusing yet extreme results:
Designing a house against the requirements
- If you design the house using #Functional decomposition, then you’re never done with the specifications. They will never fulfil the requirements.
Using domain-driven decomposition to build a house
- This however, is no different than saying you’re using #Functional decomposition to build a house. You’re just expanding the scope of the features.
Volatility decomposition
- Given you’ve designed by #Functional decomposition, the result will most probably be that the component explodes, and fragments of the explosion shatters across the entire system, damaging seemingly unrelated components.
- There are plenty, and all originates from the fact that it’s more difficult and requires more sweating than #Functional decomposition.
Using functional decomposition to build a house
- When designing software, #Functional decomposition is the most natural procedure. It’s the most common practice, because it’s the easiest practice.

Overdoing volatility decomposition#
- Designing so every subset of your system needs its own block is called designing using #Functional decomposition.
- Volatility-based decomposition is hard work, and function-based decomposition is easy, ergo it’s utterly easy to procastinate your design process by doing functional decomposition. In this case, #Functional decomposition is the Song of the siren#.
Righting software#
- How not to design software: #Functional decomposition
- The latter, regression testing, is not feasible nor fully achievable when desiging by #Functional decomposition.
code-design/#
- Parent directory zettel