4 ms·
I see people planning for success to the point of guaranteeing failure, much more than people who suddenly must try to handle success in panic. It's a second s
by boxed 2y ago
I see people planning for success to the point of guaranteeing failure, much more than people who suddenly must try to handle success in panic.
It's a second system syndrome + survivor bias thing I think: people who had to clean up the mess of a good MVP complaining about what wasn't done before. But the companies that DID do that planning and architecting before did not survive to be complained about.
- CuriouslyC 2y agoIt's not either or. There are best practices that can be followed regardless with no time cost up front, and there is taking some time to think about how your product might evolve (which you really should be doing anyhow) then making choices with your software that don't make the evolution process harder than it needs to be. Layers of abstraction make code harder to reason about and work with, so it's a lose lose when trying to iterate quickly, but there's also the idea of architectural "mise en place" vs "just dump shit where it's most convenient right now and don't worry about later" which will result near immediate productivity losses due to system incoherence and disorganization.
- boxed 2y agoI'm a big fan of "optimize for deletion" (aka leaf-heavy) code. It's good for reasoning when the system is big, and it's good for growing a code base. It's a bit annoying how the design of Django templates works against this by not allowing free functions...