3 ms·

It sucks when you say it like the title: "6 days to change 1 line of code", But... The system improved in a few other ways: 1. The setting became configurable

by bsuvc 3y ago

It sucks when you say it like the title: "6 days to change 1 line of code", But... The system improved in a few other ways: 1. The setting became configurable via the parameters table instead of being hard coded. 2. Auditing was introduced to track changes to that setting. I'm not trying to defend bureaucracy, because I truly hate that aspect of large organizations, but just point out that additional value was created during those 6 days beyond what was originally set out to be achieved. Incidentally, this is why you have to bake in a set amount of overhead into your estimates, and need to take this red tape into consideration if you do story pointing.

ebiester 3y ago
Step 1: determine true priority. How long can this take before it affects jobs? Everyone needs that in mind. If a week won’t affect anyone’s jobs, follow the process or minimally alter it. If people are on furlough because of IT, you have everyone needed in the same room (physical or virtual) until the problem is solved. We don’t have that context here. But if Ed and the entire chain doesn’t have that context, That’s a system failure. The senior would likely just insist on a second ticket to fix it right after if he knew someone’s rent check was on the line. (And if not? That’s also a management issue to solve.)
- bsuvc 3y ago
  That's a good point. The urgency of this problem was not communicated broadly enough and the impact of the simple fix was not communicated back up the organization so that it could be prioritized correctly. It seems like Ed is just being "helpless" and blaming the organization when maybe he could have raised the issue back up to the president saying "my 1 line of code fix to your problem is being blocked by these people. Can you help?" This was a communication problem as much as anything.
pif 3y ago
> It sucks when you say it like the title: "6 days to change 1 line of code" Which just states the fact. > The system improved in a few other ways Which were not required.
- bsuvc 3y ago
  I think I agree with you, but to play devil's advocate: > Which were not required Sure they were not required by Ed, but they were required by other stakeholders who are responsible for testing and maintaining this system. I agree though, it would be frustrating to get into this sort of "yak shaving" situation where you don't even care about all these other requirements that are being added. Like I said in a sibling comment, this is really more of a communication problem on Ed's part, and maybe he could have neutralized all these problems with better communication.
  - idlewords 3y ago
    Sounds like Philip should have laid off a few people in IT management.
yuliyp 3y ago
The only reason the parameters table would be useful is because making changes to the code had so many things blocking it. Similarly, auditing for this sounds unnecessary because it used to be in code which means that you had source control as your audit trail. So your two wins were basically a "win" of not dealing with extra ceremony around code changes, followed by a "win" of recovering the functionality loss of the first "win" because future changes to this wouldn't go in the code.
axpy 3y ago
Yes but it also did something that is potentially way more dangerous than the original ask. I would argue that pushing a parameter from a hard-coded value during an immediate outage or real production concern is stupid. There are way more potential pitfall there. IMO, This should have been handled with a: OP: Please accept the 1 char PR, this is urgent. I just created a ticket to track the requested enhancements. Let's address production concern first then then I will get the rest after. Reviewer: LGTM! This is actually where seniority pays, if most of your engineering base can't navigate between rules and guidelines, the organization is crazy.
- mesarvagya 3y ago
  This. If it is a production issue that needs to be fixed, fix it fast with priority and create another ticket to take care of reviewers comments.
omoikane 3y ago
Auditing requirements could have been covered by version history for the file containing that hardcoded value, I think? They would have other problems if they didn't have version control.
cjalmeida 3y ago
And it just cost 6 x 10% x $MM worth of daily products! /s

by bsuvc 3y ago

ebiester 3y ago

Step 1: determine true priority. How long can this take before it affects jobs? Everyone needs that in mind. If a week won’t affect anyone’s jobs, follow the process or minimally alter it. If people are on furlough because of IT, you have everyone needed in the same room (physical or virtual) until the problem is solved. We don’t have that context here. But if Ed and the entire chain doesn’t have that context, That’s a system failure. The senior would likely just insist on a second ticket to fix it right after if he knew someone’s rent check was on the line. (And if not? That’s also a management issue to solve.)

bsuvc 3y ago
That's a good point. The urgency of this problem was not communicated broadly enough and the impact of the simple fix was not communicated back up the organization so that it could be prioritized correctly. It seems like Ed is just being "helpless" and blaming the organization when maybe he could have raised the issue back up to the president saying "my 1 line of code fix to your problem is being blocked by these people. Can you help?" This was a communication problem as much as anything.

pif 3y ago

> It sucks when you say it like the title: "6 days to change 1 line of code" Which just states the fact. > The system improved in a few other ways Which were not required.

bsuvc 3y ago
I think I agree with you, but to play devil's advocate: > Which were not required Sure they were not required by Ed, but they were required by other stakeholders who are responsible for testing and maintaining this system. I agree though, it would be frustrating to get into this sort of "yak shaving" situation where you don't even care about all these other requirements that are being added. Like I said in a sibling comment, this is really more of a communication problem on Ed's part, and maybe he could have neutralized all these problems with better communication.
- idlewords 3y ago
  Sounds like Philip should have laid off a few people in IT management.

yuliyp 3y ago

The only reason the parameters table would be useful is because making changes to the code had so many things blocking it. Similarly, auditing for this sounds unnecessary because it used to be in code which means that you had source control as your audit trail. So your two wins were basically a "win" of not dealing with extra ceremony around code changes, followed by a "win" of recovering the functionality loss of the first "win" because future changes to this wouldn't go in the code.

axpy 3y ago

Yes but it also did something that is potentially way more dangerous than the original ask. I would argue that pushing a parameter from a hard-coded value during an immediate outage or real production concern is stupid. There are way more potential pitfall there. IMO, This should have been handled with a: OP: Please accept the 1 char PR, this is urgent. I just created a ticket to track the requested enhancements. Let's address production concern first then then I will get the rest after. Reviewer: LGTM! This is actually where seniority pays, if most of your engineering base can't navigate between rules and guidelines, the organization is crazy.

mesarvagya 3y ago
This. If it is a production issue that needs to be fixed, fix it fast with priority and create another ticket to take care of reviewers comments.

omoikane 3y ago

Auditing requirements could have been covered by version history for the file containing that hardcoded value, I think? They would have other problems if they didn't have version control.

cjalmeida 3y ago

And it just cost 6 x 10% x $MM worth of daily products! /s