Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Overengineering can kill a product

mindtheproduct.com

Post reply on HN
Print view View original

171–180 of 211 posts

Re: Overengineering can kill a product

#171

Post by blt »

mumblemumble wrote: post #76
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…

It's a question of framing. Nothing is ever over- or under-engineered. It's over- or under-engineered for a purpose. What that distinction recognizes is that it's possible for something to have been well-engineered at one time, while still being over-engineered today. Header files in C and C++ are an example of this phenomenon. They solved a very real problem with technical constraints from 40, 50 years ago, both in…

What is the less-engineered alternative to header files?

Re: Overengineering can kill a product

#172

Post by Jensson »

jugg1es wrote: post #162

I never understand why people criticize using interfaces for most functionality. How else do you write effective unit tests? Interfaces with dependency injection make unit tests far easier to write. Smartly designed interfaces also make code easier to read and understand. Lastly, adding new interfaces is trivially easy, so why not?

Yeah.

Similarly, walls of text are bad.

I use line breaks after every sentence to fix that.

I see no reason why not.

This way you can clearly tell apart sentences.

Adding new lines doesn't require any more time than just writing a space.

So why not just do it always?

By following this rule I never wrote a wall of text again!

Re: Overengineering can kill a product

#174

Post by oriolid »

kwertyoowiyop wrote: post #45
scottious wrote: post #27

The insidious thing about over engineering is that it's usually committed by very experienced engineers. Experienced engineers rarely under-engineer, that tends to be fixed very early in one's career. As we get more competent and read more books, we have the tendency to get enamored by new fancy abstractions. We get too clever and then we get in our own way. Best real-world example: I inherited a project that was an…

When is the last time anyone ever saw a project that was “under-engineered”? And aren’t those projects easier to fix…because they are so simple?

Over the last years I've been working with an audio library that makes several simplifying assumptions, like

- Audio interfaces are never added or removed over the app's lifetime

- Audio is never rerouted between interfaces, or at least the app doesn't need to know about it

- The details of an audio interface, like number of channels or supported sample rates, do not change while the interface is running

- Audio latency never changes and callback timing is always precise, so timestamps are not really needed and a single number is enough

Of course, none of these are really true and adding support for some of them would require rewriting a few APIs and many, many implementations. On the overengineering side, of course it has its own smart pointers, string class, thread implementation etc just in case someone needs to build for a target that doesn't support C++11.

Re: Overengineering can kill a product

#175

Post by satyrnein »

mmcgaha wrote: post #164
what_is_orcas wrote: post #129

Earlier quoted context omitted.

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]").

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.

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.

Re: Overengineering can kill a product

#176

Post by danielmarkbruce »

lumost wrote: post #105
what_is_orcas wrote: post #100

Earlier quoted context omitted.

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…

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) m…

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.

Re: Overengineering can kill a product

#177

Post by Groxx »

hef19898 wrote: post #152
im_down_w_otp wrote: post #95

Earlier quoted context omitted.

That doesn't sound like over-engineering. That sounds like bad-engineering.

Over engineering is a form of bad engineering, at least in my book. Fun starts when some parts of a product are over engineered while others are under engineered... One of the cases good averages get you nowhere...

I think nearly everyone would agree that "over == bad" in most settings, but the reverse is being implied by the GP - that bad engineering is a form of over engineering.

No tests? Nobody knows how it works? It doesn't perform well and doesn't fit the problem it's solving? That's very much not over engineered in my book.

Re: Overengineering can kill a product

#178

Post by engineeringwoke »

_drimzy wrote: post #166
engineeringwoke wrote: post #161

Earlier quoted context omitted.

A product manager's decisions go unchecked most of the time because engineers and responsibility for business concerns are like oil and water. That's why PM exists, no? If engineers could just talk to marketing, sales, etc. then there wouldn't be a need for them, but alas, that is not the case.

No one is denying the need for PMs. OP is pointing out that PMs have too much decision making power, with too little accountability in most organizations. Your argument is akin to, "PMs can't code, so alas we need engineers, and that's why shitty engineering exists, and there is no way to make it better"! Nope! We need product practices, akin to engineering practices, with 360° feedback and analysis, and the product…

Right. And I'm saying that is because engineers don't want the responsibility that they often request because the entire point of PM's existence is offloading that responsibility. They seem more than happy to complain about it though

Re: Overengineering can kill a product

#179

Post by davewritescode »

that_guy_iain wrote: post #169
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,…

> despite the only evidence being (usually) presented is an example of a web browser from 20 years ago! Actually normally the evidence is lots of other companies that failed to do rewrites. It's just that one was a full scale fuck up. I'm currently working at a company that literally it's echoing Netscape. The issue wasn't the rewrite it was rushing a half finished rewrite out the door. It was stopping product develo…

> I would say that the trick is not to do the rewrite. You refactor each part until the entire system is rewritten.

This is exactly the right way to approach this. The best way I’ve seen to rewrite a complex system is to literally work off a branch and deploy it in QA beside the old version. The hardest part is figuring out the right way you want to direct traffic to the “new version”.

My team inherited a massive system that was the key revenue generator for a multi billion dollar company. It was an operational nightmare from deployments to stability. It had at least 1 24 hour outage that was nearly impossible to root cause.

We slowly chipped away at it for 8 months running in parallel in QA until we were satisfied that it was functionally equivalent. Started running traffic in prod while we tuned it to start taking real traffic and had the whole thing replaced in 18 months.

The system was replaced, is handling 2X the load in prod of the old system and hasn’t had an outage years

Re: Overengineering can kill a product

#180

Post by radley »

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…

> Everything was built to spec.

First line in the second paragraph of every dead company's obituary.

Post reply on HN