Frontend Complexity originations. Root causes principles
The semi-complex plus frontend applications have 2 core (or in another word “essential”) and 1 derivative (“accidental”) root causes that span and nourish roughly north of 80% of issues — they are either direct or indirect.
So, Frontend Engineers are paid 82,496k euros annually here in Holland to tackle those root causes, navigate through them and contribute to (mostly) junk Web Pages.
These root causes are:
- Non-essential (accidental) state,
- A sequence of execution,
- Amount of code.
As you imagined the last one would be derivative. But in order to understand why it is derivative we need to dive into the core complexity root causes (or name it anti-patterns) first.
Non-essential — Accidental state
Assuming the “state” of your application in any form — Redux, MOBX, Recoil, simple properties on your classes, variables, or any other ways of managing — the current snapshot of your application.
A non-essential state is the most essential part of every middle-sized plus application (with at least a basic level of dynamism of the application and user interaction) that contributes to complexity.
Its characteristics can include:
- It is derivative and could have been avoided otherwise,
- in 70% of the cases was created due to a mental shortcut, lack of knowledge, or because the less experienced person (maybe higher in organizational ranks) pointed you out on it on PR Code Review and you were too hesitant to argue or protect your point (sadly), or indifferent to company success,
- your other valid ideas.
There is also another valid reason — by design — it can be done by the top 5% of peak-performant and intelligent engineers to save other computational resources. It’s a perfectly valid reason to have a non-essential state to save computer resources — since everything is a trade-off in computer systems then it’s entirely possible that we, e.g, cache intermediate values, use memoization or other simple approaches to save computational resources in the extent of others (memory, for example).
Anyway, it’s there. Add this up to the essential state of the system.
A sequence of execution
We all had a situation in our Software careers where we had dozens or hundreds if not more tabs in IDE while trying to understand root-cause of action as well as what came before, what came with, and what happened after it.
It’s almost impossible these days to comprehend the true flow of any decent-size software that had passed its initialization point — if I were to stop the program execution in time or we get the overall state of everything in it — would you be able to work the way of flow in and out with all possible variants of development? Or to do it without documentation (because it’s a 3d party part of the code that you haven’t written and you need a starting point); or asking your colleague (because it’s another team who engineered this code); or reverse engineering (because it’s written by you and Git remembers everything … and sadly you don’t). Frankly, me neither. I don’t think it’s even possible given some software's complexities and the limited abilities of our brains.
By opening any point in time the place where the program is being executed how anyone would be able to tell what comes next, what came before, or with it? No one? Or someone once in a while if lucky enough — don’t fool yourself, I open the code I wrote yesterday and ask myself who wrote this bool-shit only to find the truth out with Git history that it was me.
Amount of Code
Two core principles both contribute to the amount of a code. You need to code an accidental state or add code to create “flow” in your program. In order to support somewhat correct execution of software applications at a given time and environment we (usually via Software Engineers but lately I guess increasingly via code generators and AI) push 2.8 Trillion Lines of Code that have been written in the past 20 years as stated by Sage McEnery in his Medium article.
That alone can put the mental health of individuals into despair.
In order to ensure that code works and that business processes implemented or enhanced by IT; do not break while evolving and stressed daily more and more IT also will add “non-essential” to a business processes (but essential for their future) supplement code like unit tests, e2e, fallback scenarios, error handlers, graceful shutdown and many more.
Well, that’s the third reason.
Let me know in the comments if looking forward to seeing more about each of the root causes since they deserve their own story to be told.
How to manage all of these? Let’s try to unwrap this up into upcoming articles.
These thoughts are mostly inspired by work in the last couple of large companies, their (and mine of that time being) big projects as well as different great learning resources like Out of the Tar Pit by Ben Moseley, Peter Marks.
What do you think?
