https://www.youtube.com/watch?v=OXP-sUS6ffE
Something is complex when its too much entangled. Simple means one thing.
Types of complexity, from a paper called "no silver bullets". We can't remove the essential complexity. Accidental complexity can be removed, and are generally created by developers.
Cyclomatic complexity was introduced in the 70's and become higher when more branches are present in a function. For example, a if clause generate a complexity of 2.
Cognitive complexity mains the complexity to reasons of what a function can do. This complexity come from different principles and syntax.
Abstraction was made to mitigate the complexity by cutting it in small functions and hide implementations details.
Notion of the complexity trap. There not one but multiple. The first one is "Neglecting the costs". The approach is selected to reduce the code base but sometime this approach can create more complex with only one line of code.
Another one is "choose your poison", by trying to solve complexity by more hidden complexity.
Embracing industry standards can create more problems than it solves actual ones.
Embracing the latest fad can cost you many problem too, because the new standard can be deprecated soon.
Abstracting come with a cost. You need to implement multiple version of the same code for different purpose (e.g. testing).
Move all the logic in function core and branch it with imperative shell for all the side effet. The logic function will stay pure and the test will be easier to create.
To solve complexity, focus on the "How" and not the "Why" or "Why Not". Some trade-offs must be made. We should write more about boring solutions than the latest new fad to solve the problem.
The last aspect of the complexity trap is the "maximum zoom". When you are focused in a problem, you can lose the context because you only have a tiny view and not the whole picture.
The jump to towards technological solutions are too quick and new libraries should be taken with care.
The most important technique is the root cause analysis. When a problem arise, we are quickly looking for a solution, and searching for the origin of the issue. Some issues are coming from a deep origin, like system structure or company structure.
A project or product can fail because a problem domain is not well understood or the the architecture is not a good one and does not fit for the requirement or how the organization is structured, or maybe politic or people but never for a lack of features in a language.
Conclusions:
- leave your programmer comfort zone
- consider costs
- talk about trade-offs
- don't ignore boring solutions
- slow down and stop meddling with symptoms
To see: