TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

20 pointsby Dobiasdover 3 years ago

13 comments

awkwardover 3 years ago
This is the opposite of my experience.<p>Under engineered code tends to be simple, straightforward work with a low blast radius, such that &quot;make one change and test&quot; covers most cases.<p>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.<p>If I get a task to &quot;make the button blue&quot; I&#x27;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.
评论 #28318178 未加载
评论 #28318249 未加载
评论 #28318523 未加载
评论 #28318510 未加载
评论 #28318605 未加载
评论 #28324202 未加载
评论 #28320012 未加载
albertzeyerover 3 years ago
So this article concludes that starting with a certain project size, over-engineered code is easier to work with than under-engineered code, and scales well when the projects grows (even &quot;linear with the size&quot;).<p>But what this article is actually about is about entanglement of individual parts. Under-engineered implies spaghetti code with lots of entanglement. Over-engineered code does have the minimum needed amount of entanglement.<p>Of course this is right on the topic of entanglement.<p>But this is not so much my understanding of the terms over-engineered vs under-engineered.<p>I understand over-engineered as having too much abstractions. And those can turn out to be the wrong abstractions when they are actually used, which then requires more work to refactor this.<p>I understand under-engineered as having too little abstractions, and having build in some assumptions which might hold for one use case but not anymore for others. This can also require some effort to fix this.<p>In practice, this is also a continuum, and you might even have both things mixed.<p>And when actually writing some new code, it is often hard to know the right amount of complexity.<p>This is why the overall quality greatly improves when you do a couple of iterations of rewrites from scratch. Because you keep improving on just the right needed abstractions.<p>Related:<p><a href="http:&#x2F;&#x2F;number-none.com&#x2F;blow&#x2F;blog&#x2F;programming&#x2F;2014&#x2F;09&#x2F;26&#x2F;carmack-on-inlined-code.html" rel="nofollow">http:&#x2F;&#x2F;number-none.com&#x2F;blow&#x2F;blog&#x2F;programming&#x2F;2014&#x2F;09&#x2F;26&#x2F;carm...</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;Droogans&#x2F;unmaintainable-code" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Droogans&#x2F;unmaintainable-code</a>
ghiculescuover 3 years ago
This 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!
评论 #28318843 未加载
评论 #28317987 未加载
评论 #28318002 未加载
lxeover 3 years ago
Most &quot;over-engineered&quot; code is not like a puzzle. It&#x27;s an ever-growing amorphous pile of playdough. Removing pieces of playdough from the middle of it very difficult.
评论 #28318515 未加载
rblatzover 3 years ago
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.<p>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&#x27;t true, and generally build a Ferrari the business needed was a go-kart.<p>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.<p>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&#x27;t be the default, and it seems like a lot of engineers default to it because it&#x27;s &quot;best practice&quot; or it optimizes for reducing future engineering pain.
nkingsyover 3 years ago
So much of this best practice discussion seems reactionary to me.<p>Very few rules are broadly applicable to me as a software engineer on an existing code base:<p>- achieve the goal with the simplest set of changes possible.<p>- make your code look like the code around it.<p>- information is liability. The less of it moves around, the simpler and safer the code. “DRY” is only useful because it encourages thinking about apis.<p>My only real rule that flows from this is to make sure a code base sets out good standards before making anyone else work on it.
iabacuover 3 years ago
If the over-engineering is in the wrong dimension (one that the project doesn&#x27;t need), then the cost will be double: adding the over-engineering and then detangling from it.<p>The problem is there are too many dimensions a given project can be over-engineered if the future is uncertain. So even an educated guess has a good chance of being wrong.
评论 #28318161 未加载
PeterWhittakerover 3 years ago
This may be slightly off-topic, but it seems to me that sometimes, YAGNI is a judgement made by someone who doesn’t have the same &lt;insert adjective here&gt; grasp of the problem as you do.<p>Most recent case in point: a good friend recently became a work colleague and peer and we work extraordinarily well together, better than any previous working relationship of mine. In addition to the maturity and battle scars that come from ~25 and ~30 years of industry experience, and very different experience, I’d say the biggest reason for this is our very complementary work styles: he is a mix of top-down and bottom-up, write some code knowing it will be replaced later, while I am a come from the side and try to get the whole thing in my head and code incrementally across the whole stack person. (He recently called me lazy, which we both knew was a compliment, but future lazy, in that I will spend more time know to avoid a rewrite later.) We both know the value and cost of technical debt, and are willing to make it good enough for now when needed, leaving comments that link to issues for later, which is good.<p>Anyway, I’ve been the one mostly responsible for the workflow engine, while he has done the DAOs, APIs, and front end components. More than once I’ve added a seeming YAGNI, which we’ve discussed, and which I’ve defended with vague statements and hand waving. (We trust each other enough that we don’t need complete agreement.)<p>More than once I’ve come to a point where I’ve told myself that I really need X only to find that weeks&#x2F;months earlier I added either a comment about X or a doX() stub or even a partial, notional implementation of X.<p>I am very logical and very defensive in my coding, but very intuitive in my understanding of how things hang together. It took me years, perhaps even decades to accept and trust that intuition.<p>Sometimes a YAGNI is just something you know you will need, but cannot yet articulate the why and the how of it.<p>(I have also had more than a few tf was I thinking moments with code that was solid and clean and somewhere between mildly wrong (e.g., edge case mishandled) and near-wholly-borked (as in, I don’t understand how this ever worked, oh, wait it mostly doesn’t and I&#x2F;we got lucky), so it isn’t all smooth and clean.)
FlyingAvatarover 3 years ago
Where this comparison fails for me is that over vs under engineered is not the only dimension that is a factor in maintainability.<p>I have experienced very poorly engineered code (from a best practices standpoint) which easily would be considered over engineered, and very well engineered code (again from a best practices standpoint) which falls squarely in the under engineered bucket.<p>In my experience, the code that most closely follows best practices, be it either over or under engineered, will be easier to correct.
_448over 3 years ago
How to strike a balance between this? The sweet spot is somewhere inbetween.
评论 #28318253 未加载
Fire-Dragon-DoLover 3 years ago
The definition of over engineered and under engineered is so poor that the comparison cannot make any sense.<p>If code has lot of abstractions that are poorly designed, is that over engineered or under engineered? It seems like it should be over engineered but if we analyze it, it means an inexperienced engineer designed the system, or not enough time was provided, which suggests that it was under engineered.<p>Over engineered would be something being way better than the required specs, but all the better parts are unneeded and unused.
Taruchoover 3 years ago
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.<p>In my experience is not so much about under or over engineering but about how the dependencies and the side-effects were handled.<p>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.
jrodthree24over 3 years ago
This seems kind of obvious though. Larger projects are more in need of the abstractions. You ARE gonna need it.
评论 #28318130 未加载
评论 #28317992 未加载