Explore limits rather than follow a cult
This is the 11th post from my sincere dev manifesto series.
Like some Melanesian people during WWII, we live among cults. Cults generally start with decent points of views, and get generalized too broadly. They become subjects of jokes, but have their truths. It’s all about limits and constraints. Heuristics are true within contextual limits. Beyond these limits, you can have fun.
A few examples:
- Every person is different. Just forget about MBTI or astrology.
- Cross functional teams don’t embed HR or finance. Some functions remain transversal.
- All models are wrong, some are useful. By definition, models are a compression of the world, they omit dimensions on purpose.
- The levels of your test pyramid depend on your technologies, your dependencies, your tools, your knowledge. There are more than 2 dimensions. Level boundaries may even change from test to test.
- DRY (Don’t Repeat Yourself) is true within a bounded context, and should be used with much more care across bounded contexts.
- I start with WET (Write Everything Twice) before DRYing relevant things. After all, I’m more careful with coupling and dependencies than saving lines of code. Effectiveness over efficiency.
- DRY applies to semantics, not syntax. You don’t extract a plus function because a piece of code adds 2 ints and another one concatenates 2 strings. But the syntax of a granularity level might the semantics of the smaller one…
- Every design pattern allows easier evolution along a dimension, while making another dimension more rigid (if not all dimensions when the rigid dimension is observability).
- Software without side effects is useless. There has to be some side effect somewhere. Also applies to my favorite tool: immutability.
- Start with why. Also, the why of a granularity level is the how of its parent. There’s always another why, which is why science doesn’t explain things, but describes, at best predicts them.
- If taking people out of an ensemble programming team doesn’t change the outcome, how long can we keep them out of the ensemble? Why can’t we just take them out of the team? What is the lower limit of the ensemble? The optimal team setup?
There’s always a limit to the optimal application zone of heuristics. These limits are multidimensional and contextual. It’s a trade-off.
Like for architecture decisions, when taking any kind of decision, you always need to ask yourself what you loose, not only what you get. You always loose something when you draw a line in the sand.
I commit to exploring beliefs boundaries, challenging their applicability conditions, and promoting itDependsing™.
AAAgile 
One comment