The only fix is quality forward thinking details oriented leadership.
Given that corporate America has decided that all employees are meant to be replaceable and therefore transient, it is not rational for any individual to orient themselves to the long term or make near term concessions. Likewise if employee compensation is a function of hours worked more than it is a function of the company's success, it is irrational for an employee to make decisions with respect to the long term, especially if they will be rewarded for speed over complexity tradeoffs and they can leave the company with a great resume when the debt becomes overwhelming.
Admiral Rickover's speech Doing a Job speaks quite a bit to technical debt and the forces that promote it: https://govleaders.org/rickover.htm
> The manager, of course, remains ultimately responsible and must accept the blame if subordinates make mistakes.
> Complex jobs cannot be accomplished effectively with transients. Therefore, a manager must make the work challenging and rewarding so that his people will remain with the organization for many years.
> The ideas I have mentioned are not new—previous generations recognized the value of hard work, attention to detail, personal responsibility, and determination.
Engineering is not a new discipline. Software engineering is, but humans have thousands of years of prior art, and it is being actively ignored by today's tech industry. I was privileged to work for a 100-year-old engineering company. It had a lot of frustrations, but they made damn good hardware. I learned a great deal from them (and also banged my head bloody, trying to get them to let me deal with software differently from hardware).
I think that this should be on a billboard on I-280S:
> ... when the details are ignored, the project fails. No infusion of policy or lofty ideals can then correct the situation.
They treated software in exactly the same manner as hardware: measure twice/cut once, waterfall. All QC was after the fact, and done manually.
We did a great job of delivering yesterday's technology, tomorrow.
I wanted them to add flexibility. Things like a different QC system, iterative development, and faster releases of software.
I won't get into details, though. Much as I wasn't happy with things, I had (still have) tremendous respect for the company, and wish them nothing but good luck (they'll need it).
I will say this, though:
I worked with some of the top engineers and scientists in the world. The company had been producing precision optical equipment for 100 years, and people paid a lot of money for it.
It was extremely hard to suggest that they might want to consider doing stuff differently. They had a formula that worked quite well, and not changing on a whim was a big part of that. I think most folks, hereabouts, would go nuts, working that way, but you can't argue with the results.
I learned to write software of a pretty high Quality, as a direct result of working with these folks.
I violently agree with this comment, but don’t believe the will exists to put people in a position of power or leadership in today’s corporations to set this culture at the top (which is needed to attract, retain, and cultivate talent who grows with the org and cares about their work and its contribution to the org’s success). Short term thinking will reign until forced out at great cost (Boeing, for example).
I agree. Moreover plenty of jobs where they measure just the time to completion. Even small code fix ups as you go will be treated like an afternoon slacking off on Reddit and punishment or firing accordingly. At most places of work.
Another good fix is legacy companies getting replaced by newer, more nimble companies.
It's good for the economy for new startups to tackle old problems in new and novel ways, throwing out decades of legacy cruft and ossification.
It also puts more comp into the hands of the founders and frontier employees that pave the way rather than funneling it to institutional shareholders of an old business - pension funds, etc.
Sure, but for companies that fail their code ceases to be run by them. If their code is used by other groups then they will have to deal with maintenance themselves, if that's even possible.
This risk is somewhat mitigated by demanding only open source software be used. At least then if a software's supplier goes bankrupt then updated versions can still be produced. That's not the case with closed source software.
> This risk is somewhat mitigated by demanding only open source software be used. At least then if a software's supplier goes bankrupt then updated versions can still be produced. That's not the case with closed source software.
If your solution starts with "for this to work all software used will have to be open source" you have a completely nom-solution.
Given that corporate America has decided that all employees are meant to be replaceable and therefore transient, it is not rational for any individual to orient themselves to the long term or make near term concessions. Likewise if employee compensation is a function of hours worked more than it is a function of the company's success, it is irrational for an employee to make decisions with respect to the long term, especially if they will be rewarded for speed over complexity tradeoffs and they can leave the company with a great resume when the debt becomes overwhelming.
Admiral Rickover's speech Doing a Job speaks quite a bit to technical debt and the forces that promote it: https://govleaders.org/rickover.htm