The Problem With Quick and Dirty

The last couple of weeks have been pretty busy. Privately our little daughter is rightfully consuming a lot of time and also we have been in the final phase of planning our big garden project which now will commence in May. For work, I’ve been traveling a fair bit being in the US now the second time in a month and on top of that was in Prague last week. Besides that, we are entering a time of change, which is good, but also intense.

I want to keep my schedule with posting something every Monday 6pm and really today I only will manage it with a cheat. I definitely missed German time 6pm, but I can still make Seattle time 6pm!

Recently on Twitter, I found this quote:

“The problem with quick and dirty is that the dirty remains long after the quick has been forgotten” – Steve C. McConnell

Steve McConnell is the author of Code Complete which you can order on Amazon (affiliate link)

It is a book full of wisdom for programmers and one of those books that I like to have a hard copy of. Its content remains true for a very long time.

Back to the quote: „Quick and Dirty“ is so appealing when you are acting under constant time pressure. Everybody seems to be happy at first. The developer can move on to the next task and the product owner gets the feature, extension, bug fix or what-so-ever quickly.

The problem is that just after delivering the item the next urgent thing is lurking around the corner and the quick win is soon to be forgotten. What remains, however, is the hack. Worst case it will cause a bug in future because of unconsidered use-cases or untested side-effects. Best case it will make your system less maintainable, less performant, less readable, less extensible, … the list could go on.

The collection of hacks that your system is built on over time when you have delivered too often „quick and dirty“ is going to make it harder and harder to maintain and extend the application. It will become more error-prone and you will deliver slower and slower until you eventually will have to go into a painful and resource consuming rewrite of large parts of your application.

Don’t be tempted by quick and dirty. Try to do things right and you will be faster in the long run. Constant investment into the architectural health of your system will pay off.

The MVP approach sucks – sometimes.

Defining an MVP is a great approach to deliver value quickly to your customers and also to get good feedback on functionality very early in the development process so that you can base future decisions on that feedback.

Let’s start with a definition. What is an MVP? Here is the definition from Wikipedia:

A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

And another definition from the book The Lean Startup:

Version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

To me the two key goals of a Minimum Viable Product are

• be quick to market
• get early feedback for future iterations

So why does the title of this blog say that MVPs suck sometimes? It’s when we deploy an MVP into production and then never listen to the feedback and never invest in future iterations.

In that case, the only value we will get out of an MVP is being quick to market. And of course that in itself is a value but you are risking to get unhappy customers because sure enough by delivering an MVP you are setting the expectation that feedback will be evaluated and eventually the piece of functionality will evolve into something fully featured.

Many of you probably know this picture comparing an MVP to a classic iterative approach.

I fully agree with the second row of the picture, but the important piece here is that the product evolves over time from a skateboard (something minimal to get from A to B) to a car (something pretty efficient and comfortable to get from A to B)! If you keep the skateboard for years without improving it you will end up with unhappy and frustrated customers.

Also, …. the agile teams who worked on the MVP will be disappointed that they cannot iterate on the product. It feels like an unfinished job. You might think that this is unimportant detail, but the contrary is true. It directly impacts the motivation and the engagement of the team. More about that topic in my post about what employees really motivates.

Of course, sometimes it is just fine to stop after the MVP is delivered.

• You might decide that the skateboard is just fine and customers are actually happy with the MVP for long-term… in that case: awesome; job done!
• You might learn that no customer actually wanted the skateboard and you retire it. Stop selling it. That is also a perfectly legit approach.

Getting feedback from the market and not iterating on it because you are already asking teams to work on the next top priority is what will hunt you down at some point future and has a negative impact on team morale.

So what’s the alternative? I think there are two, but really there is only one. And also…  maybe there are some that did not come to my mind …

1. Stop defining MVPs, deliver a fully featured product (how again do I know  what fully featured means??!)
2. Start focusing and embrace the MVP approach.

In my opinion, only #2 is the only long-term sustainable way to go. Everybody involved in the process of delivering software to customers should push for this. It is not easy because there are always so many important things that one could work on, but it will pay off over time because it allows for focus and the customer feels heard.

I’d love to hear your opinion on the topic!