The Politics of Software Development

by Krishna on August 18, 2012

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.

{ 1 comment }

Nikhil September 17, 2012 at 5:27 am

It sounds like a very plausible solution for sure, but money can work only as long as it is the only factor involved. Money works with outsourced and freelance jobs, for instance. Where the organization insists on having a group of individuals from diverse backgrounds on the same premises, things can turn out to be very different.

In the latter circumstances, pay is not the only deciding factor, although it may well be one of the most important. There's something called job satisfaction - the perception of growth and overall well being - that may matter more than the pay itself.

Especially in the case of younger employees who have ventured into the world after doing well academically. Satisfying them entails not just good pay but also the quality and culture of life in the organization.

Employers could well forget that they need to do more than just pay well, but they will do much better if they remembered.

Comments on this entry are closed.

Previous post:

Next post: