11–20 of 47 posts
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.
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!
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.
This seems kind of obvious though. Larger projects are more in need of the abstractions. You ARE gonna need it.
Earlier quoted context omitted.
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.
The other issue is most engineers want to over-engineer. So anything that encourages that without noting the real costs should probably be tampered down.
My experience is that everyone wants to engineer to their own standards. When it's in a team setting, people with different standards (and tastes) results into "over-engineered" code base.
If the over-engineering is in the wrong dimension (one that the project doesn't need), then the cost will be double: adding the over-engineering and then detangling from it. 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.
The architecture to support something that is not needed tends to introduce rigidity into the codebase, adding a tax to future changes in order to maintain those features.
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…
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 basically pretending to be PHP, but for Perl).
The code makes a query to the database that joins the main `items` table with millions of rows with about 5 other tables. It does complicated locking logic in this query, and if this logic fails, the multiple full-time approvers cannot effectively coordinate their work, and the site cannot make money off new items. The HTML and the code of the loop are interspersed, and there are additional queries issued as you go through the loop. The code outputs JavaScript snippets to the page inside the loop which manipulate data structures incrementally.
> Under engineered code tends to be simple, straightforward work with a low blast radius
Hahahahaha this was a delicate multi-month project to split code and presentation within the existing codebase (outputting a single JSON blob instead of writing out incremental append operations to the page source), installing a separate locking system, performing a zero-downtime cutover to this new locking system, following up with a zero-downtime cutover to a backwards-compatible new subsystem, switching that system over to more-scalable queries — then finally developing a much more ergonomic but less acutely critical new frontend to improve productivity.
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…
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, reschedule for later. Multiple processes, multiple scheduled jobs, on-call alerts, etc, etc. The whole thing could have been replaced with maybe 50 lines of Python. Instead, it was probably around 10k lines of C# and dependency on a 3rd party ETL tool. It was a fucking mess. Worse, yet, I wasn't allowed to fix it.
How to strike a balance between this? The sweet spot is somewhere inbetween.
// TODO: This is the simple version that assumes [our current assumption]
//If you need to handle multiple cases here, I suggest [X strategy].
void doThing()
{
//existing code
}Very few rules are broadly applicable to me as a software engineer on an existing code base:
- achieve the goal with the simplest set of changes possible.
- make your code look like the code around it.
- 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.
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.