The saying "It's easier to beg forgiveness than ask permission" seems pretty popular among programmers and IIRC was attributed to Grace Hopper. In what situations is this typically true, and why do you believe that such a counterintuitive proposition would hold?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as off topic by Yannis♦ Jun 19 '12 at 16:01
Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.
I think that one imporant reason is responsibility. By asking for permission, you are transfering the responsibility to the person you are asking, so that person might be inclined to deny just to avoid being held responsible for the result, in case of failure.
On the other hand, once it's done, that's no longer a problem. Even if the result was a failure, it's still your responsibility, no matter if you get forgiveness or not.
Because once something is done, as long as it doesn't make things worse, it's often easier to leave it in than to take it out (i.e. "what's done is done.")
It's politics, all politics.
I've seen this become a reality on occasion, when the management or client put up too many barriers to simple changes (e.g. "quality" reviews by people who know nothing about the system, needing to get signoff from too many business areas) that it's sometimes quicker and easier to just "rip off the bandage": don't tell too many people, just make the change, and if it works, everyone's happy, you might get a slap on the wrist for "not following the process", etc.
Of course, if the change fails, you might find even more processes being layered on... but that's the risk you took.
(disclaimer: I have no problems with quality controls and checks and balances - as long as they're reasonable)
I think it's much more complicated that you think. Here are my two views on the problem:
I'm always amazing when I hear discussion about salary increase. People complaint they are not increased. But if they don't ask (unless they are in an administration automatic and predefined salary increase), they will get nothing by just waiting.
It's the same with the car of the neighbor you want to borrow... You may think "he will think I'm ....." or "She won't accept because ....." or "He will probably need it anyway ....".
The truth is that you don't know until you ask. However, the way our brain work will fill our mind with unhelpful thought that you created yourself. In most case, they are false.
So asking may be the first thing to try.
This statement is also true because in enterprise where responsabilities are clearly defined and where people are rated on their individual achievement.
If you ask the responsible of another department for something that may (thought he creates) affect him negatively, but the outcome (if positive), will not affect him, he will surely refuse, to be safe.
Two answers are very similar: fear. In the first answer it's YOUR fear, in the second is the fear of THEM.
To overcome fear of others, don't ask. In many many case, you will succeed, and in case of failure, then yes... apologize will be enought.
Not in most case unfortunaly, but that's a risk YOU MUST take in order to advance in both life and your career.
In a hierarchical organization the upper management typically has no clue about the subject matter you're working on; then their decisions are, inevitably, based on how you represent your suggestions to them. Representing technical ideas to non-technical people is notoriously hard: if you explain it as it is, they don't understand anything and might refuse just because of that. And if you explain it so that they understand, you're not stating the thing as it is. Is it ethical either, huh? Thus is it may be best to just do the right thing instead of trying to explain that in such a flowery and falseful manner that the management agrees with it.
It's not irresponsible. Even if you asked for permission, the result would strongly depend on how you represented your issue. Since you're able to affect the decision this way, why bother? Just do it and screw bureaucracy. At least you're not lying then. The key point is that you know it's the right thing to do.
Of course, you have to be pretty damn sure you're right, since you're now the one taking the risk. What you're saving is your and management's time and effort; not a small feat.
When you ask permission, the person you are asking must imagine the consequences that COULD happen if you are allowed to do it. This could include terrible things like the company going bankrupt. A risk averse person (or one with a lurid imagination) will tell you no. They may not be swayed by the possible benefit of your plan. When you just go on ahead and do it without asking, if you get the benefit then you are unlikely to be punished or reprimanded. If you get a small consequence, you will get a small punishment. Of course, if you bankrupt your employer, it's all over.
I can't employ someone who needs to check with me on every email, every line of code, constantly wanting permission to do their regular job. But someone who thought it was ok to risk the entire company on a ridiculous gamble (a company that isn't theirs to risk, since I own it not them) would not still work for me even if the gamble paid off. You need to be in a fairly big and deep pocketed organization (the US military for example) to take this attitude - and you need to understand the risks very well.
What I've experienced is sometimes it's hard to make an argument to make certain changes in your work process or tools. As long as the current process and tools work, there might not be a strong incentive for any manager (or co-workers) to go and run the risk of trying something new that a) might not actally be better or b) might fail.
There's time and resources going into it, people might have to adapt, etc. If you go upfront and ask to make a change, you might meet some reluctance and will have to make strong arguments. There can be a lot of reasons for a manager to not want to make a change and it's not necessarily because they are lazy or not up to change. But you're asking for a definitive decision or a "Go!" which actually puts the responsibility on your manager.
If you just make the change and sneak it into your workplace at the moment where the change becomes obvious to decision-makers you might already have proven that:
a) It can be done.
... and so on.
If it failed there might be some repercussions, but unless you're working with a crappy boss, these might not go behind some wrist-slapping and some humble excuse coming from you.
We did it once where we tried to sneak in a different bug tracking system behind the CTO's back. The one in place was hated with a passion by simply everyone on the dev team (but it had been evaluated - not by any devs - and paid for, so it was expected that we use it) and we had some licenses left for another one.
Sadly, this instance of asking for forgiveness rather than permission failed. We were asked to go back to the old system. I don't know if someone really had to answer to the CTO.
So basically, asking the CTO to change the bug tracking system and get permission: Zero chance.
On the other hand, starting to use it (with no expenses other than the time spent to set it up) and then seeing whether we could get some permission AFTER the fact: Not a fat chance, but considerably higher than zero.
It seems I've heard/read that the statement predates Admiral Hopper, but I don't remember details. I suspect the original source is lost to time.
Anyway, the first I remember hearing "It is easier to apologize than ask permission" was at a talk the great lady gave when a nearby college was opening a new computer center back in 1985. Her explanation was that the admirals to whom she reported didn't usually understand what she was trying to accomplish. Their default answer to anything they didn't understand was "No". However, they were almost always happy with the results if she ignored their answer. Thus, she quickly figured out that it was easier to just proceed without asking for permission; if anyone was upset, she could just say she was sorry.
My nanosecond was a cherished souvenir until it got lost in a move a few years back. :-(
It is a point of view that advocates taking risks. By that point of view, if you don't take risks, you aren't testing the water, and you will not reach your maximum potential.
If you agree that you learn from your mistakes, then you may agree with this adage. You may find that the bruises you take aren't nearly as bad as you imagined, and when you are successful, you find yourself rewarded in excess, because you "showed leadership".
This thought pattern makes the concept intuitive, if not the practice.
This attitude is most valuable someone who is in a new job situation, but has an established track record (assuming competent management). This is when mistakes will most often be forgiven (assuming good sense, intentions, and rationale), and progress will be most highly rewarded.
From what i know, that is meant towards exceptions and error handling (although i may be wrong). It means, dont ask if the file exist. Just move the file and see if you get an error or not. The reasoning is, if you ask if the file exist and delete it the next line, there MAY be a case in that split second the file may be deleted in which case the code is now deleting a file which doesn't exist.
Just try deleting (or whatever it is your doing) and see if you get an exception or error code or not. Dont ask because that is a race condition.