4 ms·
I feel your pain, but the problem is that these "escape routes" are leaky abstractions. They're the worst of both worlds. You still have the bad architecture su
by whstl 4y ago
I feel your pain, but the problem is that these "escape routes" are leaky abstractions. They're the worst of both worlds. You still have the bad architecture surrounding the whole thing, but also a lot of parallel stuff going around. Sure, they're great for getting things done in the short term, but after one year of everybody cutting corners, you have a big ball of mud.
There's unfortunately no known way to make good software other than keeping it simple, concise and without too many components.
- andix 4y agoA big working ball of mud is still better than a big ball of gold, that doesn’t do what it is supposed to do. The thing you can do to prevent it: continuous refactoring. It’s better to ship features on time and clean up afterwards, than cleaning up a lot before and never ship things.
- whstl 4y agoIf you start with a simple ball of mud, sure. But a rigid architecture that's also a ball of mud is harder to refactor, and things also don't get done. As I said, using escape routes for some time, for speed, is acceptable. The problem is making this into a rule. Refactoring a bad abstraction is easier than refactoring an abstraction that is messy and bad. So either refactor sooner (and create proper abstractions) or skip the “ball of gold” altogether (eg: use the original framework directly).