/ agile

Software Existentialism

A few days ago, in an interesting discussion I was having in a local Agile forum, someone posted the phrase:

Doing the right thing precedes doing things right

The phrase caught my attention and as the author didn't give much explanation of it and given I am an early adopter of the Cartesian method doubt of everything until you can prove it's true by yourself, I've decided to spend some time thinking carefully through it.

First, a quick overview of the difference between both in the context of this article:

  • Do the right thing is to deliver the product that satisfies or exceeds the market's expectation. In other words, delivering the valuable features the users need.

  • Doing things right is to build the product correctly. Deliver a product without bugs, which is simple to use and easy to understand. Most important, designed and coded in such way that it can easily evolve and change.

Existentialism

One of the first things that caught my attention from the phrase is that it resembles the famous phrase from Jean Paul Sartre l'existence précède l'essence[1].
This phrase summaries the existentialism school of thought by claiming there is no purpose nor destiny the man comes to fulfill to the world. The man is thrown to the world and all possibilities are open to him. It is through his life (existence) that each man finds his own meaning.
Nobody is born good or evil, hero or villain, brave or coward. We choose ourselves through our actions and we become the consequences of our decisions. We might say the essence answers the question of What? is the man and the existence answers How? does the man lives.

Then, what is then the essence of software? In my opinion, it should be delivering the right product to the market. The purpose of a software program is to satisfy the users needs. Otherwise, it's useless and has no reason to be.
On the other hand, doing things right or wrong, resembles to its existence, as it focus more on the How? the software is built.

Following strictly the existentialism metaphor, we might think that contrary to the opinion I read on the forum, doing things right precedes doing the right thing. However, believing the human condition is existentialist doesn't prove the software condition is existentialist as well. So, I will try to prove this is true from my own experience of building software.

Lean Startup

Let's imagine we are a startup company. We have read Eric Ries Lean Startup[2] book twice and we are ready to start with our first minimum viable product (MVP) in order to test the market and validate our ideas.

In order to decide whether do the right thing leads to doing things right or vice versa, we must explore the different combinations. We all know that doing the wrong thing and doing things wrong at the same time is the worst scenario, so we can discard it. And of course, doing the right thing and doing things right is the best choice, so we are not interested on it either.
The two scenarios we care about are:

  • Doing the right thing, but doing things wrong.
  • Doing the wrong thing, but doing things right.

Let's start with the latter. Given nobody has the crystal ball to see into the future it's very likely that we will start by doing the wrong thing. We need to find which is the right thing, so we need to explore our ideas and test the market to get feedback from it. This is called to pivot in the Lean Startup jargon. However, given we are doing things right, once we get feedback from the market we will have the ability and skills to rapidly change our product: add new features, remove the useless stuff and leave some functionality unchanged still working as expected.

On the other hand, let's say we were so lucky we find the right thing, while doing things wrong. What happens next? The technical team hopefully will want to start improving the product and do things right, while the business team will be eager to keep adding features to the product and release a new version after the MVP in order to get more users and start making some real money. Do you notice the tension? Who do you think will win the argument?
It could even be worse, doing things wrong could also affect the end users: bugs; functionality hard to understand and use; system too slow or exposed to security leaks; etc. When users start complaining and expressing their frustration it becomes hard to know whether it is because the product is not the right thing they need or because doing things wrong have affected them too much.
Not so far in the future, our startup company might begin to lose market share. The technical team won't have the ability to add more features easily and the rate of issues introduced will grow faster than the rate of problems solved. Maybe another company will take your idea and deliver the same product doing it much better.

Conclusion

Many people think that given you don't know if you're doing the right thing, then it's better to invest as little as possible and get things done no matter how. However, not knowing if you're doing the right thing, doesn't mean that you aren't doing it! Neither, it means that you will never learn from the market and at some point stop doing the wrong thing to start doing the right one. Then, when is it a good time to stop doing things wrong and start doing them right? Most probably the time will never come and the further you go on the wrong path the harder will be to get straight.

Doing the right thing requires creativity and exploration. It's very likely you will need to pivot several times before finding the right thing. Your ability to change and adapt your product fast and smoothly is one of the keys to success and doing things right is the best way to ensure this will be possible.

Now that I realized I am both an advocate of human and software existentialism, I can say to myself:

Doing things right precedes doing the right thing

For those who come this far and are interested in the subject, you might continue reading other posts[3] I found while writing this article.


  1. Existentialism on Wikipedia ↩︎

  2. Lean Startup principles ↩︎

  3. An article from David Anderson and another one from Allan Kelly ↩︎