This weekend I spent fourteen hours building an app. I even got it released to the App Store. Proudly, I handed over the phone to my partner saying:

Look what I made! Will this help you study Swedish?

The response was a brutal:

It’s cute but.. no

So for this post, I would like to cover two things:

1. No plan survives first contact with customers
2. This is completely fine

No plan survives first contact with users

I came across this sentence a long time ago when I read Steve Blanks The Startup Owners Manual. It has stuck with me since, thinking that anything I come up with, will likely have to change again (and again).

Brooks Jr. takes a similar stance in The Mythical Man-Month where he states “build one to throw one away because you will anyway”.

Of course, that doesn’t stop me from getting disappointed when I’m told it’s no good!

As I got my feedback, I could almost see the words racing through my head, “fourteen hours for nothing”. That’s when I remember these words above, and my own saying as well:

Nothing ever works on the first try

– personal motto of mine

Programmers doing TDD will appreciate this, with the red-green-refactor we even set ourselves up to fail first so we are sure that the test is correct.

Still, fourteen hours work and an output that’s probably not usable. It still stings.

Failing fast means learning fast

Fourteen hours might hurt but, fourteen hours is a lot less than one or two weeks.

I might have been able to reach the same conclusion in less time using wireframes or interviews. But this project was fun and very good at communicating my intention to get feedback.

Aside from that, I was able to prove out several features I need for any similar implementation. I got to try the app architecture, dictionary parsing, iOS styling and audio playing.

Having the actual app with the full use case, although with minimal data, also gave me distinct feedback I can iterate on.

Quick prototyping

Although fourteen hours might be a lot to spend on every project that pops into my head, I think I will try this again. Being able to publish an app in under two days is actually a really good turnaround time.

I could perform interviews and do wireframes to test the ideas earlier. As I’m a programmer, this way might be faster anyway. Also, it is much more inspiring.

This speed was possible because the project was completely new and I took many shortcuts, skipping CI/CD and unit testing for example.

However, before we know whether or not what we build needs to be built to last, why even bother?

Speed and tech debt

Writing code as I did this time accumulates tech debt fast. If I was to continue on this project now, adding on features, only a week later the pace would slow down. To avoid this, refactoring is a must.

I was told the other day that one of the core principals of Extreme Programming is about making it work first, proving the concept, then making it maintainable.

Maybe this is exactly what we need to do on the macro level as well. First, we show that our product or feature works, then we can make it pretty. Same goes for design and usability as well.

In my case here, I have now proven that it doesn’t work. So I will try something different (apply feedback) and then test again. If it does, first then should I focus on making it maintainable.

Try it

It should be obvious but it is easy to overdo things. Unless we know for sure what we are building, we shouldn’t spend too much time on it. This goes for everything.

It is easier said than done though. I am guilty nine out of ten of overdoing things.

What do you think? How does your team handle prototyping versus building the “the right thing”? Do you have tips, ideas? Let me know in the comments below!