[what_is_orcas]

I don't disagree, but I think that the reason that this fits here is because the poorly engineered software is unnecessarily complex (not in the "someday we might need this" way, but in ways that I'm having a hard time articulating without giving away the product because I know my coworkers are on HN). In fact, it was the ridiculous complexity that drove me to discover the disparities between the original developer's mental-model and the working-model. It just so happens that I've worked on this sort of thing before (as have thousands of others) that I was pretty quickly able to understand where the original developer went wrong (trust me, I'm just an ordinary developer, not a 10x elite hacker or anything).

[lumost]

Typically over-engineered software looks something like the following.

1) The product is horizontally scalable to 3 orders of magnitude more traffic than the product will ever receive.

2) Bespoke assembler/hand crafted memory management/other do not touch code to shave 5ms off a 5 ms call on an API that isn't latency sensitive.

3) Ability to handle N customer tenants while only handling 1 customer 3 years later.

4) multi-region redundant deployment for 1 customer strictly based out of the US with no availability requirements.

5) 100% coverage for integration tests, unit tests, CI/CD, for a single tenant blog that is never updated and no one reads.

6) Custom internal framework with micro-service splits to support team of 100 engineers working on app when there are 2.

7) Automated continuously trained ML ranking model which performs .001% better than sorting by popularity or other trivial heuristic on a social media app with 10 users.

The common theme in many of these cases is that these are pretty good ideas if you have unlimited people, but have fairly low impact. In some cases these may be counter-productive to successful delivery at the company/product level. A piece of software built wrongly due to poor understanding of the product domain is often considered under-engineering.

[_drimzy]

+1. An over-engineered software is a bazooka when you need a hand-gun, not a malfunctioning handgun!

[danielmarkbruce]

Isn't the common theme: "this is what big tech does" ? Ie, it seems a lot of small companies/startups look at "best practices" and just copy them. It's not just engineering. It happens in product, hiring, marketing, everything.

It's completely wrong given the context 99% of companies are operating in. It's no wonder a Zuckerberg can come along and build a crazy successful company in his early 20s. He likely didn't know any "best practices". Common sense was enough.

[dfsegoat]

> Isn't the common theme: "this is what big tech does" ?

In my org, we love to call this out with an (often private) "We need to do it because Google Does it!" -comment.

[marcosdumay]

You see, overengineering is exclusively of the "some day we might need this" kind of complexity. Anything else is a different problem, very likely with very different causes, even if the consequences are similar, so it's not useful to analyze together.

[what_is_orcas]

There is also some of this.

Some of it makes sense when the reasons were explained (e.g. "we figured this would make it easier for [business unit] to do [thing] which turned out not to be something [business unit] actually has interest in doing").

Other examples are purely of this sort (e.g. "we'll be glad we have this in place when we finally hit [x] users or enter [market]").

[mmcgaha]

Feature wise, when the business asks for it, it is not over engineering, but when the dev team tries to out think the business team then it is.

Design wise, I know it when I see it but other people may see different things.

[satyrnein]

Interesting angle. What if the business asked for it, the dev team delivered it, but the business subsequently gave up on it, and now it's overengineered in comparison to what remains in use. To avoid this scenario, I don't try to outthink the business team, but I do push people toward temporary manual workflows sometimes, and promise to automate later if the idea actually pans out.

[mmcgaha]

Yes the business team will often ask for things they don't need but I can justify that cost. It can still impede other development but we tackle that when it becomes a problem not before.

I agree completely on pushing off features that are not core because it is better to learn in production than to daydream in meetings. I would say most phase-2 features never get implemented.

[am391]

I feel your pain :)

Complexity kills projects and the will to work on them. It can be caused by either over or under-engineering. With the first you end up with extraneous layers of abstraction and badly applied design patterns that make it hard to understand or reason about the code...in the second you end up with a big ball of mud that's impossible to understand or tease apart.

In both cases the code gets harder and harder to change to the point that no one really knows how it works or wants to risk touching it.