Re:Code quality: a concern for businesses, bottom lines, and...
by goostavos on Wednesday October 20, 2021 @02:29PM
(#28934222)
>when discussing code quality there was almost never consensus regarding what's good and bad.
FWIW, I've found that the best way to approach dragging a team in a new direction is to not focus on what "quality" is at all, but see if everyone can agree on what the problems are.
I think if you can get people aligned on the problems -- specifically high level 'above the code' ones like "X keeps breaking" or "X is really hard to change" -- you can sneak quality into the discussion without it being an attack on any individual developer's code. "why is X hard to change" can become a conversation about loose coupling, cohesion, state, etc..
> - Code quality is quite subjective and the field is driven by opinions and fads.
Agree. In almost every team I have been part of, when discussing code quality there was almost never consensus regarding what's good and bad.
Besides, in almost every company I have worked for, modules (or products) were usually refactored after 3 years or so (as in: the code that deals with retrieving data from the DB remains almost intact, but everything else is moved out to its own repository: the frontend as microfrontend and a new in-between layer (call it a proxy or "backend for frontend"))... so there was never a huge motivation to write quality code, just to write "good enough" code.