In Defense of the Obvious - Part 1

Sometimes the most important insights about things that may go wrong are obvious. As in you know the other party can (and should) easily deduce them. Sometimes these are the hardest things to communicate. And if you fail to communicate these obvious issues, guess who will bear the blame when they occur?

We say software is built, but a more suitable idiom would be software is grown. Every new component or feature is incorporated into existing ones and possibly interacts with them directly. The result of every decision is a combined result of that decision and the previous ones. Right abstractions can reduce this dependency to a certain degree. As software grows cost of making these decisions increase as well. The question is will this be a linear or exponential increase?

I will call whoever it is you are reporting to directly, the supervisor in this post. The supervisor may know the technical side of the work more (in case of a team lead for instance) or less (a chief of whatever) than you do. It does matter in a practical, dare I say tactical sense. But it does not really matter in a big picture or strategical sense, where your career and the future of the compoany you are working for comes into play.

If you have been in the business long enough you must have seen this dynamic play out many times. Your fact based analysis is ignored with much handwaving and vaguely relevant counter examples. The supervisor has certain biases. I will try to uncover them in this post because I have seen them being ignored by programmers in real life. Yes, not being unnoticed, but ignored. I think the reason for this is programmers are in this logical/direct/overt mode of thinking (and therefore acting) and they get blindsided when they are met with emotional/indirect/covert[1] communication all of a sudden. It is a sort of shock, a sort of fleeing from the truth when they ignore the biases. But I digress…

Not the strongest bias, but I think the one with the deepest roots is confusing calculable and merely estimable costs. The cost of doing the right thing™ can be calculated. It wouldn’t be a precise calculation, but if the team has been managed properly[2] it would be accurate enough. The cost of dealing with issues as they arise can only be estimated. This is a very different uncertainty than the former. There are too many unknowns to begin with. Sometimes these issues affect other parts of the enterprise. It may cause legal vulnerabilities for instance, who knows what that might lead to? You might say I am advocating against taking risks. And indeed I am advocating against taking this kind of risk. When you hear a train coming, don’t cross the tracks. The bias to avoid calculable, (better) known costs and knowingly leave yourself open to foreseeable risks with unknown costs is a management smell[3].

The bias that things may just work out fine™ is based on the previous one. It literally means we can have our cake and eat it too! Unlike the previous bias the supervisor cannot defend this to his supervisor, not blatantly at least. However this will used against your arguments. “How do you know we will have those problems?” he will say. Remember, the cost of doing the right thing™ is calculable, but not the cost of dealing with the issues of not doing the right thing. Neither is the probability of these problems surfacing. Maybe we will have so much money then, we will be able to throw so many warm bodies developers at it that it will be resolved instantly. Maybe the company will go bankrupt because we did the right thing™. The horror! Jokes aside, I would like to point out that this question is not an unreasonable one; “How do you know we will actually have to deal with these issues?” Therefore, weighting his options, the supervisor will be biased towards a more optimistic choice of dealing with the problems as they are encountered.

This reactive mentality is a product of how technology companies operate; like conventional companies. Technology companies operate exactly like conventional companies. Top level management makes the important decisions, middle managers make unimportant decisions and they whip the slaves workers into shape, who in turn deal with the mundane details and do the actual work[4]. Why would you think it would be any different for technology companies? Because of the horizontal organization veneer that startups flaunt? No, they are only superficially different.

Back to the supervisor. To hide the fact that scheduling is done top-down, often monsters like “we will run out of money” or “the investors will be very unhappy” are called into play. Then a compromise is made between programmers and the management. The result is exactly what the management wanted in the first place. But programmers leave thinking they have to suffer a bit but the suits have compromised too. The supervisor is undoubtedly smart enough to recognize who holds the power in this charade. You see, it becomes a recursive problem; the supervisor has to justify doing the right thing to his supervisor and so on and so forth. Conventionally, hierarchies are not designed to work this way. It is much easier to just cut some corners.

Speaking of hierarchies, they are very useful for finger pointing accountability. When something goes wrong the supervisor’s supervisor will hold the supervisor accountable. The supervisor will hold you accountable. Guess who you can pass the blame? Unless you get lucky with that git blame, you are the ultimate and a most convenient scapegoat. The supervisor will be biased towards shifting the blame towards you later, than taking flak today. Even if it means his reputation will be somewhat damaged in the end. It is the principle of minimum energy in action.

So these are the four main biases the supervisor will have. There is a good chance most of you already knew all this. This post has been getting too long and I know I haven’t said much yet. I will try to drive the point home in the second part.

The image with the birds is taken from this page.