4 ms·

This makes a lot of sense - but how? By definition, management does a different job from individual contributors. How do you make a manager feel the pain of a m

This makes a lot of sense - but how? By definition, management does a different job from individual contributors. How do you make a manager feel the pain of a messy code base, for example?

therealdrag0 3y ago
If your edge manager doesn’t understand the value in clean code then you’re screwed. However that doesn’t mean it will be invested in. Clean Vs messy are binary descriptors that devs love to throw around. A lot of time messy code is not worth fixing. Managers have to make judgement calls. But what they should always let you do is marginally improve the code each time you’re in it, and especially let you invest in test coverage.
ipaddr 3y ago
Making changes take longer. This will take 6 months today or 2 months in clean code base
- max_hammer 3y ago
  How much time it will take to get to clean code base ?
Aeolun 3y ago
The pain is indirect. They’ll just see tons of failed production deployments, rollbacks, client calls, defect rate, delivery rate etc. Somehow you have to make it clear to them that yes, all of that, is caused by the message they send out every single day, reminding people to focus on delivering all promised features today. Like some IT version of ‘the whippings will continue until morale improves’.
- BigJono 3y ago
  > all of that, is caused by the message they send out every single day, reminding people to focus on delivering all promised features today. More realistically it was caused by those messages, but with a 4 year lag time, back in the days when the CTO decided to start the project from day 1 with a team of "senior" consultants that were all "full stack" and "excited to learn AWS".
gryn 3y ago
- Very long time to implement new features and even more time to change existing ones. - bugs that customers complain about. When asked for why you can explain how the messy codebase is causing problems and how there no bypassing it. I've seen this in a big medical equipment company where the CEO made a whole speech about how he now understands how legacy codebase is making our work very difficult, it caught me by surprise to see a C level bring up the topic.
al_borland 3y ago
I have management introducing unnecessary operational work into what would otherwise be a fully automated process. The code for it being fully automated is already written, it works, and worked in production for a year with 0 issues. They told me to remove it as a means of them controlling things. Anytime there is an issue with the artificial controls they asked for, I have everyone go to said management to get approval. This not only lets them feel some pain, but it causes huge delays in the process, which makes their entire product look bad. I'm also looking to throw the operational work back on the manager and his people. My goal is to annoy them into changing course while I don't do any extra work. If they want to make stupid rules that create work, they can be the ones to do that work and deal with the fallout. I'm not going to act as an enforcement arm for rules I don't agree with or understand.

This makes a lot of sense - but how? By definition, management does a different job from individual contributors. How do you make a manager feel the pain of a messy code base, for example?

therealdrag0 3y ago

If your edge manager doesn’t understand the value in clean code then you’re screwed. However that doesn’t mean it will be invested in. Clean Vs messy are binary descriptors that devs love to throw around. A lot of time messy code is not worth fixing. Managers have to make judgement calls. But what they should always let you do is marginally improve the code each time you’re in it, and especially let you invest in test coverage.

ipaddr 3y ago

Making changes take longer. This will take 6 months today or 2 months in clean code base

max_hammer 3y ago
How much time it will take to get to clean code base ?

Aeolun 3y ago

The pain is indirect. They’ll just see tons of failed production deployments, rollbacks, client calls, defect rate, delivery rate etc. Somehow you have to make it clear to them that yes, all of that, is caused by the message they send out every single day, reminding people to focus on delivering all promised features today. Like some IT version of ‘the whippings will continue until morale improves’.

BigJono 3y ago
> all of that, is caused by the message they send out every single day, reminding people to focus on delivering all promised features today. More realistically it was caused by those messages, but with a 4 year lag time, back in the days when the CTO decided to start the project from day 1 with a team of "senior" consultants that were all "full stack" and "excited to learn AWS".

gryn 3y ago

- Very long time to implement new features and even more time to change existing ones. - bugs that customers complain about. When asked for why you can explain how the messy codebase is causing problems and how there no bypassing it. I've seen this in a big medical equipment company where the CEO made a whole speech about how he now understands how legacy codebase is making our work very difficult, it caught me by surprise to see a C level bring up the topic.

al_borland 3y ago

I have management introducing unnecessary operational work into what would otherwise be a fully automated process. The code for it being fully automated is already written, it works, and worked in production for a year with 0 issues. They told me to remove it as a means of them controlling things. Anytime there is an issue with the artificial controls they asked for, I have everyone go to said management to get approval. This not only lets them feel some pain, but it causes huge delays in the process, which makes their entire product look bad. I'm also looking to throw the operational work back on the manager and his people. My goal is to annoy them into changing course while I don't do any extra work. If they want to make stupid rules that create work, they can be the ones to do that work and deal with the fallout. I'm not going to act as an enforcement arm for rules I don't agree with or understand.