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

91–100 of 211 posts

Re: Overengineering can kill a product

#91

Post by throwaway2331 »

mindvirus wrote: post #52
abraxas wrote: post #44

Earlier quoted context omitted.

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…

I think the best thing you can do as a CTO is define the problems/goals and desired outcomes very clearly. Think of possible solutions if you can but don't share them, and give your team the problem to solve. And let them stumble a bit, because in the level of buy in and growth you'll get is more than worth it - it'll be their solution after all.

Literally the only two things leadership should do to be above the mean:

1. Clearly define a vision for the future/ goal(s) that should be achieved

2. Get out of the fucking way of your minions, and trust that you hired correctly, to let them figure out how to get to the finish line

Bonus Points:

3. Your temperament is in the Goldilocks' zone of neither being too much of a spendthrift, nor too much of a miser, when setting budgets, i.e. you're not some rando without P&L experience that was tied to your bonuses.

Re: Overengineering can kill a product

#92

Post by am391 »

The issue here isn't so much over or under-engineering, but rather "Are we building the right thing?" or "Are we building the thing right?"

In a startup you don't know if you're building the right thing so trying to build it right is premature optimization. Since you have limited resources you really have to focus on ensuring that you're building the right thing...if you aren't it doesn't matter how well designed or built it is no one is going to use it.

Once you've validated you're building the right thing you can start focusing on building it right, but by they you probably know where the pain points are and where you need to spend the effort.

The trick with this though is that everyone needs to be aligned on that approach and be honest about the fact that corners may be being cut to get something working fast. Where I've seen this go badly is where a crappy initial version was built to get to market fast, but then no time was made available to address the defencies in the initial release.

Re: Overengineering can kill a product

#93

Post by what_is_orcas »

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 than necessary to run this sort of code. A lot of code running doesn't need to run in the first place, and due to the incorrect mental model, there's a substantial amount of code that doesn't run.

Nobody really understands how bad it is, though, because it's barely tested (and the engineer who wrote most of the code has argued that we don't need tests, for various reasons) and all of the engineers on the team who didn't build it initially, have told me that they're not familiar enough with how this sort of product should work to understand that it doesn't work like that (again, this is a super common kind of product).

There's a lot of other anti-patterns (I started keeping a list in my first week) but I think these are the most damning. This code is in production. Nobody at the org brought up these issues earlier in development (like saying "hey, nobody else's product does [annoying thing that doesn't need to happen], why does ours?"), which leads me to believe that the whole technical org is at fault.

It sucks and I can't wait to be done with this experience.

Re: Overengineering can kill a product

#95

Post by im_down_w_otp »

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…

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

Re: Overengineering can kill a product

#96

Post by claytonjy »

cfn wrote: post #79
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,…

I suspect that the main issue with rewrites is that the users or product managers see it as an oportunity to add new features or redo old ones extensively. In the end the scope of the rewrite is no longer a rewrite but a new product that is incompatible with the original it was supposed to replace. I have seen this happen a couple of times. A straight rewrite for technical reasons and well defined scope does not suff…

This is a great point, and my successful rewrites have done the opposite, reducing scope/capabilities. "We changed other systems and no longer need to handle x/y/z in this service", especially when most x/y/z's are edge cases now eliminated.

Re: Overengineering can kill a product

#97

Post by convolvatron »

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?

quite a bit. under engineered as in 'never really tested, is known in general not to work'. usually, yes in theory it should be easy to fix - but since the parent organization doesn't value getting a handle on what's really going on, it never does.

Re: Overengineering can kill a product

#98

Post by FpUser »

Griffinsauce wrote: post #59
darkerside wrote: post #17

Earlier quoted context omitted.

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…

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

Re: Overengineering can kill a product

#99

Post by dbg31415 »

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 your product.

Having a bad marketing plan can kill your product.

Not having enough staff can kill your product.

Not having enough funding can kill your product.

Technical debt of all kind can kill your product.

Bad data schemas can kill your product.

Under-engineering can kill your product.

Over-engineering can kill your product.

...

This is in no way a complete list, but from my experience the items on this list are ordered with the ones most likely to kill your product put at the top.

Re: Overengineering can kill a product

#100

Post by what_is_orcas »

im_down_w_otp wrote: post #95
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…

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 mental-model and the working-model. It just so happens that I've worked on this sort of thing before (as have thousands of others) that I was pretty quickly able to understand where the original developer went wrong (trust me, I'm just an ordinary developer, not a 10x elite hacker or anything).
Post reply on HN