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…
Fixing under-engineered code vs. fixing over-engineered code
41–47 of 47 posts
Re: Fixing under-engineered code vs. fixing over-engineered code
#42If 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.
Over engineered would be something being way better than the required specs, but all the better parts are unneeded and unused.
Re: Fixing under-engineered code vs. fixing over-engineered code
#43This 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 means that is better than the specifications, however such things being over specifications happen to be useless or unused. Then time and money was wasted, but the product is not worse by any mean.
Re: Fixing under-engineered code vs. fixing over-engineered code
#44Earlier quoted context omitted.
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…
This reminds me a colleague creating a Python class like this import os class Bla(): def __init__(self): self.var1 = os.env["VARIABLE1"] self.var2 = os.env["VARIABLE2"] # ... self.varN = os.env["VARIABLEN"] def get_variables(self): return self.var1, self.var2, ..., self.varN They took 2 months to write an insanely complcated code to just copy few objects from an S3 bucket to another... And because the Lambda was timi…
Often however that is a far larger/difficult task and it is easier and better for ones sanity to just fix the things that affect you directly.
Re: Fixing under-engineered code vs. fixing over-engineered code
#45This 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…
Under-engineered code can easily become over-engineered code, while retaining the appearance of being the former, as engineers keep working on it over time. It only becomes easier over time, as bugs are uncovered by users and then "fixed", as features are requested by users and then bolted on, and so on.
> 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 ...
In the kinds of codebases I'm talking about, you will successfully end up making the button blue, but then, either:
1. sth else breaks and you wouldn't know about it until later; and/or
2. a bunch of seemingly unrelated tests break and you will need to debug which button provider is auto-injected into which tests' setup routines.
Re: Fixing under-engineered code vs. fixing over-engineered code
#46Most 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.
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.)
More than once I’ve come to a point where I’ve told myself that I really need X only to find that weeks/months earlier I added either a comment about X or a doX() stub or even a partial, notional implementation of X.
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.
Sometimes a YAGNI is just something you know you will need, but cannot yet articulate the why and the how of it.
(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/we got lucky), so it isn’t all smooth and clean.)
Re: Fixing under-engineered code vs. fixing over-engineered code
#47I 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.
In my experience, the code that most closely follows best practices, be it either over or under engineered, will be easier to correct.