The Politics of Software Development

Steve Yegge has a couple of posts (here and here) expounding a new theory of thinking about software engineering. As he says,

1) Software engineering has its own political axis, ranging from conservative to liberal. […]

2) The notions of “conservative” and “liberal” on this political axis are specialized to software engineering. But they exhibit some strong similarities to their counterparts in real-world politics.

3) Everyone in the software industry who does stuff related to programming computers falls somewhere fairly precise on this political spectrum, whether they realize it or not.

He goes on to explain the characteristics of the “conservative” attitude towards software development (which he says is risk management) versus the “liberal” view. He  suggests that static typing is the key demarcation between the two camps and then proceeds to assign computer science and programming concepts, languages and even technology corporations into them. The second post has a bunch of replies to feedback. Read them and the comments too.

Sometimes it is difficult to know whether these kind of posts are elaborate trolls, but since many people will take them at face value, let me go ahead and address some of the arguments made. The posts betray a poor understanding of both how the political system works (not to mention silly caricatures of conservatives and liberals) and how software organizations work. To start with, the use of “conservative” versus “liberal” is decidedly unhelpful. It injects the debate with emotional baggage. Politics is more important, far-reaching and have greater historic context than most software development issues. The difference of writing your application in Haskell versus Ruby is trivial compared to the difference in electing one party versus the other. (If you believe that “all politicians are the same”, you are not paying attention.)

Because of that, most people’s political views seldom change. An illustration of this is the popular vote percentage of the loser in “landslide” US presidential elections: Usually close to 40% and that is the same for both Republican and Democratic candidates. Many people have lifelong loyalty to one party and no issue, news, or evidence can sway them. Electoral results are decided by a few percentage of the voters and by demographic shifts. Also, the actual issues may not even matter as parties make big shifts, but their followers remain loyal. See neoconservatism or neoliberalism.

Software development attitudes are very different in contrast. Programmers can be adamant about languages and frameworks, but there is significant churn that can only be explained by pragmatism, not any philosophical outlook. For example, take a look at the position of Objective-C in the TIOBE index. The huge success of iOS devices meant opportunity and many programmers decided to try their luck by writing code in Objective-C. PHP is four times more used than the elite favorite Ruby, because every hosting vendor throws in PHP support for free.

In other words, money counts. The market decides winners and losers. And most programmers accept the outcome because otherwise they cannot feed their families. The market rewards programmers for longer experience in a particular technology or domain and for technologies that show momentum or have value to large corporations. Most justifications are post-hoc. Programming wars are usually nothing more than a battle for status. Few people can make choices entirely divorced from the market situation.

In a tough labor market, programmers (who are trying to break in) have the incentive to try learning many technologies to position themselves with more breath of knowledge, or simply have more targets to aim for. Programmers with jobs have an incentive not to rock the boat at their workplace. You don’t want to try something new if it has the potential to backfire and get you laid off. That is true even in a favorable job market, but then there is greater flexibility and room to try new things.

Within an organization, when someone is presented with a choice, the unasked question is, “Is this going to make life easier or more difficult?” And it is a deeply personal question. Most of the time, a change you propose will mean additional effort, time and risk for someone else, not to mention cold cash being spent on your idea. Also, you get most of the acclaim if your idea succeeds, but they will share in the blame if it fails. This has nothing to do with the other person’s orientation or outlook towards software programming, but simply a cost-benefit decision, sometimes made sub-consciously, but made nevertheless.

You can see people’s attitudes when you present a way out of this situation. For example, give an extra million dollars to a team and see how quickly people change their opinion about whether something is easy to do. Or a big hike if everyone starts writing code in Ruby versus whatever they are doing now. Or extend a deadline out 6 months without handing out new work. Amazing what gets accomplished.

So, no politics here. Just self-interest.