Why you should rethink software development
Today, software is everywhere. Modern society depends on it. It’s inside watches, medical devices, phones, TVs, elevators, cars, and even “computers” (as if those other things don’t compute.)
As a consultant, I’ve helped companies develop software for the past 14 years, and coded quite a bit of software myself.
I co-authored an international standard and worked with adopters to implement it. I wrote software that controlled the behavior of a satellite communication system. I developed tools for a team that created a model of the European Extremely Large Telescope. I was involved with software for automotive companies, healthcare systems, banks, insurance, telecommunications, aviation and more.
In some of these companies, software development worked well. Teams delivered software in high quality. Stakeholders were happy. The companies grew their customer base, and ultimately their profit.
But other companies struggled.
I saw departments fighting each other over whose requirements to include in a release.
I saw developers who could not keep up with the amount of feature creep and change requests. Some of them lost any sense of purpose in what they were building.
I watched as communication broke down between developers and the non-technical business stakeholders who managed them.
And after a few years, I recognized a pattern.
Whenever people asked me what was going wrong, I just started telling them: nobody wants to use software.
At first, they looked at me like I was crazy. Software is everywhere. It’s what powers modern civilization! But after I explained myself, many of these same people would slowly nod in somber agreement.
If you are like me, you do at least some of your shopping online.
Do you want to register for one more e-commerce website?
Do you enjoy adding products to your shopping cart, one by one?
Do you want to double-check whether the credit card number you entered is correct?
Do you want to confirm your purchase several times?
I sure don’t.
But still, I shop online. Why?
Reaching the desired outcome
What I want is a desired outcome: I want to own a new washing machine or read a new book. Every interaction between me and the software is a step between me and that outcome.
Recognizing this has had a huge impact on the way I develop software.
Many companies measure developer productivity by lines of code or by velocity, which roughly means: completed features per time, adjusted by feature size.
Some people think selling features is like selling oranges. The more features you provide to customers, the higher the profit.
But I’m here to tell you that it isn’t.
Adding more features may make it easier or harder for your user to reach their desired outcome. It may actually stand in the way. There are other, more useful metrics than velocity.
When you enter a new market, make sure that your software fulfills some customer need. Cherish your customers and get frequent feedback. Don’t turn your software in a bloated, feature-rich mess that nobody wants to use.
If you already have a solid position in a market, clear the way. Make a user’s journey to their desired outcome as short and pleasant as possible. Because the end of that journey is the first moment value is created for your company.
If you can get users to complete their journeys to the desired outcome with less steps, good. Develop less, because software development is an investment.
How Amazon’s Kindle shortens the journey
Amazon started out selling books online. You went there to buy a book, which they’d ship to your door.
Then they pioneered 1-Click payment, so you could skip entering your payment details and clicking through a shopping cart funnel each time you wanted to buy something. This shortened the user journey.
Later, they introduced the Kindle. This further shortened the user journey. Find a book, view its details, confirm the purchase. After a short download, you’ve got the book. No more waiting for shipping.
Ultimately, all of this leads to the same outcome as in the early days of Amazon: you can read a book.
It’s just that now the journey taken to get there is a whole lot shorter.
Developing as many features as possible is not enough to be successful. Fortunately, I am not the only one who thinks that.
Gojko Adzic created Impact Mapping, a technique for deriving software features from business goals. He asked the developer community to “Make impacts, not software.”
David Heinemeier Hansson, creator of Ruby on Rails, believes that you can always do less.
As much sense as this makes to the developers I explain this to, in my experience, only a minority of companies have put this philosophy of shortening user journeys into practice.
So don’t get me wrong: I love software. I’m fascinated by it. I started developing software in the early 90s, and I’m still into it.
Software is useful. But not on its own. Software is just a means to an end.
Please keep that in mind.