12 ms·

I think this is normally due to bad requirements or bad architecture. If a legitimate feature is complex there's very little you can do. Apart from push back o

I think this is normally due to bad requirements or bad architecture. If a legitimate feature is complex there's very little you can do. Apart from push back on the implementation specifics. Quite often, code is too complicated due to it needing to interact with other problematic code. So you could spend many times longer fixing all the underlying complexity and hopefully make it better. Or just accept that it's not perfect, which while regrettably is the pragmatic choice (Until things get so bad it isn't)

goalieca 4y ago
For things where software is replacing an office worker, the design of the task is something that happens years before it is ever put into software.
- BlueTemplar 4y ago
  That doesn't make sense though, because software has very different qualities from human beings : it's (typically) both much dumber and much faster. So the design itself needs to be questioned.
rightbyte 4y ago
> I think this is normally due to bad requirements or bad architecture. Trying to make a "good" architecture when there are no sane way to do it in a good way is one of the deepest sins in my experience. What a messy out of necessity implementation needs is seldom another layer of abstraction to mess with your head.
- rapnie 4y ago
  Scott Wlaschin mentioned this nicely (I think in "Domain models made Functional"). Paraphrasing: "You can have all the nicest tools and greatest libraries and frameworks and coding skills.. if garbage goes in, then garbage comes out".
- sebastialonso 4y ago
  That's precisely why we should stop thinking about "good" architecture. At the very best, we'll find the least worse architecture, and that's that. But realistically, just a handful of the real world scenarios we all face fall into this category of "least worse arch is black magic". I'd bet my house than 90% of the architectural problems we faced exist because of a poor process on understanding requirements or poor architectural design. In no small amount due to hese two things being very hard.
HPsquared 4y ago
Overcomplication can be contagious and spread from one area to another.

goalieca 4y ago

For things where software is replacing an office worker, the design of the task is something that happens years before it is ever put into software.

BlueTemplar 4y ago
That doesn't make sense though, because software has very different qualities from human beings : it's (typically) both much dumber and much faster. So the design itself needs to be questioned.

rightbyte 4y ago

> I think this is normally due to bad requirements or bad architecture. Trying to make a "good" architecture when there are no sane way to do it in a good way is one of the deepest sins in my experience. What a messy out of necessity implementation needs is seldom another layer of abstraction to mess with your head.

rapnie 4y ago
Scott Wlaschin mentioned this nicely (I think in "Domain models made Functional"). Paraphrasing: "You can have all the nicest tools and greatest libraries and frameworks and coding skills.. if garbage goes in, then garbage comes out".
sebastialonso 4y ago
That's precisely why we should stop thinking about "good" architecture. At the very best, we'll find the least worse architecture, and that's that. But realistically, just a handful of the real world scenarios we all face fall into this category of "least worse arch is black magic". I'd bet my house than 90% of the architectural problems we faced exist because of a poor process on understanding requirements or poor architectural design. In no small amount due to hese two things being very hard.

HPsquared 4y ago

Overcomplication can be contagious and spread from one area to another.