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

201–210 of 211 posts

Re: Overengineering can kill a product

#201

Post by titzer »

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…

> I'm currently walking away from a code-base

> and the engineer who wrote most of the code has argued that we don't need tests, for various reasons

Sounds like you made the right choice to walk away. "My code doesn't need tests" smacks of match-over-the-shoulder type of chaos creation. This person has likely never had to maintain their own code or someone else's, nor has anyone ever had to maintain their code. 0/5 would not work with.

Tests are wonderful. Tests are proof your code works. They are something to be proud of. And they defend your code against the chaos monkey of future people refactoring and rearranging.

Re: Overengineering can kill a product

#202

Post by dfsegoat »

danielmarkbruce wrote: post #176
lumost wrote: post #105

Earlier quoted context omitted.

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…

Isn't the common theme: "this is what big tech does" ? Ie, it seems a lot of small companies/startups look at "best practices" and just copy them. It's not just engineering. It happens in product, hiring, marketing, everything. It's completely wrong given the context 99% of companies are operating in. It's no wonder a Zuckerberg can come along and build a crazy successful company in his early 20s. He likely didn't kn…

> Isn't the common theme: "this is what big tech does" ?

In my org, we love to call this out with an (often private) "We need to do it because Google Does it!" -comment.

Re: Overengineering can kill a product

#203

Post by _drimzy »

engineeringwoke wrote: post #178
_drimzy wrote: post #166

Earlier quoted context omitted.

No one is denying the need for PMs. OP is pointing out that PMs have too much decision making power, with too little accountability in most organizations. Your argument is akin to, "PMs can't code, so alas we need engineers, and that's why shitty engineering exists, and there is no way to make it better"! Nope! We need product practices, akin to engineering practices, with 360° feedback and analysis, and the product…

Right. And I'm saying that is because engineers don't want the responsibility that they often request because the entire point of PM's existence is offloading that responsibility. They seem more than happy to complain about it though

This is still missing the point. The way to improve PM accountability isn't engineers fixing them. It's the organization's and leadership responsibility to ensure PMs are held accountable.

Engineers would be far happier if they don't have to do good engineering and can do away with shitty software without accountability. But there are checks and balances to improve engineering quality, and those aren't created by PMs. It's the engineering org that champions good engineering practices and accountability and post mortems. Same should be done in PM organizations.

Re: Overengineering can kill a product

#204

Post by amznbyebyebye »

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…

What product ?

Re: Overengineering can kill a product

#205

Post by randomswede »

alex_sf wrote: post #143
what_is_orcas wrote: post #140

Earlier quoted context omitted.

The one thing that I'd challenge about this line of thought is that the product isn't necessarily "done", there are expectations to add features & fix bugs. If the product is poorly crafted, and especially if it's also poorly tested, adding features can introduce bugs, and fixing bugs in one place can cause issues elsewhere. Development then slows to handle these occurrences, which can then impact product viability.

I'm aware of technical debt and it's consequences. The point is that the vast majority of developers treat their job as creating good software, when it's absolutely not.

I'd say it's creating software that is "good enough" (good enough to do what it needs to, right now, sufficiently frequently that paying customers return).

Re: Overengineering can kill a product

#206

Post by jspash »

spaceywilly wrote: post #170
MattKimber wrote: post #28

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…

See also: Dropbox, 1Password, Gmail.

The list goes on.

Re: Overengineering can kill a product

#207

Post by drewcoo »

> overengineering has killed more products than the absence of good development practices

But as the author defines overengineering, it is clearly not a good development practice.

Further, there is no evidence provided to support the claim.

Maybe a truer lesson is that the authors work suffers under too much scrutiny. We're all better off imagining a similar thesis and then imagining it is actually true.

Re: Overengineering can kill a product

#208

Post by toopok4k3 »

jasfi wrote: post #8
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 agree, complexity is the real underlying problem. That is why good frameworks and libraries help so much.

The less you use external dependencies, more time for you to focus on your own product instead of solving problems updating those dependencies and replacing them.

Re: Overengineering can kill a product

#209

Post by wheelerof4te »

jugg1es wrote: post #162

I never understand why people criticize using interfaces for most functionality. How else do you write effective unit tests? Interfaces with dependency injection make unit tests far easier to write. Smartly designed interfaces also make code easier to read and understand. Lastly, adding new interfaces is trivially easy, so why not?

What is an Interface? What is a dependency injection? How can you explain them to someone who never needed to use them?

Do I need unit tests when my code is dead simple, or written in Rust? Etc...

Re: Overengineering can kill a product

#210

Post by a_square_peg »

steve_gh wrote: post #181
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…

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

This is both interesting and disheartening - the evolution would concern itself more with the software organization then the product (hence the product death).
Post reply on HN