How do you deal with technical debt?
-
Oh, just to add to Greg's great post... iterative is the only way to develop. If it's a brand new project or a POC, good code doesn't mean have a full-blown architecture. But, we all know a point in which code becomes crap (zero structure, non-state globals, 50 million packages, etc.). So, even if you iteratively improve on the overall architecture progressively, that's still not a tech debt situation IMO. That's just evolving the app. Tech debt would be more akin to "hacked a CSS alignment because I have no idea why that div is there."
Jeremy Falcon
This is an important point. Successful large systems evolve out of successful small systems that work and are well designed. I've witnessed literally hundreds of millions of dollars flushed down the toilet by groups that set out to build all-singing, all-dancing platforms/frameworks or rewrite large legacy products.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
Is it safe to assume your colleague isn't familiar with Bob Martin? :) At the very least, have him watch episode 1 of this series of 12 videos on writing clean code and what it means to be a professional software engineer. If that doesn't convince him, wish him the best and seek out a better work environment. Seriously. Clean Code with Uncle Bob Episode 1[^] /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
There are times when cheap and dirty is a reasonable approach, like when the spec is churning or when no one has a reasonable idea of what architecture is appropriate. When that's the case, the code should be overhauled once it's finished, unless it miraculously walked the right path. Unfortunately, dealing with this attitude is very challenging. Many developers suffer from it, as do far too many managers. People of this type should have to evolve and support their code going forward, and managers should be accountable for the productivity of their groups when it keeps getting harder to add functionality and deliver quality code. The flip side is positive reinforcement. More people will want to do it right, instead of doing it over, if they hear others being praised for delivering cogent code or fostering a culture of software excellence.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
People of this type should have to evolve and support their code going forward
Definitely!
Greg Utas wrote:
managers should be accountable for the productivity of their groups when it keeps getting harder to add functionality and deliver quality code.
The problem with this is modern management styles. In large organizations, managers are moved around quite a bit (typically every 3 years or so). By the time the effects of their manglement are evident, they've moved on to bigger and better things.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
Any tips on how you think I could address this point with him?
With a blunt object? ;p Seriously though, reminded me of How to Deal with Difficult People on Software Projects[^] He sounds like either the bull in the china shop or the incompetent type. The first one is a medium danger to the project and easy to fix (according to the website) while the second is unfixable and an extremely high danger to the project. Hopefully this can be of help!
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
It took me the better part of 7 years to show that some more time spent in the first iteration of a feature pays off in the long run, not having to rewrite it when specs changed (same features for different customers with different specs).
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
Greg Utas wrote:
People of this type should have to evolve and support their code going forward
Definitely!
Greg Utas wrote:
managers should be accountable for the productivity of their groups when it keeps getting harder to add functionality and deliver quality code.
The problem with this is modern management styles. In large organizations, managers are moved around quite a bit (typically every 3 years or so). By the time the effects of their manglement are evident, they've moved on to bigger and better things.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
By the time the effects of their manglement [sic :-D] are evident, they've moved on to bigger and better things.
That's true, making it harder to hold them accountable. It also happens with developers. Especially in organizations without a technical career path, many developers aspire to management, which allows them to leave their damage behind.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
How about an agreement, in writing, that HE has to deal with all code defects. His AND yours. Code his way and walk away. He'll come around.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
Greetings & Kind Regards May I please inquire the size of these "cheap" and "dirty" solutions. I can not fathom a project of any significant size not quickly becoming a tangle of incomprehensible code if performed in this manner even to the author.
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
lol, I just did something cheap and dirty. :laugh:
CI/CD = Continuous Impediment/Continuous Despair
-
Daniel Pfeffer wrote:
By the time the effects of their manglement [sic :-D] are evident, they've moved on to bigger and better things.
That's true, making it harder to hold them accountable. It also happens with developers. Especially in organizations without a technical career path, many developers aspire to management, which allows them to leave their damage behind.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
lol, I just did something cheap and dirty. :laugh:
CI/CD = Continuous Impediment/Continuous Despair
KSS?
-
Greg Utas wrote:
many developers aspire to management
Not the good ones.
Generally true, though some outfits are too blinkered to pay good developers what they're worth, causing some of them to seek out management positions. This sometimes leads to the loss of good developers who end up being neither happy nor good at managing. I know, because that was me until I found a manager who believed in having a technical career path, which the company later formalized.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Insert a bug in one of his old apps and let him debug it.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
If a decent source control system is in use (surely one will be), the first thing he would stumble on is who created the bug, and when. Good luck with talking your way out of that!😂
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
How do you know it really is technical debt? Most of the time I see on my team people just nagging because they don't want to spend 20 mins reading and understanding the code. No - not every code should be just drop in and understand it in 30sec. Devs on my team also nag about things that were developed 5 years ago and basically no one touches that code - maybe once in 2 years. I don't consider that code tech debt - they just have to spend time understanding it not rewrite something that is barely changed at all. If something is changed and evolving all the time like every month piece of code is updated and it requires 20 mins to grasp it again for someone who also changes it on monthly basis - yeah that is a problem, but then is it code problem or the person.
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
My development colleague is a strong proponent of getting it done cheap and dirty
Cheap and dirty is for code you need once and are going to throw away.
Richard Andrew x64 wrote:
this style incurs a lot of technical debt
Technical debt implies that the code is maintained long term. "Cheap and dirty" is therefore a contradiction in terms. Your coworker is an asshat and should be terminated immediately. This isn't programming style or anything like that. It's unprofessional and unethical.
Software Zen:
delete this; -
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
Its not that easy... I had a project that had been in prod for many years with simple string.split processing on a CSV. This was arguable a cheap and dirty approach that lasted about 8 years. Boss came along and said we had to fix it for a customer. A Co-worker came in and abhorred the cheap and dirty approach. Refactored a TON of the code to do the correct CSV style processing with a tried and true nuget package. Unfortunately his correct method also came with a bug that didn't get caught till late in testing. I asked why he didn't just import the Microsoft.VisualBasic DLL (we're a C# shop) that would have done the parsing with close to 3 lines of code changed. Complaint was about cheap and dirty. Yeah, its one example, but refactoring for pretty and "correct" only works if its correct. We need to replace cheap and dirty with fast with some debt. There is a time and place to just get it done. It takes an experienced dev to recognize this and to just get it done when the time is right.
Hogan
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
Working for a non-profit, I agree with cheap, but I like it clean and simple rather than dirty. Writing everything to use abstractions upon abstractions might be what's taught in school and seems proper, but most of the time it is unnecessary and increases time to debug or modify unless you psychically know what the future might require. I suggest a compromise.
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
I'm near wrapping up a project written in 2003-2008, where it was done cheap and dirty and the level of technical debt is near bankruptcy. These young kids that wrote it during University managed to achieve something that looked decent on the outside, and a disaster on the inside. The customer paid $30K for the program and thought it was a bargain, but didn't know that the code was unreadable, went out of date the day it was finished and could not be fixed. The debt added up to about $350K in 2024 to replace the program done the correct way. To me, it's a subject of due diligence, morality, fiduciary like an investment advisor managing your money, because overall in the end, your managing the customers money or capital investment in their project. So I will call it ideology where proper practices and principles must apply to ensure integrity and durability. Something to think about to support your argument and raise that level of quality.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
My development colleague is a strong proponent of getting it done cheap and dirty, and this style incurs a lot of technical debt. Any tips on how you think I could address this point with him?
The difficult we do right away... ...the impossible takes slightly longer.
Code reviews is how I deal with technical debt. I'm the team lead, so my word probably has more weight than a same-level co-worker. One phrase that I use a lot in code reviews is that "We do good coding here, not just coding that works." I make my team refactor code smells, fix misspellings in variable/class/method names, add comments that explain why something needs to be done that way, remove comments that are self-evident from a single line of code, use good architecture/inheritance/coding concepts (DRY, SOLID, encapsulation, etc.), change variables/classes/methods to have meaningful names, and so on. New hires are usually grumpy they they have a ticket that rolls over because they needed to refactor a bunch of code they just did, but after a while, they start to see how it really helps when the code changes over time. A good example... A new developer did a one-off code change to fix a bug in a few hours. This legacy code was very poorly written to begin with. I told him to rewrite it so it wasn't a one-off anymore. It was a big task to do the re-write (several days). However, the next sprint there was a another ticket in the same area for an enhancement. This new change would have been at least a week's worth of work and full of one-off coding with the old code (and probably buggy as all get-out), but with the new code it was just a few lines. The developer could immediately see that the rewrite was worth the effort as soon as maintenance comes into play.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
