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

151–160 of 211 posts

Re: Overengineering can kill a product

#151

Post by what_is_orcas »

mberning wrote: post #62

In the enterprise I see this all the time. Step one of the project is lets look at kubernetes or whatever is hot lately. Even for something stupid with 10k users max. What they actually need is a 30 line terraform script and a preconfigured AMI.

Ha ha.

This is why I used to throw things into simple kubernetes setups (that I just ran the same terraform scripts to create) and just tell the management "yeah, now it's ready for all of your features".

I argued for a while, then realized I didn't have to.

Re: Overengineering can kill a product

#152

Post by hef19898 »

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.

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

Re: Overengineering can kill a product

#153

Post by SkyPuncher »

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…

> 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 after only writing one or two integrations on the new platform. Nobody over-engineered here. Everything was built to spec.

I would argue this is a case of over-engineering. Though, it extends beyond pure engineering.

This is poor resource management and business de-risking. An effective approach here would have been: "Let's build out a handful of integrations. Make sure they're going to deliver the value we want. Then abstract it into a repeatable pattern".

Re: Overengineering can kill a product

#154

Post by throwawayboise »

dbg31415 wrote: post #99

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…

Most products/startups fail. This is part of the reason why. But all of this is survivable if you have customers and revenue. That needs to always be the primary focus.

Re: Overengineering can kill a product

#155

Post by noisy_boy »

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…

> 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 every decision is a 'good' one just because people 'had their reasons'.

I agree on the point regarding the decision being 'stupid' but in this case it was not because of inexperience. On the contrary, it was because an overruling decision by an experienced manager. So the point is that it is not always technical or due to inexperience (though that does happen) - from what I've seen, it is quite common for such things to happen due to hierarchical/ego/political issues as well.

Re: Overengineering can kill a product

#156

Post by _drimzy »

These are just fantastical musings of a product manager, who is pretty far from engineering, and thinks that their products fail because of engineers, not because they didn't get their product right, and/or think that every engineer who doesn't produce a fully functional Facebook with news feed and friends, in 39 days is overengineering their product and are far removed from users!

Re: Overengineering can kill a product

#157

Post by beachy »

SkyPuncher wrote: post #153
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…

> 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 after only writing one or two integrations on the new platform. Nobody over-engineered here. Everything was built to spec. I would argue this is a case of over-engineering. Though, it extends beyond pure engineering. This is poor res…

I've been in exactly this position, in fact I conceived and created the situation at my last company. I found it uncanny how on point OP was.

The trouble with "Let's build out a handful of integrations. Make sure they're going to deliver the value we want. Then abstract it into a repeatable pattern" is that when you're building an integration marketplace, you need partners, and they don't want to be your research bitches.

They just want to build their integrations once, and gtfo. If they think you're signing then up for a revolving wheel of experimentation, they'll just politely stay away until someone else has done the hard yards.

Sure if you're a Microsoft or a Google you'll have any number of willing partners who will put up with anything to be the pioneers in your integrations marketplace.

But otherwise, they're using your integrations marketplace purely for the benefits, and they don't want to be building on sand.

Re: Overengineering can kill a product

#158

Post by engineeringwoke »

_drimzy wrote: post #156

These are just fantastical musings of a product manager, who is pretty far from engineering, and thinks that their products fail because of engineers, not because they didn't get their product right, and/or think that every engineer who doesn't produce a fully functional Facebook with news feed and friends, in 39 days is overengineering their product and are far removed from users!

and then your product manager smiles during the meeting when you say this, and then bursts out laughing when the call is over

Re: Overengineering can kill a product

#159

Post by _drimzy »

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…

+1. An over-engineered software is a bazooka when you need a hand-gun, not a malfunctioning handgun!

Re: Overengineering can kill a product

#160

Post by mgkimsal »

noisy_boy wrote: post #155
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…

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

you're not wrong, but there's a whole class of problems that occur outside 'enterprise' structures. Often it's just a lone cowboy building something for a small business, and the business owner have absolutely no way to determine if what's being delivered is 'good' in any meaningful sense.
Post reply on HN