4 ms·
I’ve once worked on a system where everything was abstracted. Literally everything. You were basically not allowed to use any libraries. They had an ORM, but yo
by andix 4y ago
I’ve once worked on a system where everything was abstracted. Literally everything. You were basically not allowed to use any libraries. They had an ORM, but you could only use it via their wrapper („so it can be switched at a later point“). A lot of things were impossible with this wrapper, or just broken. You could file a ticket, but the library was just updated twice a year.
You could not make sophisticated HTTP-requests, because you had to use the in-house library. And off course it had much less functionality than some commonly used libraries.
So what I learned from that: abstractions can be nice, but they are useless if you can’t escape them. They must have „escape routes“ everywhere, to do things that are not covered by the abstractions.
- whstl 4y agoI 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).