6 ms·

And in my experience when enough people are saying that 'you can't do that' there is an opportunity waiting for you that is proportional in pay-off to the numbe

by edw519 16y ago

And in my experience when enough people are saying that 'you can't do that' there is an opportunity waiting for you that is proportional in pay-off to the number of people asserting that it can't be done. Great thought. Most of my most memorable successes were when others said that something couldn't be done. First you think, "Why not?" Then you think, "What would it take?" Then you figure that you'll never find out for sure unless you try. The reward is compounded by the initial skeptism. Just a few silly examples (any of these sound familiar?): Manager: Shop Floor Control is impossible. Me: Why? Manager: Because the base data is so inaccurate. Me: So? Manager: It would take years to fix all the data. Me: What if we turned in on anyway? Manager: The output would be worthless. Me: Wouldn't it show where the base data was inaccurate? Manager: Yes. Me: Then you could fix the biggest culprits? Manager: I suppose. Me: So turning it on would expedite data fixing? Manager: Yes. Me: So it's not really impossible? Manager: Well... Manager: Bug free software is impossible. Me: What would it take to make is possible? Manager: Nothing. Can't be done. Me: What if we added systems testing to unit testing? Me: And then built rigorous test plans covering almost everything? Me: And then enforced User Acceptance Testing? Me: And allowed nothing into production without passing? Me: Would it be better? Manager: Yes, but we can't afford to do all of that. Me: So, bug-free software isn't impossible, just expensive? Manager: No, it's impossible. Get back to work. Me: Sigh. Manager: A web app is impossible. Me: Why? Manager: Because it depends upon data entered by regular people. Me: So? Manager: People are idiots. They enter wrong data all the time. Me: What if we trained them? Manager: Impossible. They don't work for us. Me: What if we made the software smarter? Manager: What do you mean? Me: Data validation. Me: Data reasonableness based upon rules or history. Me: Crowdsourcing data validation. Manager: The data would still be bad. Me: What would it take to make the data good? Manager: Nothing. Impossible. Me: Sigh.

charlief 16y ago
What if someone said it isn't impossible, but there are big challenges, and based on your skill set, you're likely to fail. It is those kinds of non-glorified situations where perseverance is crucial, but it can also lead to spectacular failure.
- edw519 16y ago
  What if someone said it isn't impossible, but... I'd say, "Impossible != Unlikely" based on your skill set, you're likely to fail It's probably safe to say that almost everyone who ever achieved anything great was also "likely to fail". It comes with the territory. it can also lead to spectacular failure Spectacular failure is to great achievement what striking out is to hitting a home run.
  - MediaBehavior 16y ago
    Isn't the point that "unlikely" is a vague (with negative innuendo)? ...and that a more rational approach is to say, "The value of a possible success" is high enough that it's worth the expenditure of energy to bet the "losing" side of a p = .01 (or whatever)". [of course it's going to depend on who is expending the energy - and who get what portions of the possible success benefits]
  - deleted 16y ago
    [deleted]
d0m 16y ago
I don't want to be harsh, but I really hope you aren't really like that. This is really arrogant and you would hardly gain anything by acting like that. It seems like you are trying to demolish him by proving you are right instead of helping the team growing to a better solution. Manager: A web app is impossible. You: Yeah, I agree that it would be really hard to build, but it would give us great advantages. Manager: Maybe, but we can't trust data entered by regular people. You: Yes, this is a pain to deal with. Fortunately, from my past experience, I learned good ways to cope with that. At the end, everyone agreed that it was well worth the trouble. Anyway, I don't want to annoy you more with that, I know you are really busy. Let me find the project I worked on and let's talk about it later on. So basically, here's your way: Manager: "I'm the manager and I know what to do" You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU" Manager: (Don't like being contradicted by an employee.. even less being told fuck you): "I am right, here's why" You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU" Manager: (Don't like being contradicted by an employee.. even less being told fuck you): "I am right, here's why" [..] You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU" Manager: "No, you fuck you. I'm the manager and you won't win" Here's my way: Manager: "I'm the manager and I know what to do" Me: I know you are the manager and you choose what to do, but as a programmer (and from my experience), I could help you take the best decision. Manager: But I'm still the manager and I WILL CHOOSE WHAT TO DO, not you. Me: Yes, totally. I'll get some facts about xyz and get back to you, so you can choose the best thing for the team.
- charlief 16y ago
  I don't think it is fair to frame it so dramatically. I think you're arguing for strong diplomacy in negotiation, which I completely agree with. You could presume the original dialogue was not indicative of absolutely perfect diplomatic practices, but to say he is extremely arrogant... I would say he is justifiably confident if he has encountered relevant situations many times before and an adequate technical skill set. Either way, to pass any judgement, we're making way too many assumptions. And ultimately, isn't this irrelevant? They are just a few general, entertaining anecdotes. I hope you don't take Dilbert or The Office seriously as well.
  - 16y ago
pmarin 16y ago
Bug free software is impossible The main problem about unit testing is that you only can demonstrate that the software pass all your unit tests not that the software is bug free. Also, your software usually run on top of other layers that you need to trust like the operating systems, VM, BIOS, hardware failures...
- Semiapies 16y ago
  It's a rhetorical bit of three card monte. Note that he seamlessly shifts from pursuing an absolute of bug-free software and instead offers some techniques for reducing bugs, which the manager deems more expensive than the gains they'd offer. Then he conflates "would be better" with "bug-free software" in a bit of snark at the end, and you can almost hear the eye-roll from the manager.
dkarl 16y ago
This is just a case of poor communication, people talking past each other. There's a big difference between the following two questions: 1. Can the proposed idea be implemented as stated? 2. Does the proposed idea degrade gracefully, i.e., will an imperfectly achieved solution provide significant benefit? The answer to #1 is almost always "No" because the simplest way to state an idea, the normal way to refer to an idea in conversation, implies that it will work perfectly in all cases. For instance, "bug free software" is impossible in practice, but if you achieve nearly bug free software, you'll have much less buggy software than your competitors. You can't talk sensibly about any idea without explicitly moving on to question #2 and talking about costs versus benefits. Will one bad data point in the Shop Control Application cause an accident that costs ten times as much as the efficiency gained? Will the value of "bug free software" be negated by a single bug in a release? If your boss is still talking in absolute terms about question #1, then you need to move him to question #2 by explicitly talking about what the benefits of an imperfect solution are. In your mind, it may be obviously implicit in your proposal that there will be cracks in the system, but you can't blame your boss for taking your proposal for "bug free software" literally unless you explicitly address how an imperfect solution will be useful.
- ctdonath 16y ago
  "'bug free software' is impossible in practice" To the contrary, with adequate rigor it can be done. Naysayer complaints of "that takes too long" forget that there is no subsequent time spent fixing bugs because there aren't any. Prime example is the seL4 operating system: http://tech.slashdot.org/story/09/08/13/0827231/Worlds-First-Formally-Proven-OS-Kernel http://tech.slashdot.org/story/09/08/13/0827231/Worlds-First... http://ertos.nicta.com.au/research/sel4/ http://ertos.nicta.com.au/research/sel4/ To the point of the article, there is a crucial difference between "impossible" (be it mathematical or physical) vs. "too hard for me to bother".
  - dkarl 16y ago
    Using formal methods, the only place where you have near-perfect assurance of no bugs is between the spec and the code. You can't have a bug-free spec without bug-free requirements gathering and bug-free documentation. You can't have those without bug-free natural language communication. Also, a reasonable spec for a complicated piece of software is itself a complicated piece of code. If you can prove the spec is accurate by checking it against a smaller spec, and that spec against a smaller one, until you've reduced a problem of arbitrary size (say, the Eclipse project?) down to a reasonably human-checkable spec, then you run into complexity barriers. How is it possible to rigorously specify something as complex as Chrome or Microsoft Excel in a spec compact enough that you can certify it is error-free?

by edw519 16y ago

charlief 16y ago

What if someone said it isn't impossible, but there are big challenges, and based on your skill set, you're likely to fail. It is those kinds of non-glorified situations where perseverance is crucial, but it can also lead to spectacular failure.

edw519 16y ago
What if someone said it isn't impossible, but... I'd say, "Impossible != Unlikely" based on your skill set, you're likely to fail It's probably safe to say that almost everyone who ever achieved anything great was also "likely to fail". It comes with the territory. it can also lead to spectacular failure Spectacular failure is to great achievement what striking out is to hitting a home run.
- MediaBehavior 16y ago
  Isn't the point that "unlikely" is a vague (with negative innuendo)? ...and that a more rational approach is to say, "The value of a possible success" is high enough that it's worth the expenditure of energy to bet the "losing" side of a p = .01 (or whatever)". [of course it's going to depend on who is expending the energy - and who get what portions of the possible success benefits]
- deleted 16y ago
  [deleted]

d0m 16y ago

I don't want to be harsh, but I really hope you aren't really like that. This is really arrogant and you would hardly gain anything by acting like that. It seems like you are trying to demolish him by proving you are right instead of helping the team growing to a better solution. Manager: A web app is impossible. You: Yeah, I agree that it would be really hard to build, but it would give us great advantages. Manager: Maybe, but we can't trust data entered by regular people. You: Yes, this is a pain to deal with. Fortunately, from my past experience, I learned good ways to cope with that. At the end, everyone agreed that it was well worth the trouble. Anyway, I don't want to annoy you more with that, I know you are really busy. Let me find the project I worked on and let's talk about it later on. So basically, here's your way: Manager: "I'm the manager and I know what to do" You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU" Manager: (Don't like being contradicted by an employee.. even less being told fuck you): "I am right, here's why" You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU" Manager: (Don't like being contradicted by an employee.. even less being told fuck you): "I am right, here's why" [..] You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU" Manager: "No, you fuck you. I'm the manager and you won't win" Here's my way: Manager: "I'm the manager and I know what to do" Me: I know you are the manager and you choose what to do, but as a programmer (and from my experience), I could help you take the best decision. Manager: But I'm still the manager and I WILL CHOOSE WHAT TO DO, not you. Me: Yes, totally. I'll get some facts about xyz and get back to you, so you can choose the best thing for the team.

charlief 16y ago
I don't think it is fair to frame it so dramatically. I think you're arguing for strong diplomacy in negotiation, which I completely agree with. You could presume the original dialogue was not indicative of absolutely perfect diplomatic practices, but to say he is extremely arrogant... I would say he is justifiably confident if he has encountered relevant situations many times before and an adequate technical skill set. Either way, to pass any judgement, we're making way too many assumptions. And ultimately, isn't this irrelevant? They are just a few general, entertaining anecdotes. I hope you don't take Dilbert or The Office seriously as well.
- 16y ago

pmarin 16y ago

Bug free software is impossible The main problem about unit testing is that you only can demonstrate that the software pass all your unit tests not that the software is bug free. Also, your software usually run on top of other layers that you need to trust like the operating systems, VM, BIOS, hardware failures...

Semiapies 16y ago
It's a rhetorical bit of three card monte. Note that he seamlessly shifts from pursuing an absolute of bug-free software and instead offers some techniques for reducing bugs, which the manager deems more expensive than the gains they'd offer. Then he conflates "would be better" with "bug-free software" in a bit of snark at the end, and you can almost hear the eye-roll from the manager.

dkarl 16y ago

This is just a case of poor communication, people talking past each other. There's a big difference between the following two questions: 1. Can the proposed idea be implemented as stated? 2. Does the proposed idea degrade gracefully, i.e., will an imperfectly achieved solution provide significant benefit? The answer to #1 is almost always "No" because the simplest way to state an idea, the normal way to refer to an idea in conversation, implies that it will work perfectly in all cases. For instance, "bug free software" is impossible in practice, but if you achieve nearly bug free software, you'll have much less buggy software than your competitors. You can't talk sensibly about any idea without explicitly moving on to question #2 and talking about costs versus benefits. Will one bad data point in the Shop Control Application cause an accident that costs ten times as much as the efficiency gained? Will the value of "bug free software" be negated by a single bug in a release? If your boss is still talking in absolute terms about question #1, then you need to move him to question #2 by explicitly talking about what the benefits of an imperfect solution are. In your mind, it may be obviously implicit in your proposal that there will be cracks in the system, but you can't blame your boss for taking your proposal for "bug free software" literally unless you explicitly address how an imperfect solution will be useful.

ctdonath 16y ago
"'bug free software' is impossible in practice" To the contrary, with adequate rigor it can be done. Naysayer complaints of "that takes too long" forget that there is no subsequent time spent fixing bugs because there aren't any. Prime example is the seL4 operating system: http://tech.slashdot.org/story/09/08/13/0827231/Worlds-First-Formally-Proven-OS-Kernel http://tech.slashdot.org/story/09/08/13/0827231/Worlds-First... http://ertos.nicta.com.au/research/sel4/ http://ertos.nicta.com.au/research/sel4/ To the point of the article, there is a crucial difference between "impossible" (be it mathematical or physical) vs. "too hard for me to bother".
- dkarl 16y ago
  Using formal methods, the only place where you have near-perfect assurance of no bugs is between the spec and the code. You can't have a bug-free spec without bug-free requirements gathering and bug-free documentation. You can't have those without bug-free natural language communication. Also, a reasonable spec for a complicated piece of software is itself a complicated piece of code. If you can prove the spec is accurate by checking it against a smaller spec, and that spec against a smaller one, until you've reduced a problem of arbitrary size (say, the Eclipse project?) down to a reasonably human-checkable spec, then you run into complexity barriers. How is it possible to rigorously specify something as complex as Chrome or Microsoft Excel in a spec compact enough that you can certify it is error-free?