|
it all comes down to money.
you'll have to make the case that his ways are costlier.
Show him the CrowdStrike mayhem because it was caused by a null pointer dereferencing ( as far as I know)
good luck.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
Maximilien wrote: you'll have to make the case that his ways are costlier.
Depends. If you spend your career only doing things the wrong way, yes. Then it'll take a while to correct it. But like anything, if you get used to doing things the right way that will eventually get quicker as well. Anything you do a lot of, you get better at. That includes coding like crap or not.
I say this knowing that when I usually see tech debt, it's not a missed feature and more do to with the quality of software being released.
Jeremy Falcon
|
|
|
|
|
There is no such thing as technical debt; only opportunities to improve.
|
|
|
|
|
Richard Andrew x64 wrote: Any tips on how you think I could address this point with him?
People are who they are. Remember, people make choices based on emotion (even if they're not in touch with emotions) and then rationalize that choice with logic. Which means, you cannot logic your way into convincing anyone of anything. At best he'll go along with it to placate you, but his heart and soul won't be in it when it comes to tech debt.
Anyway, some people just don't care. They'll let their hygiene go. Their house will be a mess. And so on. Some people just don't care enough to care about quality in anything. Or, he's too afraid of management to tell them the truth and just got used to half-arsing his career rather than communicate with the uppers. The business side loves communication. Either way, it's a personality issue. So, good luck changing that.
That being sad, there are times for quick and dirty. Say for a once or twice used ancillary script. But, never for the main product your job relies on. Yes there are times you haven't a choice, but that should be the exception and not the norm. So, if your tech debt backlog never clears out and it's not the fault of management, it's a personality issue. Which is almost impossible to change.
If you need proof, just watch how many people will defend having a never ending list of tech debt... with the "good enough" mantra. These are the same peeps that hate unit tests. 
The best you can do is be a good example and explain your whys if asked. Maybe he'll feel left out and change or you'll make him look bad. Either way, you win. But, giving him a bullet point trying to convince him of something won't get too far.
Jeremy Falcon
modified 21-Jul-24 22:37pm.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Richard Andrew x64 wrote: Any tips on how you think I could address this point with him?
With a blunt object? 
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!
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
lol, I just did something cheap and dirty.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
|
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.
|
|
|
|
|
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;
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
As the sign in a print shop says: You can have price, quality and speed--pick two.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
I'm going to ride your comment instead of the top level because yours is the antithesis in a sense and it's why I don't want to really argue for the one I'm about to make, but recognize its cogence all the same.
If you don't worry on it and you let things run amuck for a long time, it *might* be easier to argue for that rewrite/tech facelift you're going to very much want in 5-10 years. When you greenfield it and it comes out of the gate as pristine and maintainable, the ROI in support/feature tickets will be apparent. Sure, it would be apparent if you rewrote bits of it last week too, but...
|
|
|
|
|
Matt Bond wrote: use good architecture/inheritance/coding concepts (DRY, SOLID, encapsulation, etc.),
Except that all of these things can be done to excess. Too often I've waded through ponderous codebases that have unnecessary levels of abstraction, or encapsulation (getter and setter provided for the same attribute - why not just make the attribute public). I think these things have a U curve of complexity/cost tradeoff - some of these things are useful/necessary, but more of a good thing, is not necessarily a good thing.
Matt Bond wrote: Keep all things as simple as possible, but no simpler. -said someone, somewhere
Exactly
|
|
|
|
|
You don't have to worry (so much) about technical debt if you are never going to update a program once it's delivered. If it's going out on a ROM for a video game or it's the landing program for a Mars rover, it's either good enough or not, but you'll never update it.
On the other hand, if you're deploying every day, like for a web-based business, then you're always maintaining code, and technical debt is a killer.
The way you make someone care about technical debt is to make them responsible for it. Reviewing module tests to ensure they cover the whole interface is one way. Making the person who submitted the broken code fix it is another way. A third way is to show managers that repairing tech debt after a bug is reported is more expensive than taking the time not to insert it in the first place. Technical debt is compound interest. It makes everything more expensive. If you're in a continuous maintenance cycle, it will eventually choke you. You'll have to staff up again and again to fight the growing mountain of debt. It's a business-killer.
|
|
|
|
|
There’s a difference between technical debt and shoddy work.
If the code is not written such that it’s stable and bug free,then it shouldn’t be rolled out.
If it’s merely missing features or ‘could be’ written to be more efficient, then rewrite it when doing some enhancements or bug fixes in the area.
Adages such as
‘If you don’t have time to do it right, when will you have time to do it over?’ (referenced by @GregUtas) and
‘Fast/cheap/right: pick two.’ come to mind, but it’s near impossible to change the mind of someone entrenched in their thinking.
Good luck,
Time is the differentiation of eternity devised by man to measure the passage of human events.
- Manly P. Hall
Mark
Just another cog in the wheel
|
|
|
|
|
The proper way to deal with it is to make accommodations in the project schedule. However, the corporate big wigs probably won't want to understand that technical debt is inevitable in any software project, and to protect their bottom line, they'll insist that time allocations to resolve it be removed, and thus, it lives on in the software.
This problem becomes apparent when a "dev lead" insist that the latest wiz-bang framework is implemented in the software with no team experience in said framework, and the team implements code without a full understanding of that framework until somebody has an "ah-ha" moment and realizes that "we should have done it this way". This "ah-ha" moment leads to a mid-stream change of direction in implementation, usually meaning that existing (tested and approved) code is left in its current state, and all new dev going forward uses the "ah-ha" strategy, instantly creating technical debt to bring the now "legacy" design" into alignment. This alignment technical debt that will never be addressed because corporate doesn't want to approve the tasking because the the old code "works", disregarding the obvious advantages of doing so with regards to future maintenance.
This is what we in the business of writing code call a "cluster-f*ck".
We're experiencing that in our code base right now. Someone (before I was employed) decided it would be a good idea to use React for our app, and nobody on the team had *any* experience with it. Add to that several assumptions being made about the project (converting an existing Oracle Forms app to a web app), and we have a couple of "ah-ha" variations of our "framework" code to deal with, as well as an impending 3rd derivation. It never ends.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
