Too often, what people call technical debt is simply an encounter with the limits of functional anticipation. If you think a system will never need to do X given the foreseeable usecases and then one day it does need to do X, you don't have technical debt.
Technical debt arises when you then try to shoehorn the needed functionality in, instead of asking/making/taking the time and effort to redesign it.
In fact, I've come across more technical debt in systems that tried to anticipate more functionality than reasonably foreseen: overzealous abstraction and open-endedness in a technical implementation can be a nightmare to work with. It's healthier to foster a culture where developers can cooperatively make disciplined adjustments to their software.
Spaghetti code is easier to write than maintain, and in doing software archaeology (yes, it’s a thing), I’ve encountered numerous reasons for it. Requirements creep is one of the largest reasons.
In fact, the first real software archaeology I did was explained, proudly, as being a product of someone walking in and telling the developer, “Wouldn’t it be nice if…”. Of course, nobody wrote anything down, and by the time I got to it the software was 25 years old and didn’t even have a brochure. People were still walking in and saying, “Wouldn’t it be nice if…”. Meanwhile, the company was required to follow standard software processes because it was required for contracts.
So I learned, from good teachers and a few bad ones, about Software Configuration Management, Software Quality Assurance, and Software Testing. There were reasons we did things a certain way. Our project configuration management contained everything needed to rewrite the software from scratch, including every single tool. I’d actually done a backup of a development pc after writing down the hardware specifications of the system and handed that in because quality assurance had to be able to take the same stuff and rebuild the same software so that it could be tested.
From scratch. And it had to pass the same tests. From scratch.
What I saw in other companies after that was never at that level, and on the surface it seemed ridiculous. However, any software engineer worth their weight in skittles has been screwed over by a platform changing underneath the code. Windows was infamous for it, though I did encounter it in an Apple shop as well. Your code hasn’t changed, but some update suddenly had you in the middle of bug city without even a flip flop. Microsoft has been notorious about that, with their version back in the day called DLL Hell. It’s just their (old) version of dependency hell.
I never had the problem with *nix systems, though when open source became popular and everyone started using that in their code, *nix systems started to get it too. People blamed the open source, but it was really 2 things that caused the problem.
(1) Bad Configuration Management (if it even existed!) and
(2) Taking the open source project for granted.
Open Source projects that are done voluntarily are completely outside the control of a company, but having an open dialog and even sending some money for pizzas and beer can avoid issues. Even with all of that, volunteers are fickle, so having in house expertise on projects becomes as important as how important the projects are to a company’s software. A company doesn’t really know this, though, when they don’t have software configuration management for their projects – so you end up with spaghetti projects, or as I call it, “Spaghetti Configuration Management”.
Toss in the developers that are copying and pasting from Stack Overflow, or now GPT, dash in employee turnover, where expertise is lost, and you get software entropy. Talking about software entropy causes the eyes of pointy haired bosses to roll to the back of their heads, so instead we talk about technical debt, because one thing businesses understand is debt.
Over the years, companies I worked for were at various stages of technical debt. It’s a real thing, and the startups that survived long enough to get to the point of technical debt were the worst because of the culture shift needed: Documenting things, tracking things, and making sure that the knowledge stayed within the company. I can say with good conscience that I left every company better off than when I left it, sometimes because of the company, sometimes despite the company.
seeing so many posts on here from 50-something men complaining that younger software engineers can't do as much
i would really like to settle in somewhere and just truly master 1-2 things instead of having to constantly pick up random pieces of garbage and try and use them to reinvent the wheel, but unfortunately the economy has basically incentivized software engineering to become a trade centered around picking up garbage and jamming it in random holes.
@h_thoreson Bad news from this 50-year-old senior #software engineer: we also often lack the authority to advocate better practices in our own organizations.
The product and project managers have inserted themselves like ticks into supposedly “#agile” #development teams, poisoning the process with mandates from #sales, #marketing, and the rest of the business. They’ve transformed #TechnicalDebt into something that gets you fired if you work on it.
Maybe hire an archivist to organize your company's shared drive of folders that have been yeeted in randomly, and help tackle the backlog of knowledge that prevents people from being able to go on vacation or retire because no one else knows what they know. It may be low level work in your eyes, but that's also why your problem never gets better when you assign it as a three month project to an intern... once every few years.
Observations from a startup consultant: "Either you’re swimming in technical debt or you’re just too early or too unsuccessful to have accumulated it."
i was asked to make the 404 and 500 pages look pretty.
13 commits, 16 files, 30+ test changes.
This doesn't count the buggy function i found, fixed, and wrote tests for, only to be told we could delete it and the single use of it because it was obsolete.
You were never much more than a sad slashdot knockoff with less interesting dupes. Nice shitting all over #perl for your complete lack of keeping stuff up to date to add to the class of the place. Byeeeeeee
Note the first two words in the definitions of both “we need to rewrite it” and “#LegacyCode”: “It works.” If it’s profitable, you can pay down #TechnicalDebt with minimum “interest.”
But @ncommander admits #SoylentNews never had a sustainable business or community governance model.
Does #Perl lack millions of cheap commodity #programmers? Yes. But the ones it has are force multipliers.
I just started using GitHub CoPilot for VSCode, and.. wow. This basically does 50-80% of the scut work, meaning I can crank stuff out 2-5x faster and focus on the higher level stuff and not spend time thinking about "did I remember to handle error X when. grab a web page." Also, it'll reduce the amount of typing, which is good for avoiding RSI. At $19/month/user for a team, the ROI on this is like... 20-30 minutes?
@kurtseifried
It will change the kind of #code we write and the kinds of bugs and features we create. I don't know whether it creates more or fewer insidious bugs and #TechnicalDebt (bloat, less readable style, antipatterns). At the very least it will recommend more MS tools. I've not seen studies on code quality and productivity or the long term outcomes for large complex systems. But it looks like LLMs change the way we think: https://dl.acm.org/doi/pdf/10.1145/3544548.3581196