The really interesting part is IMO this one:
There is no such thing as “done” anymore. Every app must be updated indefinitely, and not just security or bug fixes. Once my vision for my app is complete, I stop reinventing it. That’s how you get AI added to fucking notepad.
I relate. Technical debt is by far the most common source of frustration in my career. It’s that code someone inexperienced wrote years ago that no one longer understands, but it still needs to be maintained. Often the code is also unnecessarily convoluted, so there’s a high risk of introducing new bugs when working with it.
I’ve recently managed to refactor such code recently. No one could work with it with confidence, it was slow and it was buggy. A lot of the code was also completely unnecessary (like 100 line convoluted mess that could be done with 1 line of code).
Now someone else in my team who has never worked with this code wrote a major addition to it without much assistance, so I take it as a sign that my refactor is a great improvement.
My biggest gripe is the lack of respect/understanding for the importance of data models and clear domain boundaries.
Most things that end up as “technical debt” can be traced to this. Sometimes, it’s unavoidable, because what the data models changes, or the requirements of the domain, etc.
And, it’s very innocent looking differences sometimes. Like “We know that the external system state will change from A to B, so we can update that value on our side to B”. Suddenly you have an implicit dependency that you don’t express as such.
Or, things like having enum that represents some kind of concept that isn’t mutually exclusive. Consider enum values of A and B. Turns out this really represented AZ, and BP (for some inherent dependency to concepts Z and P). Someone later on extends this to include ZQ. And now, suddenly the concept of Z, is present in both AZ and ZQ, and some consumer that switches on concept Z, needs to handle the edge case of AZ… And we call this “technical debt”.
Technical debt is a real doozy. There’s no value for the higher ups in fixing it, so nobody does.
New features just take longer and longer to add, under a teetering pile of your own shit.
I think part of the problem is the ideal underlying structure for your project doesn’t really reveal itself until several years in, and by then it’s a nice to have for some other time that never arrives.
Tech debt is like a hole in your roof that many teams don’t start trying to fix until water is flooding in. Companies missing the business value in addressing tech debt leads to perverse incentives for developers where they are encouraged to cram new features into the product and then leave for another job in 2-3 years before the consequences come knocking.
There’s no value for the higher ups in fixing it
Well there is, it’s just long term value that they don’t even understand.
Really you should just make fixing technical debt part of your regular job. Don’t ask for permission, just do it. (Except for really big things obviously.)
Personal experience bias in mind: I feel like owners and managers are less interested in resolving tech debt now vs even 5 years ago… Business owners want to grow sales and customer base, they don’t want to hear about how the bad decisions made 3 years ago are making us slow, or how the short-term solution we compromised on last month means we can’t just magically scale the product tomorrow. They also don’t want to give us time to resolve those problems in order to move fast. It becomes a double-edged sword, and they try to use the “oh well when we hit this milestone we can hire more people to solve the tech debt”… But it doesn’t really work that way.
Its also possible I’m more sensitive to the problem now that I’m in them lead/principal roles rather than senior roles. I put my foot down on tech debt a lot, but sometimes I can’t. Its a vicious cycle and it’ll only get worse the longer the tech sector is stuck in this investor-fueled forever-growth mindset.
Too much “move fast and break things” from non-technical people, not enough “let’s build a solid foundation now to reap rewards later”. Its a prioritization of short term profits. And that means we, the engineers, often get stuck holding the bag of problems to solve. And if you care about your work, it becomes a point of frustration even if you try to view the job as just a job.
The good news is, with the fed lowering interest rates the cycle of
speculationinvestment will pick right up in a year or two where it left off for a whole 30 months of higher interest. I can’t believe they’re dropping it so soon, but we can’t have unsustainable businesses held to account can we? Better to destroy savers and fixed income elderly.
Not surprised that Tech debt is among the biggest. There seems to be a lot of complexity added to apps unnecessarily these days-especially web based apps. It’s almost like companies purposefully force their engineers into creating web apps so bloated that users have no choice but to use the native app version.
Definitely agree with tech debt. Seems like nobody except me cares about improving things, which is surprising given this survey!
Also definitely agree about reliability of tools/systems, but again it feels like it’s just me that cares about robustness - everyone else is very happy to churn out hacky Bash scripts, dynamically typed Python and regexes with abandon.
Either you’re all a bunch of hypocrites or the SO survey is quite a biased sample!
Consider that to go on a site specifically for programming questions and then take a survey about it, you have to be the kind of person that cares about getting their code “right”. The majority of programmers I’ve met would only go there to copy-paste a quick answer, and those people have all moved to asking chat-gpt for code now.
My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
——On the cruelty of really teaching computing science - E.W. Djikstra
