Maximize frugality rather than produce bloat
This is the 8th post from my sincere dev manifesto series.
The easiest code to modify (secure/test/APIfy/document/support/sustain) is no code. It is an ideal, and I try to tend towards it. It is also true for features, system complexity, things, and people.
John Cutler promotes Remove a feature day.
Never add things “just in case”. Even less because it’s easy to add them. When Sir Tony Hoare, inventor of null, is asked why he did that, he answers he did it because it was easy to do. He calls it his Billion dollar mistake.
Complexity increases, not with the number of things, but with the number of relations between things, and between things and the environment. And relations increase exponentially with the number of things. This is why math teachers taught me to be lazy. “Perfection is reached, not when there is nothing more to add, but when there is nothing more to remove”, said Saint-Exupery.
As a computer buddy, I’m looking for the only two magic numbers: 0 and 1. Other numbers lead to explonential complexity.
Of course, we can also produce complexity artificially. Look at FizzBuzz Enterprise Edition for example. We can call such bloat technical debt, but it’s usually incompetence. Like a weakness for the golden hammer (when all you have is a hammer, everything looks like a thumb), making you apply the same recipe in a different context. OK, we can call it negligence. Or rather, that we don’t take the time to make things simple. Sticking to what’s needed, without the arrogance of pretending we were right in predicted the future, is hard. Simple is not a synonym of easy. Simple is terrifyingly hard. It takes time, attention, iterations. Sometimes it clicks, and sometimes it never does. “I wrote a long letter because I didn’t have the time to write a short one”, said Blaise Pascal.
We love adding flexibility to the code, just in case, at the cost of design patterns (generally along arbitrary dimensions, while hardening others). But the math is not on just-in-case side in software. Because is software is soft, easy to change. And it gets easier to change with our growing refactoring skills. Refactoring is a core developer skill to master, because it allows simplicity. In code, I want to see the domain, not design patterns. We need to learn trusting this skill.
I learn to adapt to my microscopic cognitive capacity. I move in baby-steps, then micro-steps, then nano-steps. It helps me keep fewer hypotheses dangling.
I commit to producing as few sub-products of understanding as possible, like code or features.
AAAgile 
3 comments