I’ve always wondered how many of our problems with technical debt are self inflicted by trying to design for some future that may never exist. Simple, direct, and declarative code with tests are very maintainable.
... works only in an ideal world where nothing changes, i.e. where software written once is so good that you don't need to touch it.
In reality though, what happens to successful software projects is that once the management and the customers see that it works and is good enough they always, always start to request more features. In fact in the minds of managers adding a feature is just adding a feature, should be easy right? Well no, a lot of the times it's not. Too often adding features affects some core abstractions in the code in such ways known only to the developers that adds technical debt.
"Let's redesign the home feed. Should be easy, right?"
Software just rots like a smashed watermelon in a tropical jungle these days if you aren't actively developing it all the time.
You can't get off the treadmill of updating and paying attention, because if you take your eye off the ball for just a few months, you wake up with outages because some service you depended on has deprecated their API and no longer support the way you were calling it before.
" they always, always start to request more features."
It's not even that they'll request things in the future. There's often a backlog of stuff that will be coming up. I've still had to fight on people pushing back with "quit 'overengineering'! YAGNI! etc" comments.
"Yes, we ARE going to need it. You agreed to it 3 weeks ago in meeting X! Just because it's not in this week's workload doesn't mean it will never happen. We're slated to have to do XYZ in 5 weeks - we understand enough of the problems that will face to be laying some of the groundwork (some extra refactoring/cleanup today in prep for work that will come down the pipeline 5-6 weeks from now)."
But... that will impact the schedule for today so... ignore it.
It's not always so blatant, and current projects don't suffer from this approach nearly as much as some past ones, but it happens.
You have to first identify the percentage of developers that fall into the over-engineer class. 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. These are scary people, because at least the duck-tape ‘just get it done’ people write sloppy but simple code (always needs to be cleaned up, but this is a lower load cognitively than unraveling the mental models of the over-engineers). Both can test one’s patience.
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.
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...
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.
Add to this that many developers/engineering managers are trying to virtue signal to business leaders about priorities. Unless your business leaders grok code development, that translation layer is always rife with grifting aiming to pad resumes and career trajectories over serving the organization's need.
