|
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.
|
|
|
|
|
That's a very helpful comment, thank you.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
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  ] 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.
|
|
|
|
|
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.
|
|
|
|
|
Quote: My development colleague is a strong proponent of getting it done cheap and dirty
I'm also one of these 
The other side is, do everting clean and structured until you get lost in the so called 'clean code'.
I think I know both sides, and one has to make then and when a compromise 
.. and: nobody pays you for clean code...
|
|
|
|
|
0x01AA wrote: .. and: nobody pays you for clean code...
Nobody pays you twice for code that breaks all the time either. 
Jeremy Falcon
|
|
|
|
|
0x01AA wrote: .. and: nobody pays you for clean code...
Yes they do, when something is so damned wrong, that they me to do it right. 
Already happened me several times in my career (2 of them even were projects previously done by someone of the same company)
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.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
