Perpetually dysfunctional software

Perpetually dysfunctional software

Imagine that you are sitting at a restaurant and you have just ordered a pizza. Unfortunately, the product they produced for you differs a little bit from the thing you have ordered. A few slices are missing, one of the ingredients has been replaced by something else, and there is a raw fish on your pizza.

When you demanded an explanation, you heard that they had not had enough time to make the whole pizza. The cooks did not want to buy the missing ingredient just for you, so they replaced it with the most commonly used one because most people like it. How about the fish? The cook thinks it looks cool; it does not matter that none of the clients want it.

By the way, you have to pay for the whole pizza. Would you go there? Would you smile and pay them? Would you eat that pizza? So why do we accept software being written is such way?

Feature == value?

Some of us think that every feature adds value. We develop a feature and proclaim: “We have delivered value to the users!” Seriously? What if the function breaks something else? What if it is the most annoying feature ever develop? What if none wants to use it? Does it still add value? A negative value, perhaps.

There is one feature which annoys me regularly. I can connect to my TV using Bluetooth. How often do I need it? I have never used that function!

I should not be annoyed by something I do not use. So what went wrong? I cannot turn that feature off! My neighbor keeps trying to pair his/her mobile phone with my TV! Every time it happens, the TV displays a message which hides 1/8 of the screen. I have to grab the remote control and “click” the “Deny” button. Every time…

Ignoring edge cases

Often we want to focus on the most common use case and ignore everything else. We say (and sometimes honestly believe in it) one day we will implement the edge cases and the feature will be “done done”. What happens when you are an edge case?

Recently, I heard a story of Karen Sandler. She has a defibrillator implanted in her body because of a medical condition. Almost all people who need defibrillator implants are over 65 years old, so the engineers who implemented the software ignored some edge cases. Edge cases like… pregnant women.

Her device shocked her twice during pregnancy because the software concluded she is about to die. It turns out pregnant women occasionally have palpitations, and it is a typical situation.

She was forced to take medication to slow down her heart rate. Not because she needed it, but to prevent the faulty software from killing her.


You may think that professionalism is not necessary when you write another teenage blog platform, a cat picture sharing service, or “Uber for babysitters”.

If we allow people to be careless when they write non-critical software, how can we expect a change in their behavior when they begin working on something more important? Will they even know what we expect from them?

User expectations

The way we write software may seem rational and sane. We can react to changes, implement new requirements, fix bugs, and test a few versions of the same feature. It seems perfect. What do users think about it?

A few years ago I heard an opinion that “Linux is not trustworthy. It is broken software because you constantly need to install updates.” Shocking? I was a little bit shocked.

What do people think when we release an update? Are they happy because now they use an improved version of our software? That is our expectation, but maybe their reaction is different: The application was broken, they fixed it, and now it is “less broken”.

We should look at our industry from the perspective of a user. Not just a regular user, but an angry and very frustrated user. Some time ago I started reading “Geekonomics” by David Rice. I must admit I have never finished reading that book because it outraged me and I quickly decided that its author does not understand anything.

Unfortunately, one thing keeps worrying me: what if David Rice is right?

Remember to share on social media!
If you like this text, please share it on Facebook/Twitter/LinkedIn/Reddit or other social media.

If you watch programming live streams, check out my YouTube channel.
You can also follow me on Twitter: @mikulskibartosz

For business inquiries, send me a message on LinkedIn or Twitter.

Bartosz Mikulski
Bartosz Mikulski * data scientist / software engineer * conference speaker * organizer of School of A.I. meetups in Poznań * co-founder of Software Craftsmanship Poznan & Poznan Scala User Group