The Quick & Dirty Myth

There is no such thing as “Quick and Dirty”. All my experience tells me “Quick and Dirty” actually means “Slow and Dirty” or “Slow, Dirty and everyone is unhappy.”

It came up again last week. I was asked: “When there is pressure to deliver something and you have the choice between getting it done, doing it right or getting it done and right, where do you come down?” It was a fancy way of dressing up the “Will you do quick and dirty?”.

Or rather, since we were talking about the management of software development the question was “Will you make your developers do it quick and dirty?”

This question, in its various forms, is used as a kind of test for us. The person asking the question wants to know if you have a similar set of values to them. In order to answer the question “right” you need to look into the soul of the person sitting opposite you and determine what they value.

All my experience tells me that when someone chooses a “quick and dirty” path a) it takes far longer than is expected, b) the quality is so low we go around the loop a few times making things slower, c) every one involved will feel bad, even “dirty” about the soltiion and d) it causes more problems very soon.

Perhaps (c) and (d) are where the name comes from: “A choice of actions which makes you feel dirty and quickly cause more problems.”

The “quick and dirty” or “slow and right” dilemma is only a problem because of the way we approach the question. There is an assumption that there are two, and only two, options. One will take a while and one can be done quickly, one is “good” and one is “dirty.” These two options are then juxtaposed and connected by the “tyranny of the OR.”

Everything about the question smells of winner and loose, or zero-sum game to give it a fancy name. “Quick and dirty” means “customer wins, developer looses”. And the alternative is “customer looses, developer wins.”

As someone who manages software development teams I find the question particularly naive. When I’m managing the team I can’t actually make anyone do anything. I may tell a developer to “do it quick and dirty” but I have no way of knowing what they will actually do. Indeed, asking developers to repeatedly do things “quick and dirty” not only damages the code base but means I’ll probably p***-off my developers. Before long they will be heading for the exit.

My solution: don’t accept this framing of the problem. Get more options on the table. (If you can stomach the tired old cliche: find a win-win solution.)

Define what you mean by the “quick and dirty” solution. What will it involve doing? Why do we think it is “dirty” ? Why do we think it is “quick” ? What will be the outcome? Will it meet our needs? Indeed, what is the real need? Is it what we think it is?

Repeat the exercise for your “slow and clean” option. Now if these two are opposite end of the spectrum what are all the thing in-between? What other options are available? What questions do you have which you should clarify first? Often there are questions over what is actually needed, when these are clarified the problem and solution may look very different.

Now of the options in front of you can you combine any of them?

Usually when I do this exercise more options open up. There are now “clean and quick”, “minimal” and other answers available. Sometimes “do nothing” becomes an option.

Unfortunately you also find that sometimes you options are very limited. Everything looks “dirty”. The “right” solution is not even on the table so there never such an option in the first place. Doing it this way also makes people feel better, if you do have to compromise somewhere then at least everyone involved has had a chance to have their say and look at the options.

If this all sounds like it will take too long then try it and see. Taking longer in the “what are we doing” phase usually saves time in the “do it” phase.

This is not to say there are not times when you should not take fast action. Sometimes the right cause of action is to “damn the torpedoes,” push on, take the risk and get something done. However those occasions are about getting stuff done, not about making choices.

So, next time someone asks you to do “quick and dirty” remember: there is no such thing as “quick and dirty, only dirty and slow.” Then get some options on the table.