How do you approach tech debt in a fast-paced development environment?
Posted by bylandoo@reddit | ExperiencedDevs | View on Reddit | 79 comments
As experienced developers, we often find ourselves balancing the need to deliver features quickly with the growing burden of technical debt. In my current role, I've noticed that while rapid delivery is crucial, neglecting tech debt can lead to diminishing returns in productivity and quality. I’m curious about how others manage this trade-off. Do you have specific strategies for addressing tech debt while keeping up with feature requests? For example, do you allocate regular time for refactoring, or do you tackle it on an ad-hoc basis as issues arise? Additionally, how do you communicate the importance of addressing tech debt to stakeholders who may prioritize immediate feature delivery? I'm interested in hearing about your experiences, successes, and any pitfalls you've encountered along the way.
0xbasileus@reddit
don't rush to call something done to please your superiors until the tech debt has been removed. fail your deadline if you have to.
UnrulyLunch@reddit
You can do it the way my org does: pay lip service to it until it derails a release, destroying your credibility with customers, and then act like it's the fault of your engineering staff.
dustywood4036@reddit
You get it. Who cares if the database is going to crash under new volume when there's a cheap feature that can be pushed out. Fixing tech debt doesn't bring in new business. Im hoping to get out before it really does crash.
Trick-Interaction396@reddit
Unless you work in a start-up a lot of deadlines are just made up and don't really matter. Do it right, do it once. Personally, I refuse any projects where I can't set my own deadline.
dustywood4036@reddit
Ceo? What kind of org do you work in that you set timelines?
flstckdev@reddit
I normally look for small improvements that, by themselves, won’t take a lot of time when kept small. These small improvements add up over time when done regularly and consistently. These are called tidyings. Because the changes made are small, they are easy to understand and won’t take up much time. The chances of breaking anything, compared to big refactorings, are therefore low. Tidyings come from the book Tidy First.
cs50guy@reddit
Double the estimate it takes for the feature and deliver it including any refactoring necessary under the radar.
thefragfest@reddit
Bake tech debt resolution into new feature development scope. Fix related issues while you’re there or design your approach to the new feature in a way where you’ll get to address some tech debt along the way or as a prerequisite for implementing the new feature.
Much easier to convince a stakeholder something is going to take an extra 10-20% time than to convince them to leave you alone for 10-20% of your time to “address tech debt”. Plus as a bonus, when you address tech debt in-line with projects, you end up focusing your tech debt efforts on areas that you actually have to work on more often and you aren’t spinning your wheels cleaning up something in an area of the codebase no one cares about.
Askee123@reddit
In my experience you need to quantify it in plain terms and pitch it as a strategic decision/have a good case for it being a strategic decision. An engineers resources are the hours, exclusively.
Tech debt sucks up engineering hours and slows down delivery. Delivery is tied to revenue, tech debt affects revenue and now you’re given the bandwidth to fix those problems.
Isogash@reddit
In my experience a lot of "tech debt" is actually design debt: some feature has not been designed very well and ends up being coupled to other features in a way that makes all of them harder to change. This normally happens as a consequence of either trying to rush new features (due to time pressure) or simply not having an engineering culture of doing design.
Unfortunately, I've met a lot of engineers who just don't really care about good design, even experienced ones. If you don't have someone who can do it and is supposed to do it, then you won't do it, and that's actually the most common cause of tech debt IMO.
The reason bad design is such a big issue is that when your design doesn't match the user/stakeholder's mental model of the problem, it means that when the problem changes in a way that makes sense to them, your code model can't adapt easily. Really, you want your solutions to model what the problem actually is as closely as is sensible, and break it apart where things really are separate. Of course, your stakeholders are often totally useless for this as they are not modelling and problem solving experts.
The best way to avoid tech debt is to do good design work first, which means not just picking a design that works.
ub3rh4x0rz@reddit
Tech debt burn down is a theme, not a deliverable task. If you can't frame it, even if only to yourself, as incidental to some other initiative, then your problem is storytelling more than anything. Its a footnote of why some feature or bug fix ticket had a lot of changes attributed to it, or it is mission critical to unblocking an important project. It's largely something you just do as an organized team, a shared commitment to building little incidental improvements into work in a continuous fashion
37chairs@reddit
Slap a security risk label on it and note cves on any hairy dependency updates to get a little backlog priority. Write it with related work you want to clean up. Size it big enough to matter not big enough to be a rewrite.
Ask for team goals around improving quality by x% per sprint by improving (whatever thing) incrementally. Test coverage, switching to a different pattern, whatever other tech debt you can tie to product quality and actually measure. Good managers are hungry for goal ideas like this.
bossier330@reddit
Tech debt is best called “organizational debt”. Of course making money is great. But both product and engineering sides of the org need to be aware of the tradeoffs. It’s very often possible for a feature to cost 1 time, 1 org debt, and return 2 monies. But then feature number 10 later on may cost 5 time, 2 more org debt, and return 3 monies. Even worse, feature 10 may result in more bugs or needing to compromise on what can be done due to the debt.
Of course, I’m always trying to maximize the feature goodness we can deliver while minimizing the org debt they builds up. Experience helps a lot with this. But eventually, I’ll have to say “we can’t do X without tackling some of this org debt, which we need to collaborate on to resolve” or “we can’t do X because of the org debt, but we could do Y for minimal worsening of the situation for now”.
caffeinated_wizard@reddit
I've worked with a very technically smart principal who said you just fix things "while you're in there". Meaning piggy back on a task to address problems around that area. "If you're gonna add a new API endpoint, might as well refactor these other 4 to match the new standard."
I profoundly disagree. It's super tempting because you're right there. In my example it's not even that complicated. But it's bad practice. You're just bloating your PRs and obfuscating the actual effort needed to do tasks. On top of all of this you're not actively documenting and categorizing it.
The way I found is the most effective is by documenting it, estimating it like any other task and prioritizing it alongside the work. I try to negotiate a 20-30% sprint capacity but it's not a hard number. But if the tech debt work becomes very important (foundational to an upcoming feature) than it makes sense to prioritize it.
ratttertintattertins@reddit
You don’t have to have a 1:1 relationship between PR’s and work items.
Where I am, we’d do that as two PRs. One with a small refactor and one with the fix.
If we tracked the refactor as a an actual work item it’d likely get deprioritised and wouldn’t happen. Got to make it look like it’s part of the value for the bean counters (because it is).
tikhonjelvis@reddit
I like stacked PRs for that sort of work. We've been using Graphite to do that at my current team which is a bit clunky, but better than not having anything.
I honestly envy the system Jane Street built for their internal use. And, of course, the fact that they were willing to build their own system shows that they have a very different mindset towards software than most companies :P (It's not a matter of scale either; they built the precursor to the system described in the talk when they had <100 engineers at the whole firm!)
nog_ar_nog@reddit
Tracking cleanup work in separate tasks only works if the engineering managers are actually technical. The ones in our org aren’t. Our codebase is in a terrible state, and it is significantly affecting our velocity, but if you tried to allocate some time for tech debt work during the sprint they’d just laugh at you because we’re drowning in feature and firefighting work.
Leaving the code better than you found it one PR at a time is the only way to stop our productivity from grinding to a halt here. The problem is that it only makes sense if everybody does it. Engineers here are incentivised to launch hacky alpha quality code to production and move on to the next project asap. If you take your time to clean up a bit of tech debt in each PR it won’t look good come performance review time because that type of work is just not seen as impactful.
Nearby-Middle-8991@reddit
Santa needs to give them the Pheonix project book in their stockings this year :)
tikhonjelvis@reddit
The frustrating thing for me is that the teams I've seen that were actually fast-paced were the ones with the best foundations because they thought about design and tech debt holistically rather than hurrying for the sake of hurrying. I have clear ideas based on experience on how to inculcate this approach when I'm helping a team and codebase from the beginning. But, frustratingly, I have absolutely no idea of how to get an existing team to think this way if the culture, codebase and management do not understand this dynamic.
Ideally, there's no single trade-off between "feature work" and "tech debt". Instead, you understand the overall direction that you're moving—what's the point of whatever you're building?—and make decisions about what to do based on that. A blanket "20% tech debt, 80% feature work" reflects a fundamental lack of understanding and judgement, regardless of what the specific % are. It fundamentally does not make sense to divide the work like that.
Here's one concept I've found useful: when you add some new capability, you should change the system so that it looks the same as if you had designed the system with that capability in mind from the beginning. I got this specific bit of advice from Ousterhout's A Philosophy of Software Design, but it's something I naturally aimed for even before reading the book. Over time, the tech debt that causes the most trouble, by far, is "design debt"; that is, the delta between what your system's conceptual design should be and how the codebase is actually designed.
Of course, this assumes that you have some baseline level of autonomy, and you aren't subject to a top-down planning process where management wants to (implicitly or explicitly) veto work at the level of small individual tasks.
If that isn't the case, I guess my only piece of advice is to remember that you're not in a position to do things well, you can just try to do things less poorly. Hope that doesn't burn you out.
Odd_Technology_8926@reddit
It's organisational discipline and you should dedicate a budget.
10-20% of developer time is good while shipping features. 30% if your code base is absolutely messy and is heavily impact your ability to ship.
Remote-Cow-781@reddit
Practice continous refactoring as you go along just increase those estimations to cover the additional time needed to keep things clean.
horserino@reddit
There is tech debt and there is tech debt.
There is tech debt that you squeeze into estimates, talk in private channels with other devs and don't involve management. Even relatively sane and healthy workplaces can benefit from this. Make everyone's lives easier and don't expect a pat on the back for it, other than from your fellow devs.
Then there is tech debt that needs stakeholders buy-in because it requires ongoing work, design effort, rewriting stuff, etc. This is the "we made a big design mistake on the architecture" kind of tech debt. For this one you put your diplomat/politician hat on and start making friends and fear mongering campaigns. If you turn things around, you put these on your CV.
Then there is the kind of tech debt that is resolved through individual therapy: it isn't your company, it won't bother your colleagues or you in the near to midterm future and your managers and stakeholders are being deaf to tech debt shit; so just let it go.
canyoufixmyspacebar@reddit
as a developer, you don't manage it, it is not your debt, you are not the owner of the code. you can put that question to the owner and if they tell you how they want to manage it, you participate and help but they will always take lead if they want to get their house in order
ButWhatIfPotato@reddit
The former is the consequence of the latter; either you slow down and do things properly or laugh as the technical debt becomes a technical black hole which swallowed another technical black hole. Sonic the Hedgehog gets to go fast because he has no coding standards and does not write unit tests.
I hate to say it but I have never seen any "I want things done yesterday" stakeholders move one iota in this position. You can give the most objective evidence of how much money will be lost tomorrow when things explode but that will always fall to deaf ears because it doesn't matter since we are making money today. I have seen companies literally die on this hill.
FanZealousideal1511@reddit
Just put the fries in the bag bro. It's all sales. You need to sell your vision to the leadership. The fish rots from the head + lowest common denominator, it's damn near impossible to change the status quo. Unless the business itself is software quality, nobody cares, even if they say so while interviewing you.
omgz0r@reddit
Slack time is an OK solution but it doesn’t prioritize the most impactful technical debt first. It starts to be more like eng pet peeve time, which is some of the lowest value to the business work you can find.
So, you have to quantify it. Fortunately, you already point out that it impacts velocity - so use that. Look at your roadmap and express the opportunity cost of not tackling technical debt. This will be your universal language between eng, product, the stakeholders, and the business. Further, it prioritizes the most impactful technical debt by default.
The main mistake everyone makes is trying to make it seem like a black box that eng will just take care of. But it is a leaky abstraction, as Eng still will use it as an excuse if timelines slip. So, you gotta bring everyone to the table beforehand so any tradeoffs are given the rigor they deserve.
morosis1982@reddit
We have a separate board that tracks our tech debt. It must be well defined and able to execute. Every couple of weeks the team has a half hour catch-up to decide what's the top of the pile and then almost every sprint we pick the top one and move it to our primary backlog and add it to the sprint.
Top of the pile is defined as highest priority, whether that be for urgency or impact reasons. They are sized like any other story, so we can ignore the top item if it's large and we have a particularly demanding sprint. Or sometimes we'll choose one that's more relevant to the other goals of the sprint.
Either way, sprint by sprint we slowly chop away at the most important items as decided by the team.
This is in a 4 person team, including myself as the technical lead, and is something I've also championed in other larger teams.
As part of the elaboration process we need to define what the impact is, from a business perspective, and so we get buy in from the business based on that. We do have OKRs that include things like SLAs so we have a way to tie pure technical work to support requirements if we need.
arthoer@reddit
This is the way.
throwaway_0x90@reddit
Think of taking care of tech-debt as similar to bathroom-breaks.
Yes, you'd really like to stay productive and fix the bug you're in the middle of investigating but nature calls. Sure, you can put it off for a bit. But as we all know, if you keep putting it off eventually you're going to have a major problem that will absolutely halt your productivity.
You should be tracking tech-debt in whatever work management tool you're using to track bugs, feature-progress, etc. At least once a month there should be a meeting to discuss all the unresolved tech-debts and a block of time should be allocated to take care of it. And yes, this means there will be times where you won't be working on new features. That's part of doing business.
Xenolog@reddit
This sounds really correct and slow, thus impossible in countries with survivalist business culture, where 3 years is a lot of time ahead.
If company has at least some competent engineers, most probably it can realistically postpone most of tech debt payments indefinitely, because critical knots will be dealt with during major feature dev and that is more or less possible to get through during planning.
The few things which company can't postpone, critical level stuff like adding server capacity, rebuilding core functions which will break the system if not dealt with in the timeframe X - yes, tech leadership can get through to the business ppl.
Anything else - IMO company must have unsurviveable contracts on system stability and delivery time to get any tech debt through, or it must rely dearly on user engagement/satisfaction or whatever :)
1One2Twenty2Two@reddit
Would this be when you publicly shit your pants in the middle of the office?
besseddrest@reddit
wait do we work together or are we still talking about tech debt
besseddrest@reddit
brb just had a sip of vietnamese coffee
throwaway_0x90@reddit
Absolutely :)
1One2Twenty2Two@reddit
I agree that once you shit your pants. You definitely have to take care of that first before even thinking of starting anything else.
ShoePillow@reddit
We need more analogies that relate software development to shitting your pants. Really brings things into perspective
Clear-Criticism-3557@reddit
This is not the way, once management knows it exists it will never be prioritized.
It’ll turn into a discussion, when cleaning up your workspace should never require that.
Simply add it to the estimation and explain that there is tech debt that will be resolved in the ticket. Inform QA of the impact and leave it at that.
titpetric@reddit
Every startup will disagree. Kinda wish they didn't cobble those together with engineering dropout student work and then flamed out burning VC money.
How is anyone incentivized resolving tech debt? So many places without tech leadership exist, so I think paying it off is the factor of the local engineering cult. A reasonably valid way forward is to accept the issue exists, and defer it to the backlog. If someone pays for it, then yes. I'm usually delivering products to a grade that's higher, and then naturally gravitate towards structural and strategic debt, preventing the anticipated, optimising the observed. It's a character type, some people specialize in CSS
SandySultanas@reddit
I work at a large company and even with tech leadership, all the work we do must roll up to a ‘Bowler’ goal (read: OKR, KPI) that improves the customer.
I’ve tried framing debt reduction as quality work - reducing outages, improving product experience, and it isn’t funded.
I’ve tried framing it as productivity improvements, leading to improvements in other areas. Still hard to fund it.
The only strategy I’ve found to work is to just do the improvements anyway without signoff. Over estimate all other work to build a buffer and use that buffer here and there on debt reduction work. You need to track the before and after state though so if you get called out on it, can prove the improvements are worth it.
titpetric@reddit
It's a cost centre for a service context, devops/sre staff, and generally whenever something bad or unpredictable happens, the root cause could be washed away in git history, if there was only anyone qualified... There is, but you're meant to be going through bug smash, rather than proactively eliminate the cause of bugs, best practice ideals or otherwise.
You need a charter for this kind of stuff, and it's usually that you can only enact change from a sufficient leadership position. Change is top down, so I suggest you get promoted to CTO or an Engineering Lead, if you want to organise work priorities and have a technical debt roadmap. You'll never reach it bottom up, and working against debt on your own is discouraged as it brings code review burden to others, and they only commit to what's in sprint, and we need point estimations, and we need all this bullshit, while the PR you crafted sits there.
The moment before the merge is when you deliver value, and the time spent waiting, communicating, researching, documenting and waiting on review, you collect all those metrics for a change, and you'll find what your value map is. A change may stay in review for weeks, and there isn't a long term recurring process at the org what would let people track anything that's not an OKR, like say, having a roadmap on whay we're considering adding for customers, and having a technical debt inbox 0 policy. Usually you have choices, and that's a point of technical debt, some individual decided on "I can live with this" and pushed to git, and then somebody comes along who's bothered strategically and structurally.
I want to do this, but I don't want to convince people, I want to decide to do it and then I do it. Usually you need the support of a few people to implement it, but aside a few sync calls, there should be little to nothing standing in the way of best practices, because you realise it's only a matter of time before they save your ass. You probablly know months in advance you're going to need to scale out a service, and before that you probablly measure some performance, check the history to see if there are regressions, there's a whole lot of forensic detective work going on, trying to find resource hungry goblins that eat your ram, your cpu and your disk.
All we can really rely on is systems, human errors, and taxes, and talking about working against technical debt is alike trying to solve human error once and for all. Robust, resilient, secure, stable, performant, all of these are just dimensions of the same system. Complexity is also a dimension of a system, one that needs work against, prefering simpler solutions you can reason about.
I like to quite I learned most of this from the google SRE handbook. They recommend a 50/50 split, and I'm partial to some form of platform team that does software architecture backlogs, and not product ones. Correction cost but can also save you a lot on ongoing cloud cost, etc. It's always a trade off, because you can't solve all of the issues in predictable timeframes of 3 hour blocks interrupted only by a pommodoro timer.... So you have to communicate, coach, review and measure, and generally just keep around a KPI dashboard, have inbox 0...
SCRUM is a psyop for shareholder value
throwaway_0x90@reddit
Oh, I've been in many start-ups in my career.
Priorities are different - their goal is to get users, to the detriment of everything else. Get bought out, vest your shares and run away before the buyers realize they got a big ol' pile of spaghetti code.
finger_my_earhole@reddit
You need to define what tech debt is so you can prioritize the "right" tech debt with the limited time you have. The term is used SOOO loosely and subjectively: from this-tool-isnt-my-favorite-flavor-of-ice-cream, to we-are-missing-an-abstraction-i-think-we-should-have, to this-is-an-actual-measurable-operational-risk.
Without this, maybe spend what little time you have fixing the cyclomatic complexity of a function to make it more readable - only to get paged at 2am for that thing that paged you 2 other times last week.
This is a pretty decent blog post with an opinion on that, though game development related the ideas can be applied to other types of development: https://technology.riotgames.com/news/taxonomy-tech-debt (i specifically like contagion as a dimension to evaluate)
drizzyhouse@reddit
Just mention it every time it comes up. Also, make whoever is responsible for introducing it, be responsible for removing it. That's often not engineers. Some leadership person will want something done in X weeks, which means you're having to take shortcuts. You may literally written the code, but, if you had more time, you wouldn't have introduced (as much) tech debt.
I'm actively trying to invert the responsibility at my current job. The common trope is that engineers need to "find time", when it's not only their responsibility.
Another trope is that engineers need to "prove" the value of addressing tech debt. Any fool who's worked in a tech company should know the value of it. I recently presented to our whole startup that there is always tech debt, and therefore there's always time needed. There simply should be time every year for it, as opposed to engineers having to fight tooth and nail to get a balmy little week for it. Again, trying to invert the responsibility.
Lastly, I've started talking publicly about tech credit. I recently added some persistence for some metadata artifacts from pipelines. It was a small thing to add, and I openly didn't have a current use case for it, but it was adjacent to other work I was doing. Several weeks later, it turned out to be massively useful for a new feature and for fixing an urgent bug, really quickly.
I've had varying success so far, as it's my first time trying these approaches.
Tiny_Ad1105@reddit
If tech debt can be prioritised, it can be deprioritised. I learnt a while ago to never put any tech debt tickets on our Jira board, because they ALWAYS get pushed back. Tackling tech debt is not something you allocate sprints or explicit time for - it's just something you do along the way. The business doesn't care, so don't tell them. Got a ticket that will take 2 days? Now it takes 2.5 days because you need to clean up some existing code to make the new code slot in better. My favourite metaphor is the kitchen - chefs don't take two weeks off every quarter to clean their kitchens, they clean as they go. Software is exactly the same.
But also remember that not all tech debt is bad. If you're refactoring code just because it could look nicer then you're wasting your time. Only worry about resolving tech debt if you've resolved unknowns, or if the current state of the codebase is slowing you down/making it hard to add new features.
teo730@reddit
LLM-written post.
Noah_Safely@reddit
Fast or slow, I've never seen tech debt meaningfully addressed in any shop. Just products get old/obsolete and refactored to magically fix all the problems. Except the old stuff has to run for 'reasons' now you're running two systems in parallel indefinitely, with the old one getting scarier and scarier..
/oldgrump
imagei@reddit
With the caveat that it’s not always that simple, particularly on old codebases, the way to deal with tech debt is to not have it in the first place. In other words, aim to not produce monsters that are going to haunt you later on. When one sneaks through (and it is a when not an if), gauge how much it affects the velocity and deal with it as soon as feasible.
For new code I apply a simple method: I look at it and categorise it into: - tf is this shit - I can live with that …then rework the former before calling the feutre ready.
Party-Lingonberry592@reddit
Ask your manager to add tech debt reduction to his/her quarterly goals. Recommend 1 engineer each sprint to focus on bug fixes and refactoring. Watch metrics such as availability, support tickets, performance, etc... You'll have a good story to tell leadership.
LeadingPokemon@reddit
This is controversial but my pattern is to enforce standards for new code. When you say tech debt, I see strangler pattern. Do not name your cattle, but have them bear children. Those children will be the legacy code of their legacy.
donny02@reddit
tech debt doesnt matter until you've hit product/market fit and have several high paying customers. and even then, not much.
Facebook was (and still is) an PHP app. Same with Uber, the ugliest code base I ever touched makes $20B/year in revenue.
The industry rewards new features, new products, new revenue and growth. Don't volunteer to be a janitor with a keyboard talking about reworking code that already works.
eyes-are-fading-blue@reddit
Doesn’t ugly code base cause churn?
donny02@reddit
nah, big successful company RSUs tend to smooth that over.
eyes-are-fading-blue@reddit
We take care of tech debt by rarely introducing it. Sometimes, you have to due to timelines. We often address it before it causes more damage.
foresterLV@reddit
define tech debt? for many it's "I don't like this personally". tech debt throwing away subjective/dogma stuff is something that slows team down. if you can spend 4 hours to speed up development 2x of next feature it will be pretty pragmatic decision to do the change. on other hand if it's refactoring for refactoring for unknown benefits (naming it "tech debt" for a nice word) it's just waste of time.
martinbean@reddit
By creating tickets to tackle it, and including those tickets in sprints.
codescapes@reddit
So long as you exclusively call it a "proof of concept" it never becomes tech debt 👍
apartment-seeker@reddit
Create tickets and allocate 10-20% of story points per sprint to handling
severoon@reddit
You need to understand where in the stack or module you are working.
If you are working on code that supports a lot of other code, i.e., lots of incoming dependencies, then you absolutely cannot allow tech debt to accumulate. You should have as a normal part of your work some kind of requirement that doesn't consider a project delivered and "maintained" if some fairly strict bar isn't met for keeping debt down. If anything, this kind of coffee should be prepped for the future to take on more dependency.
If you're working on code that has few incoming deps and it's in part of the design that will remain that way for the foreseeable future, then investment in keeping tech debt low should have some kind of demonstrable return that is communicated, documented, and agreed upon.
In poorly designed code, everything has lots of incoming deps, so this is a signal that if you want to be able to invest less in this, get your codebase under control first and give it some clear structure.
aq1018@reddit
From my personal experience, tech debt can only be meaningfully fixed when the whole team is onboard, preferably with management awareness and support. However a good number companies I had dealt with in the past do not take it seriously enough. They tend to be more reactive than proactive.
I would recommend against being the lone hero to try fixing it yourself, as it will only breed animosity. I found what worked was to talk to management and phrase it as an investment that will lead to faster iterations and reduced incidence longer term. Depending on the priority of the company, you may or may not get what you want.
Once you have the buy-ins. You can start by catalog the tech debt as tickets and allocate a few of those tickets along with regular features for each sprint. Use pair programming / PR reviews to prevent more tech debt. Write coding standards docs so it can be communicated to the team along with more gentle and empathetic preaching to the ones who struggle, etc.
It’s a slow process and often can be interrupted when company priorities change. It’s difficult.
Historical_Cook_1664@reddit
Explain to them that tech debt is called tech debt because it ACCUMULATES INTEREST and needs to be paid off before the product not just fails, but fails SPECTACULARLY.
tetryds@reddit
Business people don't care. Business people see button, click button, button works, now they want another button.
If you don't manage to make them understand the business value of addressing tech debt you will never be able to do it. Saying "productivity" and "quality" doesn't cut it, you need to be able to explain in their language: money.
Artistic-Border7880@reddit
When you get a name in your industry as the “Boeing” of X business people will start caring… although at that time it’s already quite late.
tetryds@reddit
They care only about money. It hurts their wallets so they went to find someone to blame and have to sort it out now. This means doing the bare minimum, which clearly has not been enough, as expected.
get_MEAN_yall@reddit
Typically fast paced dev environments create tech debt instead of addressing it.
SanityAsymptote@reddit
If the business is all gas and no brakes, you don't get to fix tech debt until the debt comes due and your system is down and everything is on fire.
If the business gives you some brief reprieves from the constant pushing, you can do it during "innovation sprints" or similar break times. In my experience this is mostly what those are used for.
The most important thing is to take some time to prioritize the tech debt so when you actually get a chance to work on it, you can tackle the most important things first. If you're having a specific issue that takes down production, obviously fix that first, but try very hard to fix at least one major pain point as well.
The scary part is the truly titanic amount of tech debt generated by using LLMs for software development, if your company is employing vibe coders or using LLM tools to do PRs or some similar thing, the amount of tech debt generated will likely sink the product/company in the next few years, so you might be better off looking for another job.
Antique-Stand-4920@reddit
Teams typically already have processes in place for managing product features. A lot of those same processes can be used to manage tech debt. This has been helpful for us. Having a separate process (or no process) for tech debt makes tech debt less visible and decreases the changes of it receiving the attention it needs.
successfullygiantsha@reddit
Your manager should be able to carve out a % of time to dedicate to it. It's not just something that's done when you "have time."
randomInterest92@reddit
We allocate time each sprint to tackle a bit of tech debt and I as a lead dev control/decide the priority together with my dev team. Our goal is to not have increasing tech debt. It should either stay flat or decrease. Increasing tech debt is only allowed if business is in imminent danger, because obviously sometimes you have to make money quickly or avoid some penalty or whatever to stay alive
devoutsalsa@reddit
Slow down.
davy_jones_locket@reddit
At a previous company, when we do "rapid" iterations, we generally have the following acknowledgements:
we work in a field where our position is fragile so bugs and user experiences disruptions can be detrimental to our reputation
while we can do hot fixes, it is a whole process that requires a lot of time for more than one team and disrupts the current sprint. This is why we have dedicated release days each week.
speed to market is important and we have to align features releases to specific times of the year because our field cyclical.
we can sacrifice almost anything, but we can't sacrifice quality. We can sacrifice performance to an extent, feature functionality, etc. but everything still has to pass QA.
These are our cornerstones for most decisions and we use these a lot in our arguments. Things that get sacrificed end up in a tech debt bucket.
We reframed tech debt and those kinds of things get categorized as either papercuts or product enablement. Papercuts is the small annoying stuff that becomes more painful over time. Product enablement is all the tech sacrificed to ship an iteration. This is a big deal because we can make the argument that until we address these issues, we can't ship another iteration of feature sets. It's the stabilization of the foundation so that we don't build more stuff on a base of quicksand.
We do enablement for the next iteration regularly. The faster we can address it, the faster product can get their next iteration. Plus it gives enough time to get feedback and metrics on a new feature to decide if they even WANT to continue with it, or scrap it and do a different approach.
Papercuts tend to be less regular, and towards slow product periods, usually end of the year stuff when holidays impact people's schedules. These also tend to be things CI, working on preview environments, internal platformy kind of stuff, renaming stuff, fixing cosmetic issues, etc. Bigger papercuts do get addressed sooner, but unfortunately not before Death by a Thousand Papercuts stage, which is when it impacts product delivery.
Nofanta@reddit
I start looking for a new job. Speed is important but too much is management problem.
rayfrankenstein@reddit
The only way to do this is budget a certain percentage of story points/hours every sprint/iteration for tech debt remediation, and make sure that upper management can enforce it as an unmovable boundary the stakeholders aren’t allow to change or finagle.
e.g. each sprint stake holders get 50 story points for features and devs get 10 story points for fixing tech debt.
Because it’s a regular % of every sprint, it’s not a special sell you have to do or ROI you have to quantify.
latchkeylessons@reddit
Do whatever it takes really. Bake in time, plan for it, try to advocate for project time... just do it anyway. All of that is required to battle tech debt. The business will almost never come to a development team asking them to fix that stuff. Making serious advances against problematic code/system areas in a company of any size usually requires most of the strategies you're going to find on this sub.
Illustrious_Pea_3470@reddit
You have to clean up as you go along.
truechange@reddit
What type of architecture is the software currently using?
shroomaro@reddit
I own tech debt on my team in my org.
I have to deal with almost the inverse problem of leading a bunch of engineers who want to fix tech debt as soon as they find it and put deadlines at risk.
I think the way to manage tech debt is the same though.
I have our engineers log tech debt into a triage queue, and we meet every 2 weeks to discuss the queue, punt on things that aren’t a priority right now and schedule tech debt work that’s important enough or might block upcoming work.
Stakeholders get no say. PMs get to tell us what to build by when, but the day to day, week to week scheduling is ours. We just ensure we balance tech debt with forward progress and ensure we hit our dates.
mmcnl@reddit
Tech debt is a talking point, not actual work. So the answer is: can you make it specific And relevant to the current work you're doing? If yes, then congrats, you have the taken off the intangible "tech debt" cloth and now it's just work with costs and benefits. It no, then also congrats, because it's not important enough to address right now and you can work on something else.
Zeikos@reddit
70% of technical debt is an organizational problem.
What's the dev-hours budget allocated to addressing technical debt?
What are the software development standards the team follows? How are they enforced?
How much time is allocated to critique current processes?
What part of the development cycle is automated? =ow? What isn't?
The remaining 30% is "we always did that this way" or "we don't have time to change that now" (it then costs more time in the long-run).
The only way to ship quickly and reliably is to slow down and minimize the cognitive complexity and effort that it takes to find/fix/change things.
Ask yourself this?
How long would it take to a senior developer without any domain specific knowledge of your codebase to become productive?
If the answer is more than a week then there's a problem.
lordnacho666@reddit
There needs to be slack in the timetable to clean things up. Sometimes quite significant slack, where people are just milling around with no specific project.
You need the experienced hands to put their foot down and say "alright enough is enough, this piece needs to be refactored".
So you need the right culture.