121–130 of 201 posts
I believe there are some antipatterns like singletons and globals that on the surface look grug-brained but are actually complexity multipliers.
Earlier quoted context omitted.
I wouldn't call those "smart people". They're not much beyond mediocre, but see overcomplicating things (which in many cases they will dogmatically explain away as being a "best practice") as a way to make it appear like they're smart. The smartest are those who can make complex problems look simple, with simple solutions.
And they're never really appreciated, since those problems end up looking so simple in hindsight
OK, this was better than expected.
I love the section on tests. It really is exactly what I've come to learn over the years. Integration tests are the sweet spot for finding bugs. Mocks tend to over complicate things (I still use them sometimes but I avoid using them systematically) and unit tests are too brittle in face of refactoring whereas integration tests help with refactoring.
The worst sort of tests are integration tests which secretly depend on another integration test having run first, which will be true 99% of the time, until a change you make changes the order.
Earlier quoted context omitted.
In my experience most over-engineering can be explained by a lack of understanding. When we design it, we don't know what matters and our guesses are wrong; and when we modify it later, we don't have time to figure out how it really works. Both of those problems can be fixed by simply spending more time to understand, but time is money.
Not a lack of understanding, a misalignment of values. I had a team once implement the MediatR pattern for a When I asked them to remove it, it became a political fight that went to the VP because they were convinced that sort of flexibility was a good idea. Fast forward a year and they have a new technical leader and he thought I wanted that complexity until we had a conversation and when I mentioned I didn't like i…
Believing flexibility is needed still suggests a lack of understanding.
Earlier quoted context omitted.
There’s 2 reasons that can happen. 1. It’s not actually overcomplicated, but the people saying it is haven’t thought about it hard enough to realize this. 2. It is overcomplicated, but it’s such a tangle of complexity that fixing it would require the people pointing out the problems to basically do it over from scratch. #2 is usually the result of a very experienced developer being overwhelmed by the amount of comple…
There’s also a third reason: a form of anti-intellectualism where you think that designs that are hard to derive are intrinsically more complex than just doing the straightforwardly obvious thing.
Earlier quoted context omitted.
> The developer's incentive to maximize their own lock-in factor and billable hours are powerful forces. In my experience these are rarely, if ever, the reasons for over engineering.
My hobby projects are always over-engineered despite my best efforts. There's absolutely no monetary incentives here so anecdotally I agree with you.
It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
Earlier quoted context omitted.
Not a lack of understanding, a misalignment of values. I had a team once implement the MediatR pattern for a When I asked them to remove it, it became a political fight that went to the VP because they were convinced that sort of flexibility was a good idea. Fast forward a year and they have a new technical leader and he thought I wanted that complexity until we had a conversation and when I mentioned I didn't like i…
> they were convinced that sort of flexibility was a good idea. Believing flexibility is needed still suggests a lack of understanding.
This leads to a certain kind of decoupling, although with a higher tolerance for coupling that can kept in check by static analysis.