"This change should be easy"
"We could a clone on a hackathon"
"We have no time for refactoring"
"We kind of forgot how to ship stuff fast"
...
For further actions, you may consider blocking this person and/or reporting abuse
This sums it all up pretty damn well. Beekey Cheung writes some thoughtful articles along these lines.
One thought of mine: While complexity grows over time (and we are on a constant fight between value delivered and complexity, always trying to keep our heads above water), there also come moments of solidification: Where, after a bunch of small pivots, our mental model becomes pretty clear, and we can move in and prune a lot of the bad ideas from the code because we've settled on the direction.
That's the stage when we want to fight the urge to hoard failed ideas as dead code we "might" make use of. Consistently looking for opportunities to delete code associated with pivots is probably the best way to manage this stuff over time.
+100, I read something aligned to this recently and I'll badly paraphrase it here apologies to the author, "deleted code is debugged code", resisting the urge to hoard is one thing but actively pruning dead code is another
Regarding each bit of added code and complexity.
each custom line of code is managed by you - maybe badly - but managed
there is hardly ever a downside to removing code
you can usually look in git to see how it was done and cherrypick the good parts if needed
Thx for the article!
It would be so nice to be able to measure some of these values for a "codebase".
I just realized that working with a monorepo means you might have multiple codebases in one repo that might need to be looked at separatly.
Love the smooth vs weird surface area cube analogy. It's like putting Band-Aids on when something actually needs an overhaul instead.
Also, as someone currently learning a new codebase, I find myself spending a lot more time reading the code and figuring out it's structure. This allows me to make sure I'm not writing in code that may be short in the "component" axis, but will increase the "time" axis. Personally, I find managing the "time" axis pays off more later on, but those are decisions to be thought over as the app grows.
Andreas, great post, and thank you for sharing! I loved the "Radar Chart" as a mental model for imagining the multi-dimensional concerns of a code-base. Also adds visual context when developers talk about the "surface area" they need to manage.
Kind of reminds me of something.