Mark Needham

Thoughts on Software Development

Ask for forgiveness, not for permission

with 4 comments

I gave a presentation at our ThoughtWorks Brazil office in Porto Alegre last way on some of the things that I’ve learned while working at ThoughtWorks and the first point I made was that it was better to ‘ask for forgiveness, not for permission‘.

This was something that was taught to me a few years ago and the idea behind this is that if there’s some idea we want to try out it makes much more sense to start trying it now and then we can always apologise later on if someone has a problem with us doing that.

This is in preference to an approach where we ask whether we can try out an idea and get told no straight away i.e. we should look to be proactive.

It’s really easy to say no to something when you don’t really no what it is you’re being asked and it seems to be the default answer a lot of the time.

An example of something where this rule may apply would be if we wanted to try writing some tests with a different language/framework to see whether it improves the way we’re doing things.

We don’t really know whether the new approach is going to be better than the current one so it makes sense to spend a bit of time playing around with it so that we can find out.

Later on in the talk I suggested that on some decisions it makes sense to gather data and then let the client decide what they want to do.

An example of this happened on a project I worked on a couple of years ago where the value of writing functional/unit tests was being questioned.

My colleague Kristan Vingrys came up with a matrix which showed the risks of not testing various features and then let the client decide whether they wanted to take that risk. Alex wrote more about this at the time.

After I mentioned this Caio pointed out that this idea seemed to contradict the idea of asking for forgiveness and not permission and at the time I couldn’t really think of a good answer to why I didn’t feel the situations were exactly the same.

A week on I think that the difference is that the ‘ask for forgiveness’ approach applies mainly for new situations where we haven’t agreed as a team what we should do and people don’t have enough information yet to know whether we should or should not do what is being proposed.

The idea of gathering data and letting the client decide applies more when a decision has been made or suggested and we want to try and influence that decision.

It doesn’t make sense to just do what we want in this situation if it explicitly goes against what the client wants but equally we don’t want to do something which goes against what we believe is the best approach without at least pointing that out.

Be Sociable, Share!

Written by Mark Needham

June 4th, 2010 at 9:03 pm

  • Pingback: Tweets that mention Ask for forgiveness, not for permission at Mark Needham -- Topsy.com

  • Andy

    Having never engaged Thoughtworks on a project before, I can tell you now that I will never do so, thanks to this article. Well done!

    I’m now led to believe that you’d rather do what you want and waste your CLIENT’s money to scratch an itch. Amazingly unprofessional. Let’s all go to the movies and charge the client too!

    You run things by people because they are paying you to do a job for them. If a plumber came to your house to fix a pipe and decided to use a technique he’d just thought of (gummy bear seals?) you would be pretty enraged I’m sure. It’s all okay though! He can just ask for forgiveness later.

    Thinking that you’re cleverer than your management does not make it so, and working at Thoughtworks does not make you above your responsibility for transparent engagement with your paying clients.

  • http://www.markhneedham.com Mark Needham

    “I’m now led to believe that you’d rather do what you want and waste your CLIENT’s money to scratch an itch. Amazingly unprofessional. Let’s all go to the movies and charge the client too!”

    I guess that’s one way to interpret what I wrote but is it a waste of money if we discover a better way of doing something which means it takes less time than it might have taken previously?

    To me it makes sense to spend a bit of time working out if that’s the case rather than just doing it the same old way.

    What I’m suggesting isn’t all that far from some of the ideas of lean software development with respect to putting learning as one of the key goals on a software project.

    It’s also linked to delaying decisions until the last responsible moment until we have all the information needed to make a decision.

  • http://blog.entropypool.com Marcos Eliziário Santos

    While I totally agree with you, one must not forget the messy politics around some organizations.
    If your organization is not based on solid values like valuing results more than ass-licking, professionalism over cliques and office politics, you can be in big trouble if you go through this route. And paradoxically, you’ll end up more likely being punished if your attempt at change is succesful than not.

    That is, depending on the organization, even if you discover the cure of cancer as a result of your explorations, you run the risk of not being “forgiven”. Because you violated the processes, the traditions, the ivory towers of power, and for some organization, this kind of thing is unforgivable.

    Unfortunatelly, in some organizations, people on power want to make sure developers are mere button pushers, and thus, for this kind of people, any initiative not sanctioned by them is seen as a threath for their power. And this kind of pathological reasoning occurs not only with some sad individuals, but with pathological teams also that really don’t want anything that could shake them out of their confort zone.

    So, the idea is excellent, but it pays to do a quick assesment of organizational health before trying it.