Live data from Hacker News

Overengineering can kill a product

mindtheproduct.com

191–200 of 211 posts

Re: Overengineering can kill a product

#191

So many things can kill your product. And I agree that having an engineering-led product can be especially prone to the dangers of over-engineering... but... Not having users / customers can kill your product. Not building the right features can kill your product. Not doing enough testing can kill your product. Doing too much testing can kill your product. Having toxic / inexperienced / unmotivated staff can kill you…

dont forget BigCo noticing you have an interesting idea and yanking the rug out from under you.

Re: Overengineering can kill a product

#192

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?

In the world of hardware, which I realize is a parallel universe to the one in this thread where "product" apparently means "app", the answers are "all the time" and "no", respectively.

If someone didn't take the time to do actual "engineering" - which is to say, using mathematics to formalize design requirements (again, possibly a foreign concept to the app-building class) and just YOLOed the design based on intuition, you can end up with something so fundamentally broken in concept that "fixing" it requires a bottom-up redesign starting from fundamentals. A child's drawing of an airplane is not progress towards a blueprint of one!

Re: Overengineering can kill a product

#193
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…

Great article, thanks for sharing. I like the vocabulary explanations and the chart that summarizes all. Will share and read again!

Re: Overengineering can kill a product

#194
I own an ecommerce company, and I'm using a huge (>$100M funding raised) company that's supposed to be a tech-enabled 3PL.

It was a terrible choice, and their idiotically overengineered solutions are a big reason why.

The most egregious one is that instead of weighing packages to find out their weight, they have an algorithm that estimates the weight. My packages are designed to come in at just under a pound (it's a big cutoff for shipping prices). Needless to say, slight problems with their algorithm can and do lead them to overbill me.

A ton of work when they could just use a scale to do the job much, much better (and I'm sure save time overall with all the refunds of overbilling factored in).

Re: Overengineering can kill a product

#195
post #149

Earlier quoted context omitted.

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

your product

Re: Overengineering can kill a product

#197

I think there's a very specific form of overengineering afflicting products currently, which I'd classify as "endless revisiting". This is where companies build something which works well enough, but then get trapped in a cycle of endlessly tweaking that one thing. Inevitably the amount of code churn in this one area combined with the need for some semblance of backward compatibility results in something that is frag…

Yeah, I see this happening a lot as well. A prime example is Spotify. Their app is done. It has all the features it needs. Instead of just focusing on making those features work more reliably, they seem intent on doing a big UI redesign every few months, adding bloat to the app and making it more frustrating to use. It’s really rare to find companies that just build a thing and stop adding features once the core func…

I'm amazed how every version has been worse than the one before. The best version was out over a decade ago.

Re: Overengineering can kill a product

#198
post #171

Earlier quoted context omitted.

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?

Symbolic imports.

Basically, the way every programming language newer than C++ or Objective-C does it.

Re: Overengineering can kill a product

#199
post #83

Earlier quoted context omitted.

I think the lesson here is that with great product market fit everything is under engineered, with poor product market fit everything is over engineered. Statistically you are more likely to be building an over engineered product with poor product market fit than you are to be building an under engineered product with great market fit. Now is over or under engineering a bad thing? that depends on how many resources t…

+1 to less better built features. What I primarily see kill products is going after too many features and they all suck. Often when you do one thing really well you may find there is more value in the primitives

Or going after too many users. The 'next billion' mindset is misguided.
Post reply on HN