Fixing under-engineered code vs. fixing over-engineered code
1–10 of 47 posts
Re: Fixing under-engineered code vs. fixing over-engineered code
#2Four marines are confirmed KIA. Biden needs to step the fuck down today.
Re: Fixing under-engineered code vs. fixing over-engineered code
#3This misses the point that overengineering takes longer to do, so it adds costs to the initial development process. Unsurprisingly there’s less cost later - you’ve already paid a lot of it!
Re: Fixing under-engineered code vs. fixing over-engineered code
#4This seems kind of obvious though. Larger projects are more in need of the abstractions. You ARE gonna need it.
Re: Fixing under-engineered code vs. fixing over-engineered code
#5How to strike a balance between this? The sweet spot is somewhere inbetween.
Re: Fixing under-engineered code vs. fixing over-engineered code
#6This misses the point that overengineering takes longer to do, so it adds costs to the initial development process. Unsurprisingly there’s less cost later - you’ve already paid a lot of it!
You're absolutely right, of course. :)
While this was not the point of this article, I just added a remark about this important fact nonetheless: https://github.com/Dobiasd/articles/commit/2a251204183cb45e7...
Thanks!
Re: Fixing under-engineered code vs. fixing over-engineered code
#7This seems kind of obvious though. Larger projects are more in need of the abstractions. You ARE gonna need it.
The acronym YAGNI itself is flexible enough to handle this edge case accurately.
The GO4 were truly visionary.
Re: Fixing under-engineered code vs. fixing over-engineered code
#8This misses the point that overengineering takes longer to do, so it adds costs to the initial development process. Unsurprisingly there’s less cost later - you’ve already paid a lot of it!
This pretty much just comes down to estimate how much you're going to need and then go for that in the first place.
Which I imagine is what people would be aiming for anyway? I don't think anyone is using YAGNI knowing they are in fact going to need it.
Re: Fixing under-engineered code vs. fixing over-engineered code
#9This 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 task to "make the button blue" I'd rather do it in a repo where I need to grep around a little than in one where I need to debug which button factory factory library is being pulled in and applied to the parent docker image of the one running.
Re: Fixing under-engineered code vs. fixing over-engineered code
#10Most "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.