[hifycycyv]

That's a nice story but at my company management actively discourage all forms of code hygiene. The only thing they care about is code shipped. It comes down to a perverse set of incentives from the csuite but it 100% has zero to do with developer articulation.

Nobody gets in shit for telling their developers to code faster.

Lots of risk telling them to fix the underlying issues so they can ship faster in the future.

[xyzelement]

I am not sure you totally understood my point.

"Code hygiene" is not a goal but the means to a goal. The reason hygiene is good is that ideally should (1) enable you to ship faster and (2) have fewer bugs so you can focus on shipping the next thing instead.

So then there's two options - if your hygiene doesn't give you (1) and (2) then it's pointless. On the other hand, if you do have a velocity issue because of bad hygiene, then that sounds in line with your c-suite concern.

"hey boss, our code needs to be more hygienic" - nobody cares.

"hey boss, we are at 10% of possible velocity because of issues X,Y,Z, and we can be 10X faster if we take a month to fix those" - now they are listening.

[koonsolo]

Hey, I fully agree with your original post and this one, but I wanted to present to you a crazy example I experienced years ago.

So we offered a solution to our customers, and then we could customize this by offering our own "consultant" developers. In the end, each developer had a goal to be "80% of their time billable".

Now we sometimes had to write these things called "channels", which took about 2 weeks to write. If we would have rewritten the framework behind it (which would take about 2 weeks) we could have probably sped up writing channels to less than a week! The thing was, nobody really cared if it took 2 weeks or less than a week, since the customer paid for it. My statement of 'let the customer pay for the 2 weeks anyway' never got hold (that would have probably resulted in some accountant fraud I guess, the way they set up the contract). So anyway, nobody was willing to invest this 2 weeks refactoring that would almost instantly pay itself back.

We were writing channels all the time, and it always felt like such a waste.

Sometimes in corporations, you can end up in the most crazy situations. I've seen plenty.

[m463]

until turnover is high.

Maybe it is like those restaurants with dirty bathrooms. Most customers don't care, and if you get some minimum customers management thinks a bathroom makeover won't matter.

[lazyasciiart]

Turnover at my company is through the roof and management just moves on to other companies as well. New management people are just as reluctant to believe devs saying "well, this code is a pile of shit and so no we really shouldn't be all-in on quickly releasing your favorite new feature".

[rewmie]

> until turnover is high.

You're making it sound like having someone quit is a blocker. Some managers see that as shedding the dead weight, and keeping in the guys who are the team players with endurance. The guy who complains about code quality suddenly leaves and all of a sudden there are no more complains about code quality, and worst case scenario you have new joiners trying to onboard and cause a good impression who don't care if code is shit because their goal is to shine.

How did you solved that problem?

[MichaelZuo]

It's self correcting as customers will move to the competitors over time.

If it's one of the few business that has an absolute monopoly over a certain sector in a country, then the country will gradually weaken over time, until eventually it won't be able to resist a foreign competitor.

Or at least that's what market theory suggests. Of course the period of 'self-correction' could take a few months to a few centuries to fully play out, and simultaneously overlaps with all other market participants.