|
Wordle 1,129 4/6*
🟨🟨⬛⬛🟨
🟩⬛🟨🟨🟩
🟩🟩⬛🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,129 4/6
⬜⬜⬜⬜🟩
⬜🟨⬜⬜🟩
⬜🟩⬜🟩🟩
🟩🟩🟩🟩🟩
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
Oooh. That's just mean. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: Oooh. That's just mean.
I call it Karma  
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!😂
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
