A client’s team spent a full week adding a CSV export to their admin panel. Two engineers, clear requirements, maybe a day of actual work. The rest of the time went to understanding existing code well enough to change it safely. That’s what I call codebase drag: when the codebase makes every task take longer than it should. It doesn’t show up in any dashboard or sprint report.
Always blame engineer because tasks are perfectly described and business logic is always clear and constraint in time.
“Codebase drag” formerly known as “technical debt”.
Oh hey, next sprint we’re going to work on that!
Oh, there’s a feauture request from sales you say? Hard due date of Thursday? But that’s a really big feature we can’t just… okay fine, but the next sprint we’re need to work on tech debt.
When developing code for first release, we had a dedicated HIP Sprint (Hardening, Innovation, Planning) and we had the most productive team in the company. Other teams were struggling cause they were just using the HIP as another Sprint. So what did we do? Got rid of the HIP, naturally. You see, some teams weren’t using it and it’s unfair to those teams that we’re not doing work when they are. Now everyone’s suffering!
Also had legitimate agile practices (budgets are for HR, work on what you need to work on and let someone else worry about paying for it) and we were the most productive team in the company. So, naturally, they need to get a bunch of C-suite guys to come over and run things cause it would be really embarrassing for them if they weren’t involved in the new hotness. Naturally, though, we gotta go back to funding buckets, cause those c-suite guys don’t understand why they got to talk to the developers when they want something fixed instead of handing things down from on high. Oh no! Suddenly all these issues are popping up in the workflow, guess we gotta force in ai to fix the problems.
Last place I worked we were promised a sprint where all we would do is tech debt fixes. Guess what never happened since the top brass kept pushing new feature requests on us. Features kept taking longer and longer to implement and every release we had more and more bugs make it into production.
Well, yeah - that never happens. You do tech debt cleanup “as you go”. Slip in a few tickets to cleanup specific things and have a policy to update code that is touched when adding features / fixing bugs.
It needs to be a continual cleaning process. That’s why it’s called debt - the longer you let it go un-paid the harder it is to do.
I suggested at my current job that we adopt a policy of fixing things as we go. Boss wasn’t interested. He said his boss said “he doesn’t want people gold plating things”.
Okay. I guess we’ll keep this tower of bash scripts that breaks once a month.
Why do engineers do this?
Simply fix the relevant technical debt as part of implementing a feature or fixing a bug. That way you can chip away at it over time.
Waiting for the big removal of technical debt will never come. It’s an ongoing process.
Leave the code base better than you found it – always.
due date next Thursday
The answer is to say “We will try our best, but this is very ambitious.” Then you let the deadline pass, usually it’s artificial in the first place. When the deadline passes say: “As we feared this took longer than we hoped for.”
The answer is to say “We will try our best, but this is very ambitious.”
If there’s some urgent feature request coming from sales then that means the Thursday deadline is in the contract and it’s already signed.
So what? If you weren’t consulted when the deadline was set, it’s not your problem. Have some balls and rip your bosses a new one when they pull bullshit like this. “That deadline was unattainable when it was set. Had our team been consulted, we could’ve worked on a solution. But since sales went over our heads, this is their mess to clean up.”
You don’t with in software do you? The software guy always gets blamed anyway.
Yeah so there’s absolutely no reason not to pipe up on bullshit like this
To quote my manager from today: “I don’t want us to spin our wheels and turn this into a month long effort”
The request is to effectively rearchitect a foundational part of the system. It’s a large lift project that should take weeks.
Of course I pushed back, I have good rapport with him and I’m not worried about getting fired over this. Not everyone has that.
“This isn’t a bazaar. We don’t haggle over deadlines. We professionally estimate them.”
Nevermind, it does sound like you work in software. This is a very familiar quote. x.x And it always comes right before planning slows to a crawl.
I’ve never heard the phrase “We professionally estimate deadlines”, but I’m gonna start using it. Thanks for that little nugget!
As the tech lead at my company, I treat all deadlines as fake until proven otherwise.
Also, when they start pressing me for dates that things can be done, I start multiplying by 4…
Multiplying by Pi is what I do. :)
Why would you ask permission to do something necessary? Just do it any time you have a ticket in the area.
One place I worked at had a rule forbidding pure refactors. One, it’s no other department’s (or manager’s) business that you massaged something to be more useful. Two, what is QA supposed to do with a change that has no new features or bug fixes? Three, are you going to put “refactor” in your release notes? Four, why are you refactoring things out of the scope of a feature or bugfix?
Not sure. Something can be written fine and technically good but it’s difficult to get started in… Its a headwind… Ie drag.
I don’t see that as debt?
Anything that makes the codebase harder to maintain than it should be is technical debt.
Whilst true, I was not talking about maintenance…
Rather “getting started in” ie onboarding.
“How easy is it to onboard?” is functionally equivalent to “How easy is it to understand?”. The biggest factor in maintainability almost always boils down to how easy it is to understand. So, difficult to onboard almost certainly means difficult to maintain, and thus is tech debt.
I see that as too idealist. When the rubber hits the road you cant spoon feed every newcomer with 100x docs per 1x code, so it’s inevitably going to be difficult for some to approach.
So now cos it’s hard for somebody you assume there is debt?.. It can’t be infinitely easy.
If your project is easy to maintain (aka low tech debt) that means it should be easy to understand the overall structure and it should be easy to understand any given component. So a new dev should be able to quickly figure out what part they need to change and how to change that part.
Some large, complex systems (like an OS) are unavoidably complex. Maybe it’s not fair to call that tech debt, but it’s still functionally the same thing - stuff that slows down development velocity due to difficulty of understanding. It’s just (probably) unavoidable given the domain.
But the majority of software projects aren’t that complex. The majority of software is apps and libraries that aren’t terribly complex. Monsters like operating systems and million to billion user scale products are outliers.
So did we make it to “codebase drag” yet?
Something that isn’t debt but is a headwind to making changes.
And LLM slop coding will make it exponentially worse.
It’s like purposefully introducing tech debt into the code.
Yes and they’ll try to use more LLM slop coding to fix it, except it’ll cause the codebase to balloon way beyond any possible ability to contain it within a context window, so LLMs will hallucinate more slop and the whole edifice will come crashing down.
My LLM slop personal projects have better test coverage than many many many professional projects I have had the “pleasure” of working with.
I’ve seen many an old crusty system with good test coverage. Doesn’t mean it’s good and high coverage doesn’t mean a good test suite. Coverage doesn’t measure quality of assertions being made.
Yeah, but the LLM will eventually realize there’s no fixing it and delete everything. /s
Under capitalism there’s no lowest quality level at which workers can refuse to exchange their labor for pay.
I find most bad codebases exist because of a culture that isn’t focused on quality, and I’m not talking about bug counts or code coverage. Clean codebases stay clean by being proactive about keeping them clean. This should include meticulous peer reviews, establishing design patterns, enforcing best practices, and taking initiative to leave things better than you found them (we used to call that boy scouting).
If your teams PR comments only contain LGTM, and the average time spent reviewing them is 5 minutes, your team isn’t focused on quality. If a PR contains more files than an average person can keep in their mental context window, it won’t get the attention it needs to be properly reviewed. If there is no accountability to keep a clean codebase, you’ll end up with 2 hours of work taking 5 days to complete.
The signal-to-noise ratio of reviews is nearly zero in my experience. It’s for the least productive people on the team to argue about spaces or gotos or grind other ideological axes.
I find PRs really dumb things down, but not in a way that makes code more understandable. And it certainly doesn’t improve quality.
If your team is only focused on tabs/spaces or soapboxing during code reviews, you have bigger issues to take care of.
Show me a place where this isn’t the case. Because I’ve never seen it not be the case in 20+ years in the field.
You must work in dreadful places. I’ve seen it a few times, but most places have been productive.
It needs a good lead dev to set the culture though.
Whitespace change debates can be avoided by using rule sets in IDEs and agreeing standards within the team.
Good static code analysis tools in pipelines and IDEs handle most technical issues leaving reviewers to focus on design, maintainability, clarity and readability.
You can avoid pickiness if you communicate why, so they learn and understand. If you use PRs as a training and learning tool they’re quite productive. If not sure, ask why something was done.
And if you get picky comments respond with “personal preference and not part of team rules”. But also, you cannot be defensive in your PRS. You have to be open to feedback and points and happy to discuss. Be polite even when feedback is invalid. Defendivesness kills constructive feedback and no matter how old you are and how long you’ve been doing it, you can still improve. Oh and if you been doing it that long, you’re a senior or lead and can influence how things are done.
15+ years in engineering here. 10+ in leadership.
Code formatting hasn’t been an issue since the early '10s. Tabs or spaces? Who cares. Your editor can make it look like whatever you want and it won’t effect the code.
As for other asshole-ish behavior or gatekeeping, I open it up to a vote. Let the team determine best practices. Don’t like what your team decides? Find another team to shitlord over.
My last job was pretty good about code reviews, when people actually spent time on them. My front end code got much better when the front-end expert actually reviewed it.
My current job, code reviews are a rubber stamp farce and I’ve seen total garbage sail though. The code base is a tire fire. These things are related.
A good alternative is code presentations.
You present your changes to a group of engineers. Then discuss it.
argue
Yes, it happens too often. That’s a failure of leadership or a social problem.
Techies often try and fix human and social issues with technology, but that doesn’t always work.
Code review helps spread knowledge about the code base through the team. Without it, you easily end up with disjointed fiefdoms ruled by petty code lords that don’t share information.
Spreading knowledge and context sharing are exactly why I like code reviews. It should also be something done by more than one person so that information is better disseminated throughout the team.
Code presentations are great for that.
One or two people present their code before the merge. Others watch, ask questions, etc. Small changes and improvements can be done immediately. Ideally the change is merged after the presentation. It can speed up things immensely and more people feel ownership. If a simple ticket stays in review for a week, it can be very detrimental.
I mean, what we have now is a clique of ideologically-aligned people who insta-approve each other’s bad PRs outside their domain and ignore or jam-up the PRs of people outside their clique.
You can say it’s a failure of management, but this is the primary tool used by the ideologues. And I’ve seen it used so at various places.
What I haven’t seen is a real dissemination of knowledge about the code via review. At least not above and beyond what can be achieved by looking at the code and using blame to see the changesets and looking at the associated issues.
This kind of social behavior is corporate politics and a failure of management of course.
Okay, I’ll go tell management they’ve failed. 🙄
No, you tell about management the problem and how only their amazing social and people skills will be able to do something about it.
That’s an engineering culture problem. Not a PR problem.
I’m fully talking out of my ass here, but I feel like a quick “five whys” exercise at any given company would reveal that the real issue is neither engineers nor code, but rather something systemic.
We used to do retrospectives at one of my old jobs, because everywhere loves cargo-culting agile and scrum stuff.
I quickly realized that a lot of the problems were largely outside the team’s control. It was shit like “The CEO doesn’t believe in designers or UX, so he won’t hire one, so we spend a lot of time doing that work badly ourselves.” Or, “management is making us spend all this time in ‘planning meetings’ so we don’t get anything done”
Stuff that has easy solutions, but we can’t do because some idiot or powerful cry-baby is in the way.
It’s usually because the engineers were rushed to deliver completely new features because the sales department over promised again.
It is almost always that.
Dysfunctional engineering teams, that have no empathy for end users is an issue as well.
Conway’s Law
Relevant xkcd:
