4 ms·

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 cau

by 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.
mcv 10y ago
If Scotty didn't confirm that it's important enough to risk serious damage, he didn't do his job. His job is not to blindly trust the captains omniscience, his job is to inform the captain of the technical consequences. If warp 9 in 15 minutes is preferable to taking damage, than that's the better option. In the example with the line of code that took 6 days, there was no dramatic emergency in production that required cutting corners. If it had been an emergency, of course the code refactoring demanded in code review should have been postponed; those changes increased the impact of the change, and therefore the resting requirements. And if it really is an emergence that requires people to drop what they're doing, then someone with sufficient authority should be directly involved in order to override all the usual procedures. But you don't just drop all procedures just because somebody claims somebody said something. That would be dangerously irresponsible.

by raldi 10y ago

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.

mcv 10y ago

If Scotty didn't confirm that it's important enough to risk serious damage, he didn't do his job. His job is not to blindly trust the captains omniscience, his job is to inform the captain of the technical consequences. If warp 9 in 15 minutes is preferable to taking damage, than that's the better option. In the example with the line of code that took 6 days, there was no dramatic emergency in production that required cutting corners. If it had been an emergency, of course the code refactoring demanded in code review should have been postponed; those changes increased the impact of the change, and therefore the resting requirements. And if it really is an emergence that requires people to drop what they're doing, then someone with sufficient authority should be directly involved in order to override all the usual procedures. But you don't just drop all procedures just because somebody claims somebody said something. That would be dangerously irresponsible.