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?
Parsing machine learning logs with Ahana, a managed Presto service, and Cube, a headless BI solution
Check out my article published on the Cube.dev blog!
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.
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?
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?
You may also like
- Data/MLOps engineer by day
- DevRel/copywriter by night
- Python and data engineering trainer
- Conference speaker
- Contributed a chapter to the book "97 Things Every Data Engineer Should Know"
- Twitter: @mikulskibartosz