the game of escalation

Often I ask myself how long I would still want to stay in the software industry. Before I started my professional programming career, I never thought that this wonderful world of software craftsmanship is full of complaints, frustration, anger, and hostility. Perhaps that is just the reflection of people wanting to achieve the best things they can do. When you aim for a perfection, anything good enough will not be satisfactory.

I can't say for sure, but somehow I feel that I am still heavily influenced by the positive gratitude mentality, even in the case of calamity. When you have an accident and your right arm is amputated, someone reminds you, "You are lucky, you could have lost your legs!". Losing an arm is considered lucky? This does not mean that we bury our head in the sand and forget the fact that one arm is gone already, it just means that we should not be blind to the fact that things could have been worse. By doing so hopefully we keep things in perspective and move forwards as positive and as best as we can.

One of the lessons I learned so far is the amount of extrapolated verdicts you would get from the users, the developers, and/or the customers. Any bugs, any annoyances, no matter how small it is, are sometimes blown out of proportion. I call this the Universal Rule of Blaming. A customer complains, the company desperately grabs a consultant to help, he finds the bug in the toolkit, the toolkit guy chains it further to the operating systems, and so on. Of course, for each stage, the amount of anger and loudness of the screams increase exponentially. Basically, nobody wants to be the escape goat.

Sadly, everyone in the business of doing software seems to forget that making a software is just like another engineering project. It has its constraints, the resources are limited, the time is the (common) enemy, priorities must be set, and practically it is impossible to achieve 100% perfectness. It is the classic optimization problems. Thus, the responsible people have to make some decisions and these decisions can't please everyone. There will be people alienated with such decisions. Anyone ever done any kind of sensible business knows exactly what it does mean. Every customer feels that he is important (I mean, who does not?), yet a typical company has a lot of customers and such a company is always ready to disappoints 10% of the customers, rather than 90%. As you can guess, it is a matter of minimizing the loss. When a business guy asks his customers, "Hey, I need your feedback" and he really means it, he is not trying to be nice, he is trying to save his business.

However, my concern is not on the technical matters, but rather the non-technical side. When you are angry, you may say some words that you may regret later. Unfortunately, getting mad because of software annoyances can trap you in the same, if not worse, situation. What I often witness is that people start guessing, accusing, throwing blames, up to the a point where it becomes counter-productive and getting personal. You all know what happens when a developer takes it personally: a cycle of violence is about to roll. Once a while I try to stand in the line of fire (a big mistake, I know) in order to bridge both parties. No luck, it is like being trapped in a DMZ and people will just release their steam and waste their bullets to me as if they are happy to find a new bandito to kill. Ever wonder why some developers take the holy vow of silence?

The most common case is the why-my-bug-is-not-fixed drama. For example if I do not fix the problem X on the platform Y, people might start rambling on anything from "you secretly plan to drop support for Y" to "you rather focus only on feature Z instead of fixing X". There are various reasons I still do not manage to provide you the fix, but because of the frustration, people tend to invent and believe in some kind of conspiracy theory. Feel free to write a long Pulitzer-quality editorial on why the lack of the fix destroys your million dollar business, but no need to cross the line and start imagining things.

The drama can continue in a developer conference, where a guy might ask a simple, seemingly innocent question (even in a keynote speech) such as "Why don't you fix (my) bug 123? Why do you work on feature 456 instead?". Believe me, I saw that happened many many time. Those questions will put both the speaker and the audience in a awkward situation. While I fully agree that every bugs must be fixed, throwing such a question which only has the intention of embarrassing the developer in front of everyone is way too dirty for my taste (not to mention that, like often the case, our poor little developer never took any How to Deal with Angry Customers course). In fact, every time I encounter this kind of scene, I make a mental note to stay away from that guy. And I am sure I am not the only one who is doing that. Like I often expressed, we are not in the kindergarten anymore, screaming does not make the solution comes faster. Time to make a ThinkGeek T-shirt for that?

Thus, I reached a conclusion that there are two types of software guys: those who symphatize with the difficulties and problems of delivering a perfect product (because they are trying to do the same, "Welcome to the club!") and those who just like to shift the blames to others (because they get customers banging their doors). Nobody likes to deal with angry customers so the choice is (not) hard: either you take the blame (after all, you are the one who is doing the direct business to your customers) or you pass it along (every one of us is a customer of someone else's product). In the latter case, you just become yet another angry customer.

Noblesse oblige.