In Defense of the Obvious - Part 2

First part was about certain biases managers of software developer have towards taking shortcuts and against taking bitter pills in general. To recap:

• The cost of doing the right thing™ can be calculated but the cost of dealing with foreseeable problems can only be estimated.
• Things might just work out fine in the end.
• It is easier to manage down.
• Blame can always be shifted below.

All these things might look wrong, evil or unprofessional to you. But I think they are just part of the reality. I think it is healthier to analyze professional interactions strategically in an amoral context. Not because we can’t ever expect moral standards from one another. We should, in a human context. In a strategic context we are dealing with incentives, power asymmetries, transparency (or the lack thereof) and personal agendas. Yes, personal agendas. You have one. I have one. It doesn’t have to be sinister like a Bond villain. Mine is that when I leave a project I want people to say mostly good things afterwards. This is a personal agenda because nobody cares about it but me. What you, as a programmer, probably don’t have are critical knowledge and decision power. And unless you are in the advancement track you have at best lackluster incentives.

In contrast you have the cold, hard truth of code. When we add that to our analysis, it should be clear where the discord comes from. The biases I mentioned above are a reality you have to deal with. It is not because you are working in a horrible place you have encountered them[1], it is because the business is structured that way. There are worse places that allow too many windows to be broken at one time and there are better places that actively fight for product, team, code quality even though once in a while something nasty gets through the cracks. Good people will want to work with a good codebase and infrastructure and good practises. Good products are the fruits of good people[2].

Note that good programmers are capable of writing mediocre code, just add a soul crushingly depressing environment… And then they will leave. Instead of taking two, three or five days off from development to migrate the codebase to git, keep sending zip files to each other at your own risk. But then you will eventually end up with programmers who stamp user’s passwords to log files in the clear.

How to deal with those situations then? You see something is wrong. It is in fact something obvious, like devs frequently ssh’ing into production servers to fix databases manually. Because you know you are working with capable people, you are amazed at their indifference. You point out that these hot fixes cause more problems later on, wasting a lot of dev time trying to figure out who did what on the production server fixing them. And finish your speech with “so, how about we stop doing this incredibly stupid thing, my esteemed colleagues?” Because manners are important. And the response is “yeah, we know. But we can’t afford to build a decent automated deployment infrastructure now. Next topic is…”

There are a few of ways you can respond to this. In the extremes; you can flip the table and then quit or you can pretend it never happened and move on with life. The former would be a premature decision and the latter is only an option if you are already checked out.

Letting go is a perfectly valid option. After all you are not steering the business. As long as you do your work, right? But it would be a smart thing to make sure there is some solid evidence that you have issued a warning. You can, for example, casually mention it in an email report. It is a good habit to keep record of meetings and such anyway. How would you be able to do retrospectives if there is no data? How can you improve things if you can’t do retrospectives?

Some issues are too important to look the other way. They are worth playing the game of politics. There are two things of note here. First is that you can’t always win in politics. In other words you can’t always take and never give[3]. Second point is to not forget the argument is going to be more political than technical. Otherwise the problem would have been dealt with. However this option is not a bad one. If you can keep calm and argue your points without causing too much agitation, even if the issue is left unresolved, you should earn respect.

One option is to offer sacrificing your resources (time) to get it fixed. Like a personal crusade. I personally don’t like this option except for small stuff. It is like helping someone against their will. Even if everybody is better off in the end, you have still overstepped your bounds. Plus, I have only seen this sort of vigilantism makes things worse, even when it is sanctioned by the management.

The reason why I don’t have a hard-line stance on these obvious yet overlooked issues is fixing them is not as important as fixing the underlying culture of shortcutism. It is a programmer’s professional responsibility to bring these issues to light. But an honest analysis of the bigger issue, the cultural issue is likely to be met with disapproval. I recently delivered some unpleasant messages to an audience initially eager to listen, only to see their faces form concerned expressions. Having written 2000 words about it, my only conclusion is this is a compromise between truth and peace. Thread carefully.

This post does not apply to early stage startups. By early stage I mean; maximum two years old, 10 or less people. There is real pressure in such companies and the constant panic mode is not unwarranted. On the other hand relationships are more ad-hoc and candid, so speaking out shouldn’t be a problem anyway.

Table flipping image is taken from here.