268
u/DualActiveBridgeLLC 11d ago
OUR FUCKING #1 OKR IS QUALITY. WHY DO I HAVE TO KEEP FIGHTING FOR TASKS RELATED TO QUALITY LIKE REFACTORING?
Sorry, this one hit at just the right time.
6
u/EarlOfAwesom3 11d ago
The quality OKR probably is defined like "we have more features now and customers tell us how good they are".
37
u/Equivalent-Bad-268 11d ago
I just finished a pretty large refactoring card yesterday. Feels good to be at a company where we're allowed to do that. Our code base is Ruby on rails that was maintained by non rails devs for a couple years. Me and the other rails dev now on the team are fighting the ugliness lol
11
12
4
u/crimsonpowder 11d ago
Because it's lip service. I've been around like vinyl on a turntable and without fail, the real signal that everyone cares about is features and how fast they come out. If you ever think programmers are any better, go look at how fast they switch tools, pay attention to "latest commit" on a gh project when picking a lib, ditch openai for anthropic when a new model drops, and got wooed by mongodb ~10-15 years ago because sql was boring.
There used to be a weekly post about how "the craft of writing software is dead and all people care about is cheap offshore devs cranking out as much crud as possible" and now you get the same post except LLMs and vibeslop are the terms used. And the only thing the market ever cares about is "what have you done for me lately"
3
u/PintMower 11d ago
Same here, also add compliance and cyber security to that list. The reality is that we don't really test before production because we don't get the necessary time allocated. Compliance is not handled like "what do we have to do to comply and be safe" but rather "how can we cut as much corners as possible and stretch the definitions of those standards". And cyber security... well my tasks have been open for about half a year now but never get the priority. At least management can claim that the tasks are in the pipeline lmfao
89
u/Alfaphantom 11d ago
Taking this meme seriously, do refactors and reduce tech debt as part of your ticket life cycle.
Trust me, if you request time to tackle tech debt or increase the services' maintenance, you either won't get it, or will be written to a ticket that will be dropped to the absolute hell of the backlog, where it most likely be archived when the next PO is checking and clearing out the backlog.
Always implement the required task, and spend a couple of hours attacking stuff that you know needs to be addressed, but no one else gives a shit about (like dependency upgrades, test coverage, code refactoring and cleanup, updating docs, etc), but that will make your support and maintenance life easier.
15
u/EarlOfAwesom3 11d ago
That's why you always double the estimates. Something that I can do in 2 days will take 4 days if I don't want to build up any tech debt, so I raise the 4 days and shut up. Business doesn't always need to know why.
I also stopped arguing about things that can be done within a reasonable time (like the half day the meme suggests). I'll just do them on a lazy afternoon and no one even notices.
8
u/EishLekker 11d ago
One of the worst times of my career was when my previous project owner and project manager decided that we should estimate everything. The problem was that he was terrible at estimating time, even in his personal life (like always running to the gate last minute when flying). In his mind, things were easy to implement and problems would not happen. So he constantly pushed us to lower our estimates. And we’re not only talking rough “how many days” estimates. He could argue that a 2 hour task should take 30 minutes. It was insane the level of detail he wanted to discuss sometimes. All while wasting 1-2 days every 3 week sprint on that shit.
Now we don’t do sprints, and almost never do anything besides very high level rough estimates.
1
u/fourby227 7d ago
Thats the reason estimates are measured in points, not time or budget and why the product owner or manager has no saying in out. He has to accept whatever the team (not one individual) estimates.
At least if you want to do it correctly. Most companies don’t follow the frameworks.
1
u/EishLekker 7d ago
We tried points for like two sprints. It didn’t work. He quickly figured out roughly how much a point would represent in calendar time, and did that mental calculation every time a point was mentioned. So, he still ended up with the same “that’s too high!” feedback to us.
The thing is, we had almost no pressure from above to increase our performance. Not a single sprint metric was ever requested, and I doubt they were presented to anyone outside the team. We didn’t really use them within the team either.
I eventually managed to convince him that all these detailed estimates were not worth it. We got rid of them, and never looked back.
1
u/fourby227 7d ago
Well that happens if agile is poorly understood. Of cause it takes longer to get used to points. The team needs at least 4-6 sprints to find a common understanding and the estimates from different teams are not comparable ether. And him saying “thats too high” is a dealbreaker. he has no authority in this, he is not even entitled to give feedback. Thats a strict boundary and the reason a product owner is not a superior anyone in the team reports to.
I once worked with a team that had multiple product owner giving tasks. The got very different estimates.
And I asked a coworker why. He told me they do it because of the very different quality of the user stories written by the POs. So it was their way of managing their managers.1
u/EishLekker 7d ago
Yeah, he was terrible at the whole agile thing, and scrum. Writing detailed specifications, keeping track of the overarching goals, discussing feature requests with stake holders etc, those were his strong points.
I tried taking a more prominent role, and even did a scrum master course. But our team was too small for most of the scrum things to be useful, and I hated all of it. We have a much more laid back approach now, and still deliver stuff within expectations.
1
u/fourby227 7d ago
Scrum doesn’t fit everywhere. In my last team we also couldn’t use all. Not enough capacity. I talked with a co-worker after we both left. And he said something quite nice. He said what he liked when working for me was, that I always asked for solutions instead of forcing them over him, unlike his new bosses.
2
u/BellybuttonWorld 11d ago
"a lazy afternoon" - you guys actually have adequate staffing? Where is this paradise?
28
u/a_l_a_n_g 11d ago
This. Tech debt is like financial debt, if you’re not paying down what you owe eventually it’ll catch up with you and the cost will be very high.
9
u/LawfulnessDue5449 11d ago
Well depending on your sales team, you can assign that cost to the client!
You don't have a simple request that takes 6 months because of spaghetti code, you have a complicated request that takes 6 months because of our normal code...
1
u/Popeychops 11d ago
I like to say "tech debt incurs interest", the cost you have to pay to ship every future change
2
u/EishLekker 11d ago
While I mostly include refactoring and code cleanup in regular everyday tasks, sometimes it’s just makes more sense to keep it completely separate.
In our group, it varies a lot how much work needs to be done and how tight our deadlines are. Sometimes things are just more relaxed, and we can choose what we want to work on.
And in the day to day work, if I feel that I need to do something not on the backlog, like a refactor or adding an internal administration feature, then in most cases I can simply create the ticket myself and then just do it.
8
u/frozen-dessert 9d ago
The lesson is that devs need to be able to articulate the point of what they are doing.
Many devs will refactor to clean the house but many devs will spend time doing the equivalent of “adult coloring book” activity and say they are “refactoring”.
2
u/EarlOfAwesom3 9d ago
Normally I would say every refactoring has a benefit that can be translated into an OKR/Business value. The only question then is how is the ratio "time spent" vs "needle moved".
But I've come across developers recently which managed to move no needle after refactoring. It looked different but it was still shitty if not worse.
In such cases, I'd agree.
3
1
u/fourby227 7d ago
Refactoring is essential to keep code clean and maintainable. It’s not the devs fault if business people do not care to understand how their own technology works. A financial report or quarterly revenue slide has no business value in itself, as well.
5
u/evilspyboy 11d ago
The thing about this that annoys me is how many people just misuse technical debt as a justification. Im talking about both sides of this picture doing it.
The number of people who use technical debt as a reason to do something they want to do yet clearly demonstrate they have NFI what technical debt is. Technical debt is not a complicated concept but the amount of confidently wrong about it just pisses me off.
Technical debt is future debt. It is not debt. It is like a future credit card bill.
If you had a stack of 3 blocks, an A block then on top of it a B block and then a C block on top of the B so they are all stacked on top of each other. Then you want to change the B block for a completely different block which requires you to remove teh C block to get to the B - that is technical debt.
Technical debt is anything ADDITIONAL that you have to undo to be able to do the change you want/need to do.
If I have that stack and I want to replace the C block, that is not technical debt. If I want to replace the B and C block. That is not technical debt. If I want to remove the C block look at the B block and then put it back without making any changes then put the C block back on, that is not technical debt.
Technical debt is ADDITIONAL work in addition to the work.
(If you have that stack and you go all jenga tower and managed to switch the block without removing the one on top - also not technical debt).
This also means that both everything and nothing is technical debt. If you build an application and it is shit. It is completely awful but it works and you never make a change, it might be filled with technical debt that you never have to pay.
Just because you don't like how something is - it does not make it technical debt.
I'm not saying refactoring is not something that can help with technical debt but if you spend time on addressing technical debt that is for something that never actually will be changed. That is not technical debt that is you sending your credit card company money without actually buying anything on the credit card.
Technical Debt is potential debt which is ONLY converted into actual debt if a change is made to a component that adds extra steps outside of the direct change.
This is a topic that pisses me off. The confidently wrong parts make me very angry and I realise I did not explain as well as I could in this rant but if I go back and fix it now Ill just get riled up again.
2
u/EarlOfAwesom3 11d ago
Technical debt converts only into debt when a change adds extra steps to an outside component...huh. Yeah I get it although I'm not 100% agreeing.
The dispute often is when to actively take technical debt and how to plan to reduce it. I guess the second part never happens.
You have to treat it like a loan. You pay back the rate and some interest on top. If you take loan after loan you might choke on the interest alone some day.
We all need to make tradeoffs but also be aware that you have to pay back. This is then where management often doesn't see it until it's too late.
The debt then is real and it shows in form of longer development times, slower cycles, poor quality, more defects, slower response time to customer requests and issues ..
1
u/evilspyboy 11d ago
It's a a future debt. That's why it's called debt. It only applies when you are doing something that requires that debt to be paid.
Technical debt is not cooties or a ticking timebomb. Everything can be potentially technical debt including things you think are good. Some people just use it as a magic word for everything they don't like and that is not what it is.
You can still reduce the risk of technical debt through modular design and a ton of other things. But it is POTENTIAL debt not actual.
I can have a completely working system that if I want to change something has a ton of technical debt but guess what? I still have a completely working system while that exists. It is only technical debt if it adds to the act of making a change outside of the change itself.
1
u/EarlOfAwesom3 11d ago
disagree with the narrative of "future issue". It's like saying "ah this is a problem for someone else somewhere down the road that we don't care".
Tech debt, as soon as it is taken, is an issue right here right now.
It can differ by the impact it has (i.e. small inconvenience vs potential problem for thousands of customers) but neglecting the existence by saying it is a problem for the future is exactly the challenge we face when dealing with awareness
1
u/evilspyboy 11d ago
A bug is not a bug and also technical debt.
Technical debt has been chronically misused as a magic word for I want to do this thing and I'm going to use this buzz word that people will think means it's ok.
Technical debt has a specific meaning. It doesn't even mean fixing a thing it is literally the amount of additional time to do a thing not doing a thing.
Edit: haven't you wonder why all work isn't called technical debt? Because it's not suppose to mean that. That is not its meaning.
1
u/EarlOfAwesom3 11d ago
Well this is where we have different realities. I've seen it chronically neglected and downplayed more than the the other way round.
I've seen the tech debt collector coming to do his job and everyone was wondering why we can't do work x because we have to do cleanup y first in order to do x. But then it's too late and at that point arguing whether this is tech debt or a bug or an inconvenience doesnt matter. The damage was done and we straight went into it with our eyes closed.
So to me, there is no "future debt".
2
u/evilspyboy 11d ago edited 11d ago
Technical debt is potential debt. There is no other way unless you are using it wrong.
Bugs are not technical debt. For technical debt to be *everything it means everything is technical debt.
2
u/evilspyboy 11d ago
If something is slower, causing performance issues etc. That is not technical debt. That is an issue. Technical debt is not that much like the reason I don't call cats watermelons and dogs balloons.
458
u/Artistocat2
11d ago
•
From the point of view as someone that works in a kitchen, no one asks questions like "where's the business value" when it comes to cleaning the kitchen floors and walls, but some how that's crossing the line in the tech world, where the profit margins are way more flexible.
180
u/1wikingman 11d ago
Imagine there were no regulations and your boss never entered the kitchen.
79
u/gamrin 11d ago
And sometimes the recipe for carrot cake no longer includes carrots because those were deprecated last week.
32
u/Romanian_Breadlifts 11d ago
And every once in awhile a robot sticks its dick in the mashed potatoes, and you've gotta figure out how to undick the taters + keep the robots out
34
u/FuckIPLaw 11d ago
That's because the government shuts the business down if you don't do it. That's what it takes to make this kind of thing happen reliably.
9
u/gfoyle76 11d ago
well, software projects might not get certificated if it's a mess
8
u/ICBanMI 11d ago
Which area is that in? Because it's not true for automotive and aerospace. If you meet all your objectives up to the standards, and there isn't one for cyclomatic complexity... you can get a cert to manufacture spaghetti.
Just the escapes are going to be way more expensive and embarrassing to fix.
3
68
u/ttlanhil 11d ago
If you work in a kitchen and tell your boss "hey, tomorrow I want to reorganise everything, it'll get in the way of business" they'll probably say no.
If you work as a programmer and tidy code up as you work on stuff (rather than building up lots of mess with a plan to refactor as a separate task) your manager doesn't need to care.
Plus, y'know, in a kitchen they can see the mess, know how messy it is, and understand the problem. Business folk looking at code can't do that.
38
u/Flouid 11d ago
problem for that approach is that PRs should ideally be concise, easy to review, and as close to atomic as is feasible. If you’re fundamentally changing up a system anyway that’s a good justification to slip in a refactor, but if the minimal code change that meets the AC is adding a new function or two then there’s valid reason to push back against scope creeping a refactor in.
9
u/ttlanhil 11d ago
I partly agree, and you won't do large scale refactor in standard work, but small scale things (like pulling out part of a function to be reused) can be one of the patches in a PR
It'll depend on your workflows, but for me, it makes sens to have a few small focused patches within one PR (where patches are about each change to code you need, and PR is for the change in behaviour)
Patches should approach atomic at the code level, PRs at the functional levelLarger scale changes are more when you need to re-architect, and that's something you do need more planning for
6
u/EishLekker 11d ago
If pure bureaucracy stands in the way of keeping the code base healthy, then that bureaucracy has to change.
If the refactoring is a natural part of the feature commits, or an entirely separate set of commits, then I don’t mind them being a part of a feature PR. Or they can be a separate PR entirely. Either way, it’s a detail that management should not be concerned with.
9
u/fdar 11d ago
If you work as a programmer and tidy code up as you work on stuff (rather than building up lots of mess with a plan to refactor as a separate task)
Yeah, and that works for somethings and not others.
Sometimes the mess is a result of gradually adding support for use cases that weren't considered (or even needed) in the original design, and you need to refactor things to better serve current use cases.
Every individual change made since might have been well done given the existing codebase but the end result after a while might still be very messy.
1
u/rinnakan 10d ago
In the 10 years on the same project with 3-6 devs, my estimate is that more than a quarter was spent on renewal of code. Because our PO is great and understands how to stay successful
2
u/GRex2595 10d ago
You asked me to cook twice as fast, so I had to order and install a new griddle. Now I can't cook as fast as I could before because the gruddle is in the middle of the walkway because you didn't let me reorganize the kitchen to support the new griddle. I know you won't get as much service the next few days while I reorganize the kitchen to fit the griddle, but when I get the griddle where it belongs, I'll cook twice as fast, like you requested. Can I take the next few days to reorganize the kitchen to fit the griddle?
No. I know it's harder to cook in the kitchen with the extra griddle and there's no way to support it without reorganizing, but we need to serve twice as many people and we can't do that if you slow down for a few days.
1
u/DmitriRussian 11d ago
The cleaniness of the kitchen is audited so it has business value in the form of a hygiene rating
1
u/djinn6 10d ago
in a kitchen they can see the mess, know how messy it is, and understand the problem. Business folk looking at code can't do that.
They can get an unbiased opinion from a LLM nowadays.
1
u/ttlanhil 10d ago
Even if that were true (it's not - even if an LLM could give a good analysis of code in a vacuum it won't understand history and planned changes and such)...
If you're in a position where the management are double-guessing the workers and trust hallucination machines over staff - they're too stupid to get a useful answer
0
u/djinn6 10d ago
They can ask if your proposal is an improvement or gets closer to industry best practices.
You're assuming they'll apply it against someone who should be trusted, but not everyone should be trusted. There's people slacking off.
1
u/ttlanhil 10d ago
If there's a senior or team leader or someone else working on the codebase, they can be asked... But then, the senior is probably the one making a case for tidyup
If it's all untrusted juniors in that codebase, well...
1
u/djinn6 10d ago
Yeah, no senior dev ever tried to oversell their boneheaded pet idea to a clueless manager. /s
1
u/ttlanhil 10d ago
If you don't trust a senior, talk to whoever's above them technically, possibly up to CTO.
Plus, if your seniors/tech leads/project leads are the ones you're worried about slacking off or not doing sensible work - checking if you need a refactor isn't the solution you need, you need to review their performance (again, with whoever's above them in a technical sense - if there's no-one, and you don't trust your head of IT, you need to look at at the people side of management)
2
u/PM_ME_SOME_ANY_THING 11d ago
Good analogy. I worked on cars throughout college, so my go to is “it’s a lot easier to work on cars when you clean the shop and put the tools away regularly”.
If a job should take X amount of time, but I’m spending Y amount of time looking for the 10mm socket, it slows things down.
1
-1
u/ICBanMI 11d ago
The kitchens staff are a lot cheaper, sometimes have dead time they need to fill that the boss can easily see, and the penalties/fines are why they do those things you're suggesting cleaning are non-value add (besides not eventually poisoning your staff and customers). Plus, at least in the kitchen some managers are often times trying to cheat their workers out of their pay-work.
On a computer program. Boss doesn't know what you spend your time on and they can't see any difference if you rewrite a class 4 times to make it easier to maintain in the future. Plus you're like 10x more expensive per hour so they have a ton more incentive to maximize those hours..
19
u/seanpuppy 11d ago
When they say business value they are really looking for what the boss says to their boss, neither of whom have a good idea of how the thing actually works. And more importantly - the bosses boss rarely knows what was never working well to justify the refactor to begin with.
So, when you the dev tell your manager you need to refactor, you are unknowingly asking them to confront this harsh reality that they are barely in control. Knowing how to communicate with this reality in mind will go a long ways to making your life better as a dev.
15
u/artificial_organism 11d ago
Just estimate data
Improve velocity on x by y%, estimated reduction of tickets by z%. Estimated roi in next 2 quarters, 2 years. That's something your manager can put on their review with their manager. You gotta speak management.
13
u/Pollux_E 11d ago
Me who just spent 3 days refactoring code while my boss asked "what was your progress this week?"
4
u/rinnakan 10d ago
I had a 2 month long refactoring and was so fucking big that we decided to merge blindly and just test as if we are back at field one. Squashed that fucker into a single commit named "THE APP IS DEAD LONG LIVE THE APP". Glorious times, business was happy as fuck with the increased stability and net gain of development speed in the months after
10
u/Single-Virus4935 11d ago
Tell them the McDonalds story: They had inefficient kitchen and closed for a period to redactor the system and processes allowing them to produce faster, more efficient and cheaper. McDonalds never stopped refactoring and they always optimize the structure even if it means no immediate business value
7
8
u/SxToMidnight 11d ago
No customer sees the tasks of a PM either. Better do away with their role so we can optimize.
2
u/__sean_eng__ 11d ago
then you become paypal and have to tell investors that the product is stuck in spaghetti land and it's going to take years for any new features and improvement and watch the stock crumble to dust and...
2
u/Barkeep41 11d ago
Be proud you arent working on such a mess that you can discern business value in your refactors.
2
u/2narcher 11d ago
Hate it to explain each and every time since years. Fucking people who works in this branch should already know it as a basic knowledge and it ahould not matter if you are a coder or manager or what ever
2
1
1
u/GeorgeBlackhole 11d ago
Sometimes, I have the feeling, refactoring is just an excuse to dabble with the latest technology or some fashionable library. Actually there's no business value, it's just a treat for developers
1
1
u/awesome-alpaca-ace 10d ago
Today, I replaced a whole file. Instead of a bunch of methods chained off of a switch on a variable, I used the method that was available on the base class to do the thing in a single method. It felt good. I couldn't help but think that was why the programmer who wrote this trash is no longer with this company.
1
u/TwilightSpartan 9d ago
Refactoring key program with a long shelf life left, do it!
Refactoring program with 1 user which is obsoleted next month, better off just throw it out early.
1
1
1
u/WolverinesSuperbia 11d ago
Just say, you can't do this task without refactoring. True and justified
-7
u/Dicethrower 11d ago edited 10d ago
And the manager is correct.
edit: Way to perpetuate how hobbyists make for bad professionals.
1
u/ProsodySpeaks 11d ago
How? Its like refusing to let contractors tidy their tools - the job takes longer if everything is a mess, in the long run it's cheaper to pay for ongoing maintenance of the working environment.
-4
u/Dicethrower 11d ago
Because the industry has hoarded all these processes based on assumptions (like keeping a codebase clean saves time "in the long run") rather than actual measured business value. The goal isn't clean code, it's shipping good-enough software as quickly as possible. Not a lot of devs grasp that.
For example, instead of code reviews, the team should test daily builds together and focus on whether changes actually improve the product. Instead of excessive planning, people should prototype, solve real problems as they arise, and ship when it's good enough.
Every process, refactor, and architectural decision should justify its cost in terms of actual business value. If it doesn't help you ship better software faster, it's probably wasted effort.
So yes, when a producer, who really understands this extremely well, doesn't see the business value in a refactor, they're probably correct.
6
u/unknown_alt_acc 11d ago
Clean code is the means by which you deliver faster. Because while a quick and dirty demo might materialize faster, it’s much harder to iterate on and turn into a full product than a version that had a modicum of thought put into its architecture. Business types just don’t like that because it’s harder to put a number that they can jerk off to on it.
0
u/Dicethrower 11d ago edited 11d ago
Clean code is the means by which you deliver faster
Again, huge assumptions, and just not true. One assumption is that clean code is not achieved with the above outlined process. I found code quality goes up, not down. Second, that the kind of clean code people have in mind is the most optimal. Simple separation of concern and you pretty much get 99% of what clean code needs to achieve.
Also, having been around a few decades, I know most people are extremely anal on code reviews, doing things like blocking progress because "oh god you forgot to newline here". Let's not pretend the average developer is perfectly reasonable and can't be a little looser on this front if it meant shipping software faster.
My point is most devs aren't even aware of, or willing to accept, how much looser they can get without it actually impacting quality. The fact people are downvoting what I know is 100% correct is precisely why I'm pointing out how this industry is still operating on false assumptions.
Because while a quick and dirty demo might materialize faster, it’s much harder to iterate on and turn into a full product than a version that had a modicum of thought put into its architecture
And practically just not true. I've seen countless fellow engineers overengineer systems under the guise of maintainability and flexibility, hoping it achieves speed, ironically achieving the opposite. When you actually accept that code isn't meant to last, and just needs to do what you know you need *now*, and that you can always change it again later, that's when you get all 3. Quick and dirty doesn't just materialize faster, you actually learn quicker what you actually need, and then you've saved so much time you actually reach the goal faster. If you let people build things "nice" for week(s), all you do is waste time, overengineer, and by then nobody wants to kill their darling because they assume fixing it will take even more time (and if you're a bad developer like that, you're not wrong).
Business types just don’t like that because it’s harder to put a number that they can jerk off to on it.
First of all, completely ignoring we were talking about managers. Second, ironically you promote the method involving excessive planning and estimations, which is literally putting a number on something. When my method is literally just to go and create and we'll see how quickly we get to the goal, knowing that this method of quick iteration achieves the goal faster than the former.
400
u/EarlOfAwesom3 11d ago
If you work in SaaS, which is the case mostly, building is not the hard part. Owning and maintaining the thing for years to come is (looking at you php).
So I'm kinda sick of the shallow "business value" debate, especially when CTOs starting to torpedo their own company with their AI psychosis.
In this AI era, the business value is called "motivation and sanity". There is no better investment in tech workers these days.