6 ms·

I think the linked thread is good example, changing 3 to 4 can seems minor, but i think even with rules in place, it is not a burning 'fire', it should be easil

I think the linked thread is good example, changing 3 to 4 can seems minor, but i think even with rules in place, it is not a burning 'fire', it should be easily acceptable to run this with rules enforced in a day or two. Letting people to override rules is more damage in long run for sure. Maybe they would override next time when they shouldnt

raldi 10y ago
Sorry, but you don't get to make that call; it's the CEO's job, and the CEO said it needed to be done immediately, not in "a day or two".
- switchbak 10y ago
  Having read that article, I do agree - but the requested change, while being "one line", could have unforeseen consequences that could also have a very negative effect on the business. I'm thinking that the CEO wouldn't take the blame for that though. But if people's jobs were truly on the line, I'm inclined to agree with the "screw it, push it through" approach.
- didibus 10y ago
  I wholeheartedly disagree. In fact, I believe that's the difference between an engineer and a programmer. If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." You don't just change a 3 to a 4 because the CEO wants you to. You have to make sure the change doesn't come with unforseen impact that would put the company at risk, and you have to make the change in a similar way. That's what the CEO expects also. If you did the change, and it had caused impact to the business, that you had not pointed out, and for which the business believe is more harmful then having waited a few more days, you and only you are to blame, and you will be. You can't say, but CEO told me, you're the engineer, you're the person they hired to know this stuff and prevent these issues from happening, not the CEO.
  - raldi 10y ago
    I'm not sure we're actually in disagreement. If Captain Kirk tells Scotty, "We need warp 9 in five minutes or we lose the ship" and Scotty cuts corners that cause a decompression explosion that kills twenty redshirts, then yes, that would probably be an example of bad engineering management. But if Scotty delivers on time at the cost of overloading an expensive piece of equipment that, after the battle is won, requires a week in drydock to replace, that's probably a successful execution of exactly the kind of call a senior engineering manager is expected to make.
    - mjevans 10y ago
      It always amazed me how little Star Trek used robots, even just remote arms, to do things. (Yeah, it's a side-effect of it being made for TV)
      - Natsu 10y ago
        Trek wasn't made for logical consistency. They could duplicate Riker with a transporter accident, but they couldn't make another Data that way, they had an entire episode about deconstructing him, then another about him constructing a 'child' robot.
    - didibus 10y ago
      Could be we don't, most disagreement is miscommunication. In your example, Scotty knew what he was doing though. He didn't say, wow, what Kirk wants me to do could kill twenty redshirts in the process, I'll just take the gamble since he seems to want me to. He knew exactly the impact, and made it knowing he would easily be able to contain it. Which is often not the case in Software and in practice. You have to do something to know the impact, because most problem we solve is always new. Its not something we did many times before. If that variable was often changed, then it would be completely different, because he'd known, just like Scotty, that its something they can do. In that case you can make the choice to say, lets change it, and later handle the tech dept of the less maintainable code. Also, in software, its almost never the case that people can't wait a few more days.
    - 10y ago
- user5994461 10y ago
  Sorry, the CEO's job is not to talk about nitpicky technical details. He's got no voice in what a code or a test should be.
- bluesign 10y ago
  Ok this is the problem with story telling tbh: David: It's for Philip. It we don't do this right away, we'll have to have a layoff. and Judy: OK, then I'll fill out that section myself and put this on the fast track. ----- 2 days later. ----- David: What's the status of 129281? "It we don't do this right away, we'll have to have a layoff" and "2 days later", making an impression of this is an "a day or two" task, not a "fire/emergency" I don't think if this change finished in 2 days anyone will be unhappy. But if you took this to production, and somehow failed, everyone would blame QA/testing
ZeroFries 10y ago
The ideal solution is neither always enforce the rule nor always permit lapses. Are you saying you don't think human beings are capable of coming close to that ideal solution?
- lotyrin 10y ago
  In my experience, no, they cannot exercise judgment and an absolute system has to be in place. In theory, could informed, intelligent, rational actors without ulterior motive do so, sure. I'd sleep on a couch and eat ramen for the chance to be part of such a team, but I haven't met them.
snovv_crash 10y ago
Those rules that were overridden were basically QA bikeshedding about variable names in something that has never changed before, and insisting on tacking on refactoring while trying to put out fires. The engineer did their due diligence, wrote tests to make sure it had the desired behaviour, and got it done in minimal time. Clearing technical debt in old modules should be done, I agree, but not while trying to put out fires. It adds considerable risk to a change which should not have any impact except for the request.

raldi 10y ago

Sorry, but you don't get to make that call; it's the CEO's job, and the CEO said it needed to be done immediately, not in "a day or two".

switchbak 10y ago
Having read that article, I do agree - but the requested change, while being "one line", could have unforeseen consequences that could also have a very negative effect on the business. I'm thinking that the CEO wouldn't take the blame for that though. But if people's jobs were truly on the line, I'm inclined to agree with the "screw it, push it through" approach.
didibus 10y ago
I wholeheartedly disagree. In fact, I believe that's the difference between an engineer and a programmer. If you are hired as a programmer, then yes, just do whatever we ask of you. But if you are hired as an engineer, everything the business asks of you comes with an implicit: "and make sure it's done in a proper way that won't break anything, or slow us down, or cost us too much, or limit our ability to gain a competitive edge." You don't just change a 3 to a 4 because the CEO wants you to. You have to make sure the change doesn't come with unforseen impact that would put the company at risk, and you have to make the change in a similar way. That's what the CEO expects also. If you did the change, and it had caused impact to the business, that you had not pointed out, and for which the business believe is more harmful then having waited a few more days, you and only you are to blame, and you will be. You can't say, but CEO told me, you're the engineer, you're the person they hired to know this stuff and prevent these issues from happening, not the CEO.
- raldi 10y ago
  I'm not sure we're actually in disagreement. If Captain Kirk tells Scotty, "We need warp 9 in five minutes or we lose the ship" and Scotty cuts corners that cause a decompression explosion that kills twenty redshirts, then yes, that would probably be an example of bad engineering management. But if Scotty delivers on time at the cost of overloading an expensive piece of equipment that, after the battle is won, requires a week in drydock to replace, that's probably a successful execution of exactly the kind of call a senior engineering manager is expected to make.
  - mjevans 10y ago
    It always amazed me how little Star Trek used robots, even just remote arms, to do things. (Yeah, it's a side-effect of it being made for TV)
    - Natsu 10y ago
      Trek wasn't made for logical consistency. They could duplicate Riker with a transporter accident, but they couldn't make another Data that way, they had an entire episode about deconstructing him, then another about him constructing a 'child' robot.
  - didibus 10y ago
    Could be we don't, most disagreement is miscommunication. In your example, Scotty knew what he was doing though. He didn't say, wow, what Kirk wants me to do could kill twenty redshirts in the process, I'll just take the gamble since he seems to want me to. He knew exactly the impact, and made it knowing he would easily be able to contain it. Which is often not the case in Software and in practice. You have to do something to know the impact, because most problem we solve is always new. Its not something we did many times before. If that variable was often changed, then it would be completely different, because he'd known, just like Scotty, that its something they can do. In that case you can make the choice to say, lets change it, and later handle the tech dept of the less maintainable code. Also, in software, its almost never the case that people can't wait a few more days.
  - 10y ago
user5994461 10y ago
Sorry, the CEO's job is not to talk about nitpicky technical details. He's got no voice in what a code or a test should be.
bluesign 10y ago
Ok this is the problem with story telling tbh: David: It's for Philip. It we don't do this right away, we'll have to have a layoff. and Judy: OK, then I'll fill out that section myself and put this on the fast track. ----- 2 days later. ----- David: What's the status of 129281? "It we don't do this right away, we'll have to have a layoff" and "2 days later", making an impression of this is an "a day or two" task, not a "fire/emergency" I don't think if this change finished in 2 days anyone will be unhappy. But if you took this to production, and somehow failed, everyone would blame QA/testing

ZeroFries 10y ago

The ideal solution is neither always enforce the rule nor always permit lapses. Are you saying you don't think human beings are capable of coming close to that ideal solution?

lotyrin 10y ago
In my experience, no, they cannot exercise judgment and an absolute system has to be in place. In theory, could informed, intelligent, rational actors without ulterior motive do so, sure. I'd sleep on a couch and eat ramen for the chance to be part of such a team, but I haven't met them.

snovv_crash 10y ago

Those rules that were overridden were basically QA bikeshedding about variable names in something that has never changed before, and insisting on tacking on refactoring while trying to put out fires. The engineer did their due diligence, wrote tests to make sure it had the desired behaviour, and got it done in minimal time. Clearing technical debt in old modules should be done, I agree, but not while trying to put out fires. It adds considerable risk to a change which should not have any impact except for the request.