Because Product is not always a quest for perfection: Advocating "quick and dirty" approaches

 

In the last months I have perceived an increasing amount of comments, tweets, etc. about how bad quick and dirty approaches are in the digital product arena.

It seems, not quite sure about it, it is part of the anti-agile, anti-lean startup sentiment that is also part of the conversation.

As someone who, when leading the presales department of a scale up, pushed the building of a ‘quick and dirty’ culture, I feel pressed to defend it - with some nuances, and even if that means Dijkstra will be on my shoulder my whole life...

I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself “Dijkstra would not have liked this”, well, that would be enough immortality for me.

-- E. W. Dijkstra

First of all, it’s clear quick and dirty has no place in mission-critical modules in any sector or industry. I don’t think we are that crazy. Telling a Platform Engineer or Product Manager that they should implement a quick and dirty approach on the key algorithm of a regulated company is not part of this discussion.

My take is more related to ethics.

When deciding about how to approach a specific part of a digital product, one should think about the there basic types of ethics to reflect on what to do:

• The ethics of virtue, or excellence. This is where we focus on the search for perfection. Let’s try to craft the best possible algorithm under current constraints.
• The ethics of principles. Everything is led by the principles that lead my life, or my company. Whatever I am implementing must follow those principles.
• The ethics of utilitarianism. My focus is to understand the final goal and act accordingly. to achieve it

Of course, life is not black or white, so our actions are ethically diverse. But it’s good to think about these three axis to make those decisions.

In the quick and dirty case, this approach is extremely useful when our ethics is clearly utilitarian:

• An MVP where the quality of the algorithm is less important than measuring the thirst of your potencial customer for having it.
• A proof of concept, a demo, where showing the "what" is key. Showing the "how" in detail may come later.
• Non-critical aspects of production environments where, in some specific cases, having a so-so version is still much better that not showing anything. It can be as utilitarian of having a feature that your competitor already has so you get a “check” in your potential customer’s competitive landscape checklist.

The two main issues I see with the "quick and dirty" approach are that

• people in the organization may think this is the standard way of building products. Being able to build a demo in a few days or a PoC in a few weeks may give the impression that "this thing of building products is not that difficult". It is part of the Product Manager's job to clearly articulate and explain the difference between building the core software architecture of the product and, again, enabling the sales team to show a possibility to the customer.
• the second is obvious: quick and dirty code should not stay long in the codebase. This may cause an increase of technical debt. Under pressure to save the burn rate, many teams will feel pressed to just run and forget. This will bring problems in the long term, as many of us have experienced.

 

Some people in the organization may feel frustrated by quick and dirty as part of our toolbelt. The ethics of virtue is very strong in some. I tend to go that path sometimes, I admit - I have a few academic papers to show it-. But the same way a chef may eat a sandwich once in a while, we need to accept that in some situations, quick and dirty saves our day.