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

Fixing under-engineered code vs. fixing over-engineered code

github.com

Post reply on HN
Print view View original

21–30 of 47 posts

Re: Fixing under-engineered code vs. fixing over-engineered code

#21

Post by [deleted] »

hermitdev wrote: post #17
awkward wrote: post #9

This is the opposite of my experience. Under engineered code tends to be simple, straightforward work with a low blast radius, such that "make one change and test" covers most cases. Over engineered code tends to be more convoluted, with more fan in, more fan out and a large dependency graph. Changes become more like high pressure bomb squad work, where cutting the wrong wire blows up the whole project. If I get a ta…

Your experience largely mirrors my own. At a previous employer, I had to make some changes to a process that was importing data from a vendor. Typical straight-forward ETL, right? Not even a lot of data, like 20-30 records daily. The process? Load the data from CSV to JSON, ship the JSON off to Azure. Pull the data back from Azure, check to see if it's been processed, apply the change on premise. If failed, reschedul…

[deleted]

Re: Fixing under-engineered code vs. fixing over-engineered code

#23

Post by rblatz »

This seems to miss the point, engineers need to communicate with business stakeholders to understand the business needs and where they are in product development. Then adjust your engineering efforts based on that.

The worst case is you delay learnings by over engineering a product, make things more complicated, bake in a lot of rules and assumptions that aren't true, and generally build a Ferrari the business needed was a go-kart.

Engineers tend to optimize for the engineering experience and miss the broader business experience. I love it when I have to go back and clean up technical debt that we leveraged to move faster, learn quickly, and find product market fit. That is a high class problem. I also love it when we have to scrap under-engineered products we built, because we learned a lot and need to change directions. What I hate is when we have to scrap an over built system that was costly to build, took a long time, and I burnt a lot of political capital to build.

If you are in a mature product, and the business is confident in the direction, absolutely spend the time to build out and think through all the abstractions and really build an enterprise grade solution. But that shouldn't be the default, and it seems like a lot of engineers default to it because it's "best practice" or it optimizes for reducing future engineering pain.

Re: Fixing under-engineered code vs. fixing over-engineered code

#25

Post by merrywhether »

xnx wrote: post #19
the_sleaze9 wrote: post #7

Earlier quoted context omitted.

The acronym YAGNI itself is flexible enough to handle this edge case accurately. The GO4 were truly visionary.

GO4?

“Gang of Four”, the name commonly applied to the authors of the seminal book “Design Patterns”

https://en.m.wikipedia.org/wiki/Design_Patterns

Re: Fixing under-engineered code vs. fixing over-engineered code

#26

Post by LeifCarrotson »

awkward wrote: post #9

This is the opposite of my experience. Under engineered code tends to be simple, straightforward work with a low blast radius, such that "make one change and test" covers most cases. Over engineered code tends to be more convoluted, with more fan in, more fan out and a large dependency graph. Changes become more like high pressure bomb squad work, where cutting the wrong wire blows up the whole project. If I get a ta…

Over-engineered code has a lot of coupling where incidental equivalence may have been misapplied as fundamental sameness. This was discussed here on one of my favorite PLC programming blogs:

https://www.contactandcoil.com/automation/industrial-automat...

Copy and paste are great tools. Making all 6 buttons in a particular grid with the code:

    grid.AddNewButton(1, 1, "Thing 1", Color.White, Color.Black, onClick1());
    grid.AddNewButton(1, 2, "Thing 2", Color.White, Color.Black, onClick2());
    grid.AddNewButton(1, 3, "Thing 3", Color.White, Color.Black, onClick3());
    grid.AddNewButton(2, 1, "Thing 4", Color.White, Color.Black, onClick4());
    grid.AddNewButton(2, 2, "Thing 5", Color.White, Color.Black, onClick5());
    grid.AddNewButton(2, 3, "Thing 6", Color.White, Color.Black, onClick6());
keeps this incidental sameness in mind. Just looking at the above code causes programmers everywhere (myself included) to imagine ways in which the above could be done with a `for` loop, computing the row and column numbers from the index, using string concatenation for the labels, creating an array of onClick handlers and indexing into it... But that forces fundamental sameness where there may not be any; a little repetition doesn't hurt.

Re: Fixing under-engineered code vs. fixing over-engineered code

#27

Post by AlexCoventry »

lxe wrote: post #10

Most "over-engineered" code is not like a puzzle. It's an ever-growing amorphous pile of playdough. Removing pieces of playdough from the middle of it very difficult.

The OP seems to be assuming the abstractions in the over-engineered code are all clean. If that's the case, the abstractions really can be like partially-solved portions of a jigsaw puzzle. It's a common, flawed conceit that you can get design clean abstractions up-front with pure engineering discipline/process, though.

Re: Fixing under-engineered code vs. fixing over-engineered code

#28

Post by michaelcampbell »

awkward wrote: post #9

This is the opposite of my experience. Under engineered code tends to be simple, straightforward work with a low blast radius, such that "make one change and test" covers most cases. Over engineered code tends to be more convoluted, with more fan in, more fan out and a large dependency graph. Changes become more like high pressure bomb squad work, where cutting the wrong wire blows up the whole project. If I get a ta…

Your experience agrees with mine. It may be TEDIOUS, but it's generally easier to fix underengineering which (IMO) tends to be wide but not deep issues.

Overengineering has its hooks everywhere; even WITH tests, changing something changes everything.

I've come to realize that at least for the level of engineering I'm exposed to that boilerplate is not always bad, copy/paste is perfectly valid to a point (which for me is usually "2-3"), and DRY is a tool, not a design goal.

Re: Fixing under-engineered code vs. fixing over-engineered code

#29

Post by rblatz »

fennecfoxen wrote: post #16
awkward wrote: post #9

This is the opposite of my experience. Under engineered code tends to be simple, straightforward work with a low blast radius, such that "make one change and test" covers most cases. Over engineered code tends to be more convoluted, with more fan in, more fan out and a large dependency graph. Changes become more like high pressure bomb squad work, where cutting the wrong wire blows up the whole project. If I get a ta…

If we're sharing experience with underengineered code, let me have a go. At $BUSINESS we have a very successful marketplace that brings together buyers and sellers! We've recently IPOd. We get a lot of new items in and we have an internal page which is used by multiple full-time employees to approve new items, maintaining quality and defeating spammers. The code is written in HTML::Mason templates in Perl (which is b…

That feels like a really high class problem to have. You have a product that got you to IPO, and it hit the end of its lifespan and needed to be upgraded/rebuilt.

Re: Fixing under-engineered code vs. fixing over-engineered code

#30

Post by Tarucho »

This article assumes the overengineered abstractions make sense, as if they were all part of the same puzzle. Sometimes the code is just an abstract mess.

In my experience is not so much about under or over engineering but about how the dependencies and the side-effects were handled.

Given the choice of working on 1 of 2 code bases that solve the same problem I will choose the one where the dependencies and the side-effects are more up front.

Post reply on HN