You can ignore it, tie it to unrelated company initiatives, or feign ignorance and simply not offer solutions that add to it. Or… you can adopt more above-board techniques such as Crawl/Walk/Run and the Reverse Farmer’s Rule, which reframe projects so that confronting tech debt is an upfront part of the plan.
Is it even ethical to begin with to sincerely assist a company to accomplish what it is trying to do? It seems like it would be more ethical to prioritize your own interests if the company isn’t itself altruistic.
I sometimes add a “tax” to the estimates of unrelated tasks, and use the extra hours to work on tech debt, unbeknown to upper management.
Not particularly ethical on my side, but… I’m the one that gets paged when things break down at night or on weekends, and I don’t care that upper management doesn’t care about that.
Refactor first to make the work easy, then do the work.
Ah, good old guerilla development
Is it really unethical if it benefits the organization? Even if that’s not really the goal.
Is it really unethical if it benefits the organization? Even if that’s not really the goal.
The blogger acknowledge that the use of the word “unethical” as a hyperbole ton drive engagement.
The real-world issue is that we need to get stakeholders on board with the idea of having to do extra work that is not required to deliver a feature. If you tell a manager that you need to spend a month rewriting a system that was just launched, they will laugh at you.
I work for the absolute LAZIEST engineering manager I have ever known right now. Like dude has Ages of Empires open on his desktop all day at work. He is last remaining engineer from a team long ago that created the wireless technology that put us on the map. This was maybe 15 yrs ago, he was obviously the dumbest member of that team because he is secretly hiding the fact that he can no longer get the original source code to compile and he is slowly running out of ways to bullshit around it. We are now owned by a VC so upper management could not care less, but this guy creates tech debt out the wazoo! Him and the 20 yr old EE make changes to firmware, PCBs, mechanical designs CONSTANTLY and dont document any of it. it is crazy. They break production all the time. Nothing is documented, basic assembly, programming and test documentation for production is a decade old, if it even exists. They just do not give a shit, the engineering manager is already checked out, and his protege has never even seen what a good company looks like, or what engineering design control is. I feel really bad for whatever company gets suckered into buying us as that is the only concern of the VC, cut costs (primarily labor by laying a bunch of people off) as much as possible to make the company look good. Whoever buys us is going to be in for huge surprise! lolol
Technical debt is very real and can complete fuck companies.lol sorry for you, how do you cope working in that environment?
They pay me well, I get to work on things I enjoy and my boss doesn’t actually manage anything so I can kind just do my thing and no one bothers me. Not sure how solvent the company will be so I’m just riding it for now. But it sucks. I fucking hate my boss, not to mention he is magat asshole.
Staying is more fun than interviewing.
Technical debt is very real and can complete fuck companies.
Even though the situation you described is unfortunate, I don’t think it has any relationship with the concept of technical debt.
The term “technical debt” conveys the idea that a resource is invested in a way that requires to be repaid later. The whole concept revolves around the idea that taking shortcuts doesn’t eliminate the need to actually do the work to make things then right way. Rushing to a deliverable can leave a mess in your wake, but cleaning up that mess is also work that needs to be done and doesn’t magically go away.
It is the VERY CONCEPT of technical debt! Shortcut after shortcut shortcut… The company is literally shortcuts all the way down. No left at the company even knows how to work the erp properly. Because the person who set it up and customized it didn’t document or train anyone and then left… Technical debt. How about the mountain of product SKUs that were forced out the door never properly tested, filled with bugs and zero documentation… Left of the next guy… Technical debt. What about all those products not having real assembly or test documents and there being a literal single guy that knows how to test and program everything? No way to pass that info on besides a mountain of manufacturing engineering work? Technical debt.
What are you talking about dude!?!? Lolol.
No left at the company even knows how to work the erp properly. Because the person who set it up and customized it didn’t document or train anyone and then left…
That’s not technical debt. That isn’t even the definition of legacy code. That’s a mess and a whole set of problems, but technical debt ain’t one of it.
To me it sounds like they took a lot of shortcuts and everyone from the team, barring the last engineer standing, were driven away by the looming Mount Debt
I ended up on a project to integrate an HR system with Active Directory.
Did we technically have to insist that the HR system became the source of truth and we would never make manual changes on the AD side? No.
Did we have to use the new integration and automated new hire account creation process to punish the managers who kept trying to get new hires processed at 4pm Friday to start Monday, claiming no way to rush the processing so the previous “rule” about lead time was now set in stone? No.
Did the integration actually force the reorganization of our Active Directory to clean up a decade of band aid fixes layered on top of each other? No.
Did we have to finally implement a proper data retention process including deletion of former user accounts and mailboxes for the integration to work, along with formal methods to request temporary access to old mailboxes that included an automatic time limit? No.
Did my boss and I use it as a golden opportunity to push all of the above and more into official standards, saving an absurd amount of man hours since? Fuck yes.
Not all of it was tech debt, sure, but in short you should use a available opportunities to improve as much as you can, instead of always defaulting to “I do exactly what was requested”. If for no one else, do it to save yourself pain in the future.
Useful insight that some MBA types consider debt to be a good thing, so it makes sense to use a different term than technical debt. “Operational drag” doesn’t quite hit the mark though, IMO.
Seems like another example where the people making decisions are not qualified to make those decisions.
Thanks. I actually learned something reading this.
