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

131–140 of 211 posts

Re: Overengineering can kill a product

#131

Post by crispyambulance »

crate_barre wrote: post #25
crispyambulance wrote: post #21

Earlier quoted context omitted.

I share this sentiment BUT... It's also important to try stuff out, fail, recover, and try again. That "Code Complexity vs. Experience" graph in the article is not completely a joke. Very few people can tunnel through the complexity hump without years of failures and successes behind them. Moreover, you might not have a choice. You might find yourself dropped into an obstacle course of complexity that other people cr…

My message was mostly for those that hide behind mistakes via an appeal to authority. Trying new things is a risk, which is fine, but to own the the success of the risk means you must also pay the collateral of owning the failure. The message is for those who don’t put up the collateral and hide behind ‘this is what everyone(the pros /sarcasm) is doing’ or ‘this is how it’s done’, and never reflect objectively. No on…

Yep, also on a Titanic myself, rearranging the deck chairs (because I have to!).

Re: Overengineering can kill a product

#132

Post by DoctorDabadedoo »

jamil7 wrote: post #107
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…

That was a fun read, you should write this up in a blog post :)

I plan to do it, eventually, thank you for the encouragement :)

Re: Overengineering can kill a product

#133

Post by [deleted] »

DoctorDabadedoo wrote: post #85
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…

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…

[deleted]

Re: Overengineering can kill a product

#134

Post by activitypea »

DoctorDabadedoo wrote: post #85
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…

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?

Re: Overengineering can kill a product

#135

Post by alex_sf »

svnt wrote: post #123
alex_sf wrote: post #108

Earlier quoted context omitted.

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

I understand the sentiment but there are so many situations where this is not true. All it takes is a good enough sales and marketing team, or the right executive relationships, especially if the team being “supported” is small. You can say the company or division is presently functioning, but the time constant on the product is different, and the coupling is too loose to say anything else with accuracy.

> All it takes is a good enough sales and marketing team, or the right executive relationships, especially if the team being “supported” is small.

That's the point though. Getting caught up in engineering purity or even whether it's objectively _good_ is a waste. The product exists to drive business (financial) metrics. If it's doing that, it's working.

Re: Overengineering can kill a product

#136

Post by zackmorris »

Engineering within the wrong paradigm can kill your product.

I see far more problems on a day-to-day basis with patterns and anti-patterns taken too far. For example, I never use the factory pattern, because it leads one down the Java road where everything ends up an object with mutable state. Which isn't scalable over some metric (like a million lines of code) because a human brain can't trace execution, even with a debugger. A far better pattern generally is to take a functional approach of accepting data, swizzling it, and returning the resulting data without mutability or side effects.

Another really bad pattern is when execution suspends and resumes somewhere else (goto hell). Any project which uses queuing, eventual consistency, promises, nonblocking streams, even basic notifications or things as complex as monads will encounter this nondeterminism and inability to statically analyze code. Note that pretty much all web development suffers from some aspect of this due to its async and multi-signaling nature.

So what I do now, which I don't see much these days, is solve problems abstractly in a spreadsheet (pure functional programming), in the shell (the Actor model) or as a flowchart (declarative and data-driven design), and then translate that to whatever crappy language/framework I have to use for the project. I find that today, roughly 90% of developer effort goes to discovery, refactoring and testing of ill-conceived code. Only 10% is "actual work" and that's probably a stretch.

Which is incredibly heartbreaking for me to see, since I grew up on software like HyperCard, FileMaker and Microsoft Access which solved much of this in the 1980s and 90s in a no-code fashion. One of the very first "languages" I used was a visual programming environment called Visual Interactive Programming (VIP) for the Macintosh by Mainstay, which unfortunately today I can find almost nothing about, to show what an impact it had on computer science hah: https://duckduckgo.com/?q=Visual+Interactive+Programming+VIP...

With mainstream languages and frameworks like Node.js and React, and their predecessors like Ruby on Rails and Angular, I just keep thinking to myself "never have I seen so much code do so little". It's all overengineered man!

Some better alternatives to the status quo:

Simple Made Easy: https://www.youtube.com/watch?v=LKtk3HCgTa8

Object-Oriented Programming is Bad: https://www.youtube.com/watch?v=QM1iUe6IofM

Re: Overengineering can kill a product

#137

Post by selcuka »

mumblemumble wrote: post #76
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…

It's a question of framing. Nothing is ever over- or under-engineered. It's over- or under-engineered for a purpose. What that distinction recognizes is that it's possible for something to have been well-engineered at one time, while still being over-engineered today. Header files in C and C++ are an example of this phenomenon. They solved a very real problem with technical constraints from 40, 50 years ago, both in…

Agreed, but "nothing is ever over- or under-engineered" is a bit too bold. There is definitely over engineering just for the sake of over engineering, and under engineering caused by incompetency.

Re: Overengineering can kill a product

#138

Post by wheelerof4te »

baby wrote: post #122
wheelerof4te wrote: post #87

I often find myself prefering languages with few abstractions even when some more complex language might be "better". Reason is that with "bare" languages like C, you can choose your own design more freely. Case in point: Serenity OS. Author of that OS replicated entire libc and still refuses to use C++'s STL. He created his own abstractions that he feels confident using. That is true engineering.

You should check golang, it’s much more safe than C and has very few ways of doing the same thing. It makes every codebase look like simple code. It’s always a pleasure to read or refactor. That’s the only language that managed to do that imo.

I tried Golang while I was experimenting on Linux. Fun little language, but I haven't got used to it's type notation.

What is the state of Golang's Windows support?

Re: Overengineering can kill a product

#139

Post by lonelyasacloud »

Fwiw, my experience is that generally a lot of blame for over engineeering tends to be lumped on engineering when in reality its usually a wider business failure.

Every competent engineers I have met has been capable of grasping that: - They shouldn't rely on the use of crystal balls. - Complexity should be minimised. - If it can be done today, it can be done tomorrow.

So if a business provides its engineers with: - A process that helps them develop an intuitive understanding of their customers' needs. - At least one other similarly capable person to work with so they know they're not the only person going to be looking after the project off into the future. - A procurement process for off-the-shelf solutions that is less painful for them than rolling their own. - Time to test and document where projects should go if the initial version is successful. - And crucially, confidence that they'll be given enough time to do the additional work if it becomes necessary.

Then the business, at least in my experience, will be in a pretty good position to prevent almost all over engineering.

Re: Overengineering can kill a product

#140

Post by what_is_orcas »

alex_sf wrote: post #135
svnt wrote: post #123

Earlier quoted context omitted.

I understand the sentiment but there are so many situations where this is not true. All it takes is a good enough sales and marketing team, or the right executive relationships, especially if the team being “supported” is small. You can say the company or division is presently functioning, but the time constant on the product is different, and the coupling is too loose to say anything else with accuracy.

> All it takes is a good enough sales and marketing team, or the right executive relationships, especially if the team being “supported” is small. That's the point though. Getting caught up in engineering purity or even whether it's objectively _good_ is a waste. The product exists to drive business (financial) metrics. If it's doing that, it's working.

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.

Post reply on HN