4 ms·

I've never seen a PM come to a dev meeting saying "Hey guys, our sales team decided to use the Kubernetes and an elastic search cluster because our clients told

by hsn915 4y ago

I've never seen a PM come to a dev meeting saying "Hey guys, our sales team decided to use the Kubernetes and an elastic search cluster because our clients told us unanimously that the thought of our product running on an advanced container orchestration monstrosity makes them feel really warm and fuzzy." It's usually the developers telling the sales guy "Sorry man we can't deliver this feature on time because our Elastic Search cluster is on Fire All The Time and we need to fix it before we can start adding new features". https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ

whstl 4y ago
Love this, and agree 100%. The crazy thing is that I've seen such a situation of the video happen, but it was with a monolith. "No, a junior can't add a filter to this column because the current system doesn't support filtering aggregates, so we have to partially rewrite it. No, we can't add this directly to the controller or model because there's no controllers or models anymore! Or more like: there's just one! Why? Because we wanted a future-proof system and decided to make a GraphQL simulacrum that allows adding new features without almost no cost! Sure, almost nobody understood it and sometimes it requires rewriting, but who wants to working on a fucking CRUD system?"
- 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 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 ago
      A 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 ago
        If 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).

by hsn915 4y ago

whstl 4y ago

Love this, and agree 100%. The crazy thing is that I've seen such a situation of the video happen, but it was with a monolith. "No, a junior can't add a filter to this column because the current system doesn't support filtering aggregates, so we have to partially rewrite it. No, we can't add this directly to the controller or model because there's no controllers or models anymore! Or more like: there's just one! Why? Because we wanted a future-proof system and decided to make a GraphQL simulacrum that allows adding new features without almost no cost! Sure, almost nobody understood it and sometimes it requires rewriting, but who wants to working on a fucking CRUD system?"

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 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 ago
    A 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 ago
      If 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).