Perpetually dysfunctional software

Imagine that you are sitting at a restaurant and you have just ordered a pizza. Unfortunately, the dish they gave you differs a little bit from the thing you have requested. A few slices are missing, they gave you garlic instead of cheese, and there is a raw fish in the middle.

When you demanded an explanation, you heard that they had not had enough time to make the whole pizza. The cooks were out of cheese, so they replaced it with garlic because there was plenty of garlic in the kitchen. 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 in such a 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 developed? What if people don’t want to use it? Does it still add value? A negative value, perhaps.

There is one feature that 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 neighbors keep trying to pair their mobile phones 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 that 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.

Professionalism

You may think that professionalism is unnecessary when you write another teenage blog platform, a cat picture sharing service, or “Uber for babysitters.” I don’t agree with that point of view. If we allow people to be careless when they write non-critical software, how can we expect a change in their behavior when 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, the developers 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?

Perpetually dysfunctional software

Feature == value?

Ignoring edge cases

Professionalism

User expectations

4 reasons why TDD slows you down

Extreme ownership and software engineering

Perpetually dysfunctional software

Feature == value?

Ignoring edge cases

Professionalism

User expectations

4 reasons why TDD slows you down

Extreme ownership and software engineering

Related Posts

Turning greenfield projects into brownfields projects

Is programming art or science?

Does a tester break the product?