Re:The True Meaning of Technical Debt (2020)
by harryf on Tuesday April 13, 2021 @09:33AM
(#26791899)
Great extension to the analogy! In my experience over-engineering class are the most damaging of all and I feel like the article and general discussion of technical debt largely ignores this.
I'd also add two subsets of the over-engineers. One subset are those that create frameworks to solve problems vs. address the problem directly. The other are those that introduce (language / datastore / build tool / etc.)-of-the-week to a codebase in an ad-hoc manner. And I'll admit, I've been both of those once upon a time...
Re:The True Meaning of Technical Debt (2020)
by nicoburns on Tuesday April 13, 2021 @09:28AM
(#26791847)
> If it’s 30%, then it’s possible 30% of your team will over-abstract, and if you make them a principal, they will over engineer most of the codebase.
Isn't the idea to make a non-over-abstracting engineer the principal, and then they will bring everyone else into line with code review, etc.
Re:The True Meaning of Technical Debt (2020)
by runawaybottle on Tuesday April 13, 2021 @10:27AM
(#26792580)
Business usually values speed. If you over engineer or just duck tape everything, so long as you are fast about it, you’ll be on the short list to be a principal.
Wrong values propel them to the top.
To keep running with the analogy, the sloppy developers will just take a credit card and max it out. The over-engineers will do credit default swaps on mortgage backed securities and tie up the whole economy.