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

181–190 of 211 posts

Re: Overengineering can kill a product

#181

Post by steve_gh »

darkerside wrote: post #17
a_square_peg wrote: post #15

On the other hand, simplifying an already over-engineered product is almost next to impossible simply because many jobs depend on it. Maybe I'm cynical but I'm beginning to think that software complexity grows until it justifies all the head counts in the department.

This is the same phenomenon as the Peter Principle, where people Rose to the level of their incompetence. It sounds like a joke at first, but, of course they do. People get promoted when they excel. When you are in over your head, you stop getting promoted. Of course, over time, people grow into their roles, and regain their competence. Devs will build software until they can no longer do so because the codebase is l…

It's a well known phenomenon studied in Complexity theory - and it is called "Evolution to the Edge of Chaos"

Re: Overengineering can kill a product

#182

Post by mmcgaha »

satyrnein wrote: post #175
mmcgaha wrote: post #164

Earlier quoted context omitted.

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.

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.

Re: Overengineering can kill a product

#183

Post by DoctorDabadedoo »

activitypea wrote: post #134
DoctorDabadedoo wrote: post #85

Earlier quoted context omitted.

I used to work for a company which the founder (and original engineer) was both very curious about how compilers worked and paranoid about having the company's code base stolen. That came to fruition with the following idea: "if I develop my own language and compiler, even if someone steals part of the code they still won't be able to run without the language specification and compiler!". He designed his own programm…

...Was your boss Rich Hickey?

Clojure's Rich Hickey? No. I'm not too familiar with him or Clojure, but it seems he put a lot more thought on it than the co-founder in my story could ever dream of.

Re: Overengineering can kill a product

#184

Post by nisa »

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…

basically I just looked for an excuse to post the link to the article - which is really a great article and describes the problems inherent to software in an - for me at that time - new and fascinating way.

Of course in practice it's always messy and rightly so, but I've learned the hard way that you better don't loose control about your state and data - because that's where the ugly bugs are.

The article is very good. Just ignore my drivel :)

Re: Overengineering can kill a product

#185

Post by antoniuschan99 »

I found this to be the most important line in the article (author was referring to when Hiring Senior Devs, but it applies to everyone in the firm):

Stick with those who put the user and simplicity ahead of simply technology solutions.

Users are #1. It’s a constant battle between diving into the code/technology and reaching out to users and customers.

Re: Overengineering can kill a product

#186

Post by axiosgunnar »

FpUser wrote: post #98
Griffinsauce wrote: post #59

Earlier quoted context omitted.

> Devs will build software until they can no longer do so because the codebase is larger than their collective abilities to manage. I'm developing a principle of radical simplicity to attempt to combat this: always keep things absolutely as simple as they can be. It is always easy to add complexity later, never to remove it. So the only conscientious choice you can make is to keep things as simple as possible while s…

Ability to keep things "simple" (basically produce code / architecture that is easy to understand) when solving problems in business domains (which usually are very complex in real live) is an art that few can successfully practice.

Exactly. It's actually very very hard to write simple code, no matter the problem at hand. It's easy to write convoluted, complicated code.

Re: Overengineering can kill a product

#187

Post by dehrmann »

what_is_orcas wrote: post #93
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 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…

You've checked-out, so it's too late, but depending on the circumstances, this can be a situation for an experienced engineer to step in. The biggest challenges are political, but also triaging the issues and coming up with a migration plan. "Rewrite all the things" rarely goes well, especially if they already work, just on beefier hardware than is needed.

Re: Overengineering can kill a product

#188

Post by what_is_orcas »

dehrmann wrote: post #187
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…

You've checked-out, so it's too late, but depending on the circumstances, this can be a situation for an experienced engineer to step in. The biggest challenges are political, but also triaging the issues and coming up with a migration plan. "Rewrite all the things" rarely goes well, especially if they already work, just on beefier hardware than is needed.

Yeah, I have no interest in being a "hero" or whatever. If they want a lead, they can hire a lead (I wasn't hired as a lead).

Re: Overengineering can kill a product

#189

Post by d0m3 »

The concept of overengineering is good on paper, but in practice it's being overused and not understood precisely.

I see devs freaking out when you use the word abstraction now...

Suggest extracting business logic from a React component and you don't know anymore if someone is gonna raise the "overengineering" flag.

If you start a new project, do you not use any library or framework at the beginning?

Obviously you take decisions according to how much the project/feature is expected to scale.

If your estimation was too low, you might cripple your development at some point, and need a rewrite or at least some significant refactoring.

If it was too high, I guess you overengineered.

What matters is asking yourself the question, and of course as engineers we like to challenge ourselves into building the best possible solution, but we equally need to consider how likely it is that such a solution is never needed.

Re: Overengineering can kill a product

#190

Post by d0m3 »

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…

Well how do you know something is overengineered? It's when you know it will never (or too far in the future) need to scale accordingly to the engineering.
Post reply on HN