Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

newsletter.beginner.dev

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#31

Post by gonzo41 »

orblivion wrote: post #17
xnx wrote: post #8

Newbie devs think under-engineering is a problem. Experienced devs know over-engineering is a problem.

A half-baked thought: It's interesting though isn't it, that the "immature" approach is to try to be extra vigilant. You'd think an immature coder would just want to hammer things out quickly. I wonder if it's because they learned that lesson at some point (maybe in college) and are overcompensating, trying to be extra mature or something.

I think the immature approach is to try and solve all problems, rather than just addressing the needs of the moment. Whilst it looks and sounds bad, delivering quickly and ontime creates the opportunity to fix things. Trying to deliver perfect products, ie finding and fixing all faults steals future time.

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#32

Post by tivert »

mattbuilds wrote: post #5

I really disagree with the pros listed on over-engineering, specifically "future-proofing" and "reusability". I doubt you can accurately predict the future and whatever assumptions you make will likely be wrong in some way. Then you are stuck having to solve the problem that you created by trying to predict. As for reusabilty, it's similar. Start with solving what you have to, then abstract as you see it fit. Again,…

> I doubt you can accurately predict the future and whatever assumptions you make will likely be wrong in some way. Then you are stuck having to solve the problem that you created by trying to predict. As for reusabilty, it's similar. Start with solving what you have to, then abstract as you see it fit.

Kinda sorta. It's not a binary: you can "predict the future," just not too far out and not with complete certainty. The art is figuring out what the practical limits are, and not going past them.

> Realistically you should engineer for the problem you have or can reasonably expect you are going to have pretty soon. You can solve future problems in the future.

Another factor is comprehensibility. Sometimes it makes sense to solve problems you don't technically have, because solving them makes the thing complete (or a better approximation thereof) and therefore easier to reason about later.

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#33

Post by bluGill »

mattbuilds wrote: post #5

I really disagree with the pros listed on over-engineering, specifically "future-proofing" and "reusability". I doubt you can accurately predict the future and whatever assumptions you make will likely be wrong in some way. Then you are stuck having to solve the problem that you created by trying to predict. As for reusabilty, it's similar. Start with solving what you have to, then abstract as you see it fit. Again,…

> I doubt you can accurately predict the future and whatever assumptions you make will likely be wrong in some way.

I doubt this for most of us. Computers have been around for a long time. Most of us are not work on new problems. We by now have a pretty good idea of what will be needed and what won't be. There are a lot of things left that haven't been done yet, but if you understand the problem at all you should have a good idea of what those things will be. You won't be 100% correct of course, and exactly when any particular thing you design for will actually get implemented is unknown, but you should already have a good idea of what things your users will want on a high enough level.

Of course if we ever get something new you will be wrong. 10 years ago I had no idea that LLM type AI would affect my program, but it is now foreseeable even though I don't really know what it can do will turn out useful vs what will just be a passing fad. Science fiction has 3d displays, holographic interfaces, teleportation, and lots of other interesting things ideas that may or may not work out.

Likewise, 20 years ago you could be forgiven for not foreseeing the effects that privacy legislation would have on your app, but you better assume it will exist now and the laws will change.

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#35

Post by arp242 »

bpicolo wrote: post #19
mattbuilds wrote: post #5

I really disagree with the pros listed on over-engineering, specifically "future-proofing" and "reusability". I doubt you can accurately predict the future and whatever assumptions you make will likely be wrong in some way. Then you are stuck having to solve the problem that you created by trying to predict. As for reusabilty, it's similar. Start with solving what you have to, then abstract as you see it fit. Again,…

Agreed. These feel backwards. When I think "Under engineer", I think "keep it simple, because you can't predict the future". Simplicity is a great enabler of flexibility and tends to go hand in hand with scalability.

It's usually comparatively easy to make something that's too simple a bit more complex.

It's often much harder to make something that's too complex more simple.

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#36

Post by alternatex »

jj-natik7 wrote: post #27

My rule of thumb, design for what you know is a requirement, account for what has an 80% chance of being a requirement (as in, already in the backlog), and ignore the rest. That said, GraphQL is a great way to hedge your bets and make your future as well as current self do less work.

GraphQL is also a great way to create maintenance and performance problems for your future self. There's no silver bullet. Future problems are better solved by developers living in the future.

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#37

Post by angarg12 »

mattbuilds wrote: post #5

I really disagree with the pros listed on over-engineering, specifically "future-proofing" and "reusability". I doubt you can accurately predict the future and whatever assumptions you make will likely be wrong in some way. Then you are stuck having to solve the problem that you created by trying to predict. As for reusabilty, it's similar. Start with solving what you have to, then abstract as you see it fit. Again,…

I think this is nicely captured by the concept of "cost of carrying".

Keeping code around is not free. Cost of carrying refers to the ongoing efforts of maintaining code, not to mention side effects such as increased complexity and cognitive load.

If you over-engineer a system you aren't getting value out of the extra bits, but you are still paying the cost of keeping them around.

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#38

Post by dwallin »

icedchai wrote: post #29
rqtwteye wrote: post #14

Earlier quoted context omitted.

Don't forget that under-engineered things can also be very complicated. "Under-engineered" doesn't mean "simple"

There is a balance. I've seen plenty of under-engineered software with the same code copy-and-paste dozens of times. I've also seen incredibly complex abstraction layers that only made sense to their original authors (long gone...) and were incredibly hard to navigate and maintain (class hierarchies 5 layers deep, etc.)

It's worth noting that oftentimes a complex abstraction layer can be a sign that they were building upon an under-engineered base. A corollary to Hanlon's Razor could be:

"Never attribute to over-engineering that which is adequately explained by repeated under-engineering."

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#39

Post by bsaul »

There's a middleground that many developers have trouble finding :

You can design your code so that it'll be easier to evolve into the most likely path. However, you don't actually implement the future cases.

Example: it doesn't take a lot more effort to create a configuration struct instead of hardcoding a value. However, you don't want to implement handling of any other values that the one you planned on using. You can easily throw a "value not supported" error if the configuration has anything else.

However, this will greatly help any newcomer on the codebase to understand what possibilities your component potentially offers and how it can evolve.

Re: Striking the Right Balance: Over-Engineering vs. Under-Engineering Software

#40

Post by arp242 »

nikodunk wrote: post #34

Does this appear to anyone else as the exact style, length and depth of a ChatGPT text?

Just badly written blogspam with little interesting to say beyond extremely superficial takes that are so superficial it's just wrong (for the general case).
Post reply on HN