3 ms·

>> But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the lon

>> But often they get stuck on fixing whatever the most recent thing that bothered them about our code rather than on what actually impacts customers in the long or short term. One company had a homegrown debug protocol and tool to interface with it. I needed to add some custom info screens for development, but it was very hard to add because the code was $h!t. So I started fixing it just to be able to add my new data. Not only was I told that Work should be "managed" and prioritized, it was later discarded even though I had done it. When programmers do things to "make the code better", it may not have an impact on today's customer demands, but it is meant to make the programmers more efficient in the future. This is stuff that will - by definition - Never be a priority in management's eyes.

subharmonicon 4y ago
> This is stuff that will - by definition - Never be a priority in management's eyes. I'm not sure why you think that is "by definition" not a priority. Of course it is if it's impacting being able to do new work that adds value. The question is, is that a priority at the moment it's noticed, or something that should be added to a backlog to be addressed later? If it's a small amount of code clean-up, it's usually easy to squeeze into current work without disruption. We always try to refactor as we go along. If it's "This 3000 lines needs to be redesigned and rewritten", it really amounts to feature work and should be added to a backlog and prioritized along with all the other work. The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important.
- phkahler 4y ago
  >> The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important. Sometimes that new person is wrong, buy often there is truth in their assessment. If they're right that they've walked onto a bunch of garbage then their desire to fix it immediately is IMHO the correct thing to do with the exception of making critical (meaning contractual) deadlines for a customer. The time to fix a disaster is when someone has that intrinsic motivation to do it.

subharmonicon 4y ago

> This is stuff that will - by definition - Never be a priority in management's eyes. I'm not sure why you think that is "by definition" not a priority. Of course it is if it's impacting being able to do new work that adds value. The question is, is that a priority at the moment it's noticed, or something that should be added to a backlog to be addressed later? If it's a small amount of code clean-up, it's usually easy to squeeze into current work without disruption. We always try to refactor as we go along. If it's "This 3000 lines needs to be redesigned and rewritten", it really amounts to feature work and should be added to a backlog and prioritized along with all the other work. The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important.

phkahler 4y ago
>> The phenomenon I'm talking about is ICs seeing something for the first time, and then deciding that must be the priority because it's so bad, and dropping everything else to fix that thing even if it's weeks worth of work. They see what's in front of them as the thing that's most important. Sometimes that new person is wrong, buy often there is truth in their assessment. If they're right that they've walked onto a bunch of garbage then their desire to fix it immediately is IMHO the correct thing to do with the exception of making critical (meaning contractual) deadlines for a customer. The time to fix a disaster is when someone has that intrinsic motivation to do it.