Overengineering can kill a product • Hacker News Board

Re: Overengineering can kill a product

#141

Post by [deleted] » Wed, Nov 24, 2021, 4:44 PM UTC

noisy_boy wrote: post #73

somehnacct3757 wrote: post #60

I don't think you can diagnose over-engineering after the fact. Unless you were in the room, or have access to written specs from a meticulously documented team, you don't understand the conditions under which the code was written. Maybe the company was betting at the time on an integrations marketplace, or a lot of partnerships, so a robust integration platform was built. Then the company moved on to another bet aft…

My new colleague used to wonder about certain things i.e. why is this is done this way, it doesn't make any sense. As I had been there a lot longer, I would share the technical and non-technical background/restrictions we operated with. Eventually when another new colleague joined, he told the guy, "I used to wonder why some parts of the code are setup that way; now that I have the background I can say that if you ar…

[deleted]

Re: Overengineering can kill a product

#142

Post by redler » Wed, Nov 24, 2021, 4:44 PM UTC

noisy_boy wrote: post #73

somehnacct3757 wrote: post #60

I don't think you can diagnose over-engineering after the fact. Unless you were in the room, or have access to written specs from a meticulously documented team, you don't understand the conditions under which the code was written. Maybe the company was betting at the time on an integrations marketplace, or a lot of partnerships, so a robust integration platform was built. Then the company moved on to another bet aft…

My new colleague used to wonder about certain things i.e. why is this is done this way, it doesn't make any sense. As I had been there a lot longer, I would share the technical and non-technical background/restrictions we operated with. Eventually when another new colleague joined, he told the guy, "I used to wonder why some parts of the code are setup that way; now that I have the background I can say that if you ar…

The ever-relevant Chesterton’s Fence.

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Re: Overengineering can kill a product

#143

Post by alex_sf » Wed, Nov 24, 2021, 4:48 PM UTC

what_is_orcas wrote: post #140

alex_sf wrote: post #135

Earlier quoted context omitted.

> All it takes is a good enough sales and marketing team, or the right executive relationships, especially if the team being “supported” is small. That's the point though. Getting caught up in engineering purity or even whether it's objectively _good_ is a waste. The product exists to drive business (financial) metrics. If it's doing that, it's working.

The one thing that I'd challenge about this line of thought is that the product isn't necessarily "done", there are expectations to add features & fix bugs. If the product is poorly crafted, and especially if it's also poorly tested, adding features can introduce bugs, and fixing bugs in one place can cause issues elsewhere. Development then slows to handle these occurrences, which can then impact product viability.

I'm aware of technical debt and it's consequences. The point is that the vast majority of developers treat their job as creating good software, when it's absolutely not.

Re: Overengineering can kill a product

#144

Post by HEmanZ » Wed, Nov 24, 2021, 4:48 PM UTC

"Stop overengineering" was the excuse I heard back on a rough project when I insisted we add logging beyond just the returned HTTP status code to our service before shipping to 200M+ people. But that would take an extra week or two in the current system and that's just too much investment for some silly over engineering.

Had we gotten decent logging in place early, we could have saved a terrible change that got passed our canary rings, which got us called to see the CEO and made news.

So, I learned early that "overengineering" can also be a management excuse for cutting corners that shouldn't be cut.

Re: Overengineering can kill a product

#145

Post by blindmute » Wed, Nov 24, 2021, 4:51 PM UTC

jcun4128 wrote: post #2

I'm wondering about this now I guess it is old fashioned now to use environment variables and bare EC2 servers, managing your own APIs and websockets/DB on same server as opposed to breaking everything out. You need to use cloud formation and "oh did you know there is an AWS service for that?" Then you are using 5 services instead of 2. This twelve factor app concept. Don't know when is the right time to do this/at w…

My last startup was spending stupid money on AWS services and horizontal scaling for an app which had, when I left, about 100 users and maybe 2 concurrent at a given time. And they had been doing this since before I joined when the numbers were much lower. The complexity was idiotic and no one but the devops guy who set it up could grok it. We still managed to have frequent downtime

Re: Overengineering can kill a product

#146

Post by aranchelk » Wed, Nov 24, 2021, 4:54 PM UTC

gampleman wrote: post #66

One thing that bugs me is the notion that "Software rewrites are something you should never do", which is a mantra so often repeated that it has acquired the status of self-evident truth, despite the only evidence being (usually) presented is an example of a web browser from 20 years ago! (Which incidentally spawned Mozilla, so not exactly a complete loss; especially from the POV of society rather than shareholders,…

The way it was once told to me:

Old developers have left. New ones come in. The systems the old devs built suck, so the new team convinces management to do a rewrite. The new devs don’t really understand the problems encountered by the old ones so they repeat all the same mistakes. New system, same problems.

The lesson we’re supposed to take away “no one should ever do full rewrites”. It’s a stretch, but IMO the proper takeaway should be 1) really understand the old system and 2) have a very good reason before doing full rewrites.

Re: Overengineering can kill a product

#147

Post by m3kw9 » Wed, Nov 24, 2021, 4:58 PM UTC

Over engineering also have a way to burn people out when a very vocal engineer say it is imperative that this and that should be scalable and secure. It delays actionable areas before people even want to hack you or use you

Re: Overengineering can kill a product

#148

Post by btilly » Wed, Nov 24, 2021, 5:00 PM UTC

somehnacct3757 wrote: post #60

I don't think you can diagnose over-engineering after the fact. Unless you were in the room, or have access to written specs from a meticulously documented team, you don't understand the conditions under which the code was written. Maybe the company was betting at the time on an integrations marketplace, or a lot of partnerships, so a robust integration platform was built. Then the company moved on to another bet aft…

I don't think you can diagnose over-engineering after the fact. Unless you were in the room, or have access to written specs from a meticulously documented team, you don't understand the conditions under which the code was written.

Can you prove it in a court of law? No. But you still can often easily diagnose it. And you'll usually be correct.

For example the conditions under which https://wiki.c2.com/?SecondSystemEffect happens are well-known, and the pattern has been repeated often in the half-century since it was named. If it is a second system, and you can find complicating abstractions in it that get used exactly once in practice, then with better than 90% odds it was over-engineered. And the farther you dig, the stronger the evidence will become.

Re: Overengineering can kill a product

#149

Post by vanusa » Wed, Nov 24, 2021, 5:05 PM UTC

throw10920 wrote: post #125

nisa wrote: post #3

Complexity kills your product - Overengineering is just one instance of complexity - Technical Debt like having state and data all over the place is another one - I quit my last job and I happily blame this article for convincing me to quit: https://itnext.io/the-origin-of-complexity-8ecb39130fc - coordination causes complexity and this killed me - we had everything not once but twice or more in different places - ju…

> Complexity kills your product This is like saying that water is lethal - both are true in the sense that some x (water, complexity) is ok, but too much is bad. Complexity is an unfortunate (but necessary) side-effect of (1) adding features and (2) optimizing for performance, both of which are critical for building a product. If you try to remove all complexity from your product, you won't have a product. Instead, y…

The basic point is that the default tendency in many environments is to run toward ever-increasing levels complexity -- often without even being aware that this is happening -- rather than be (as I believe one should be) by default always skeptical of added complexity.

If you try to remove all complexity from your product,

This wasn't what the commenter was advocating, of course.

Rather it was an attempt to simplify the basic message of: "Complexity has attendant risks which are too easily ignored -- and which in short enough order, can kill hour product."

Re: Overengineering can kill a product

#150

Post by dominotw » Wed, Nov 24, 2021, 5:09 PM UTC

Overengineers will find an edgecase or an hypothetical future scenario to justify their overengineering.

unless there is an org level commitment to not using "what if in future" type scenarios, overengineers will win everytime.