Skip to main content

Posts tagged with 'economics'

VM "Vicky" Brasseur talks open source and free software. This episode is sponsored by Smartsheet.

Show Notes:

Want to be on the next episode? You can! All you need is the willingness to talk about something technical.

Music is by Joe Ferg, check out more music on!

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

I was listening to Econtalk (again). This time the guest was Anthony Gill on the topic of Religion. He brought up a well-known quote quote: "I don't know how Nixon won. I don't know anyone who voted for him". This quote was used to demonstrate the same principal that applies when academic economists don't think that a topic like religion is worth studying.

(By the way, that quote is often attributed to Pauline Kael, but it is somewhat apocryphal).

However, I thought the quote was very interesting, and something that I think can definitely apply to anyone (not just politicians and economists), including developers. It's quite easy to get caught up in the same sort of technological provincialism. Since I've worked with Microsoft tools for most of my career, I've worked with lots of other people who've also worked with Microsoft tools for most of their career. I could easily dismiss Java or Ruby or PHP or whatever with an attitude of "I don't know anyone who uses it, therefore it must not be important".

This phenomenon has its own logical fallacy: the "hasty generalization" or the "unrepresentative sample". It can even take the form of something more ugly like fanboyism or, shall we say, "overly optimistic" viewpoints about technology. I don't want to start a flame war, but I'm sure you can think of a few technologies or products that might apply.

I know that I'm not immune to this phenomenon, but I've tried to take steps to combat it.

First, I'm a heavy Twitter user (follow me @mgroves!). My goal is to follow as many developers as I can in my region of the world (midwest USA). Not just .NET developers or web developers, but any developer: Java, Ruby, COBOL, MUMPS, FoxPro, ColdFusion, anything. I believe that every developer has something that they can teach me, no matter what tool they do their job with. I've often called the people I follow on Twitter my "140 character mentors". I don't agree with everybody. I occassionally groan when I see things tweeted about politics or religion or technology (or whatever) that I don't agree with. But I'd rather be challenged and uncomfortable than stagnant.

Second, I go to conferences and make an effort to talk to people I've never met before and go to sessions that are outside my area of expertise. This has exposed me to all kinds of awkward and/or shocking conversations (ask me about how I first met @PerryNeal sometime), but every new person or new topic can be an opportunity for me to improve, even in a small way. This is especially true at conferences like CodeMash that aren't organized around a specific technology or a specific vendor.

To wrap up: there's a whole world out there outside of your own technology's borders. You don't have to emigrate there, but you can learn something by travelling abroad every now and then.

Edit: I wrote this post before I learned about the passing of Jim Weirich, but I wanted to make special mention of him here. Jim was often considered a "Ruby" guy, but his knowledge and interest expanded far beyond that technology. By attending his sessions, I learned about some advanced ideas of OOP from him and from a book he recommended (What Every Programmer Should Know About Object-Oriented Design), as well as feeling comfortable with Git for the very first time through a live workshop in which he used Git Immersion. I think of him every time I read the book and every time I use Git, and I think he stands as a shining counter-example to the phenomenom I described in this blog post.

POW Camp paradox

February 19, 2014 mgroves 0 Comments
Tags: methodology economics

I often listen to the EconTalk podcast, because I have an interest in economics, and I also enjoy looking outside areas of my own expertise for ideas and thought processes that can lead to results within my area of expertise. I've been trying to think about ways to apply economic theory to software.

Let me warn you now that I don't have a conclusion or really even a hypothesis yet. Just some observations and random thoughts. So don't be disappointed when you read through all this and I don't have an answer (yet).

Recently, I've been thinking about the incentives that are involved with teams writing software, and trying to achieve the optimal outcome with a given team.

While reviewing one of my favorite episodes of EconTalk (October 27, 2008 Episode, "Munger on Middlemen", with guest Mike Munger), I was reminded of a reasearch paper entitled "The Economic Organization of a POW Camp". It's not a hypothetical paper--it's based on accounts from POWs in WW2. The episode covers it quite well, but here's a quick overview:

  1. Each prisoner of war receives a care package from the Red Cross."...the supplies to each person were equal and regular."
  2. Each prisoner is free to make trades.
  3. A priest in the camp makes a series of trades, starting with a partial care package.
  4. At the end of all his trades, the priest ends up with the equivalent of 1+ care packages worth of goods.

So what happened? Preferences, prices, and the role of the priest as a "middleman". (Side note: "middleman" is often used as a pejorative, unfairly so. Listen to the podcast episode for more on that). From the paper: "it came into existence not by conscious imitation but as a response to the immediate needs and circumstances."

If a Red Cross package contains cheese, and I don't like cheese: that cheese is essentially worthless to me. I prefer to have cigarettes. Someone in the next barracks doesn't smoke, but loves cheese. It's in our mutual best interests to trade. However, finding each other and intiating the trade is time consuming--we might not ever get to make the exchange because we don't have enough information. The priest, however, travels among the barracks, learning preferences, enabling trades, and possibly even performing exchanges and distribution. Through his knowledge of the "prices", he is able to a) help everyone else improve their goods according to their preferences, b) improve his own lot, c) direct the economy towards equilibrium by his actions.

On a software team, we aren't exactly prisoners of war (i.e. we aren't "independent of [our] exertions"), but we are also faced with similar challenges of scarce resources: We perhaps have a fixed budget or a fixed amount of time. We are "prisoners" of constraints. And everyone has preferences: some of the team doesn't like writing tests; some team members hate working with the UI; some team members are bad with SQL; certain members want to use a new JavaScript framework; etc. There are other tasks like dev reviews, documentation, etc, about which people have various opinions and preferences.

A typical approach that many leads would take is essentially that of a dictator or a centrally-planned economy: a top-down assignment of activities that the lead thinks are allocated correctly, even though in reality he'll never have enough information to make every optimal decision. He's giving everyone a Red Cross package, but not allowing or assisting with trades.

I definitely believe a lead/manager should act like the priest instead. Let the team organize the work according to the constraints and preferences, pushing down decision making as much as possible, with the "priest" merely facilitating and making it easier to do so. This can be tough though, as it might feel like giving up control, but maybe that control is mostly an illusion.

Matthew D. Groves

About the Author

Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.

Latest Comments