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

111–120 of 211 posts

Re: Overengineering can kill a product

#111

Post by guscost »

alex_sf wrote: post #108
what_is_orcas wrote: post #93

Earlier quoted context omitted.

I politely disagree. I'm currently walking away from a code-base (and the company who let it be built) that was obviously built by someone who's mental model of how the code works was incorrect. At some very basic levels, it under-performs compared to literally every other example of this sort of code I've ever seen (and it's extremely common), which results in a subpar user-experience and an EC2 instance way bigger…

Sounds like there are multiple employees. Does the product generate the revenue for their paychecks? If so, it's working correctly.

Love/stealing this, but adapting it to be:

> Does the product generate the revenue for their paychecks, plus extra for the company?

You want to be comfortably generating/contributing more revenue than the expense of employing you.

Re: Overengineering can kill a product

#112

Post by what_is_orcas »

alex_sf wrote: post #108
what_is_orcas wrote: post #93

Earlier quoted context omitted.

I politely disagree. I'm currently walking away from a code-base (and the company who let it be built) that was obviously built by someone who's mental model of how the code works was incorrect. At some very basic levels, it under-performs compared to literally every other example of this sort of code I've ever seen (and it's extremely common), which results in a subpar user-experience and an EC2 instance way bigger…

Sounds like there are multiple employees. Does the product generate the revenue for their paychecks? If so, it's working correctly.

I appreciate this sentiment until I am assigned to maintain and add features to this product.

Re: Overengineering can kill a product

#113

Post by marcosdumay »

abraxas wrote: post #44
yosito wrote: post #32

Six months ago I left a company that was working on an overengineered product. Even worse than it being overengineered was that it was also under documented. Working on anything was a pain, because the CTO wanted everything to follow his well thought out, and frankly very cleverly engineered design patterns, but he couldn't clearly communicate what those patterns were. And the entire company amounted to transforming…

Being ins a similar role myself, how do I ensure that engineers stay happy working on the project that we're working on? I'm finding myself actually doing the opposite of the CTO you mentioned and pushing them towards adopting more off-the-shelf components instead of maintaining homegrown stuff but I think I'm causing a degree of upheaval by doing this. Their justifications for push back however, often smell of sunke…

> and pushing them towards adopting more off-the-shelf components instead of maintaining homegrown stuff

Are you spending your time second-guessing the developers and micro-managing them on the exact thing they are supposed to be experts?

Your phrasing has that "feel", but it's far from a sure conclusion. Anyway, if it is the case, you may need to reevaluate both your hiring (should you get more senior people?) and management (this is a clear "should never be done", unless your people are explicitly under training) practices.

Re: Overengineering can kill a product

#114

Post by am391 »

what_is_orcas wrote: post #100
im_down_w_otp wrote: post #95

Earlier quoted context omitted.

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

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…

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.

Re: Overengineering can kill a product

#115

Post by hinkley »

mgkimsal wrote: post #80
noisy_boy wrote: post #73

Earlier quoted context omitted.

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…

Occasionally, it is because of that though. If not 'stupid', at least inexperienced. I've had plenty of things I've done that worked, but were, in hindsight, 'stupid' (and have been called out on that). Sometimes, people try to make a lot of post-hoc justifications for a block of code or a data/tech decision that really is, just... 'stupid'. Again, that's more likely down to inexperience than anything else, but not e…

> Can't be true - the person who wrote it is a DBA

Not for long…

Re: Overengineering can kill a product

#116

Post by baby »

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…

I interpret “early over engineering” not as adding complexity necessarily. It could also be about decreasing complexity but by taking too much time. Early on you’re supposed to rush to your MVP and add tech debt, not spend too much time to design something pretty and modular. Later on once you know your company can survive multiple quarters, then you can spend more time refactoring.

Re: Overengineering can kill a product

#117

Post by baby »

rytcio wrote: post #104
jasfi wrote: post #8

Earlier quoted context omitted.

I agree, complexity is the real underlying problem. That is why good frameworks and libraries help so much.

Frameworks and libraries are the cause of complexity, imo

It depends, there’s a trade off. At some point things can become very complicated if you don’t abstract them and put them in their own lib or framework.

Re: Overengineering can kill a product

#118

Post by justin_oaks »

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 I've heard it is is "Evolution, not revolution".

You evolve your code with refactoring and rewriting only pieces at a time. This is opposed to revolution, also known as "the big rewrite", which replaces the entire application all at once.

Your "modular enough systems" seems to indicate that you also favor evolution over revolution.

Re: Overengineering can kill a product

#119

Post by mgkimsal »

hinkley wrote: post #115
mgkimsal wrote: post #80

Earlier quoted context omitted.

Occasionally, it is because of that though. If not 'stupid', at least inexperienced. I've had plenty of things I've done that worked, but were, in hindsight, 'stupid' (and have been called out on that). Sometimes, people try to make a lot of post-hoc justifications for a block of code or a data/tech decision that really is, just... 'stupid'. Again, that's more likely down to inexperience than anything else, but not e…

> Can't be true - the person who wrote it is a DBA Not for long…

heh... well... he was a DBA, and wrote all the application code as well. testing on localhost with 20 sample users, what could possibly go wrong? :)

Re: Overengineering can kill a product

#120

Post by activitypea »

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…

In my experience, the situation you're describing more often results in "sloppy" code -- it seems convoluted, non-obvious, poorly thought out until you realize when the pivots happened. Overengineered code usually looks neat at first glance, maybe even impressive, especially to non-technical stakeholders. Then when you actually dive into it, you notice a bunch of wrong abstractions that introduce layers of indirection without offering any sort of valuable flexibility. "This metaclass that implements a context manager could've just been a slightly longer than average function" type stuff.

A codebase that pivoted multiple times makes more sense the more time you spend in it, an overengineered one makes less.

Post reply on HN