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.

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.

• Tainted Love as played on 13 noisy floppy and 1 hard disk drives.
• ConduitJS is a "targeted AOP" framework for JavaScript
• Couldn't get enough Pete last week, eh? He wrote another blog post about Parameter Checking with Postsharp
• Check out this book on the Mikado Method of refactoring. I'm not familiar with it yet, but looks interesting.
• Using RealProxy for AOP

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

There was a period of time that I was really into the game show Jeopardy!

I even had aspirations of becoming a contestant on the show, but alas it hasn't happened yet. But I did some research, and tried to figure out the best way to study/practice.

One of the best ways to practice is to actually play along with episodes of the show. Karl Coryat, a contestant on the show in 1996, came up with a way that you can practice at home and track how well you are doing. I started doing this, but it was somewhat tedious to do it with pen/paper or even an Excel sheet, so I wrote a little HTML/JavaScript to do most of the tedious stuff for me.

You can check out my Coryat Scorekeeper now on Github. It's actually a pretty old piece of code at this point (it uses jQuery 1.4.0, which I believe was the latest release at the time I wrote it). It could probably use a fresh coat of paint (and an updated reference for the average Coryat score), but it's still functional!

Hello, again! "Weekly Concerns" 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.

• Pete Shearer from the Pete on Software podcast kindly invited me to be on his show so I could shamelessly plug AOP in .NET:
  • Episode 5 of the Pete on Software podcast
  • AOP with Matthew Groves blog post, from Pete's blog.
  • Pete also did an Intro to AOP with PostSharp blog post.
• "Pete, Pete, Pete, enough about Pete already!" Okay, okay.
• I was reminded again recently how bad I am with regular expressions and how much I don't like them. Well, I came across a "fluent" interface for regular expressions called VerbalExpressions. I haven't used it yet, but it's something to keep an eye on.
• These sorts of questions aren't common on Stack Overflow anymore, but check out the answers for Strangest Language Feature. There are some answers that I found very cool and some that were real head-scratchers. Not a lot of C# answers in there; I guess C# isn't a very strange language :)
• Another tool to help remote pair programming: go-pty-screen

The principle of least surprise (sometimes known as the principle of least astonishment in more posh circles) is an axiom of design: typically UI design, but also software design. The idea is that some object, operation, device, etc, should be obvious and consistent with its name/appearance. A trivial example: a "left click" should be done by pushing the button farthest to the left on the mouse. To do otherwise would be quite surprising, and make for a bad experience. (That sounds shockingly simple, but it's just an example).

I was thinking about this when I was writing some validation code. I was thinking about a user selecting a U.S. State in a dropdown. On some forms, it's required for the user to select a State, on other forms it's optional.

I wrote a class to help me manage a list of States/Provinces like so:

Elsewhere, I wrote code to use the IsValidState method to check to see if the user, in fact, selected a valid state or not. The first time I did this, it was on a form where the field is required. So, if user doesn't select a state, then IsValidState wouldn't even get executed.

But, later on, I reused IsValidState on a form where the state field is optional. What happens when the state argument is null? A big fat exception, that's what. So, I changed the method:

Is that the correct decision? Or should IsValidState only be called when there's an actual value? I think I made the correct decision, because null isn't a State. Another decision that could be made is throwing an ArgumentException if the argument is null or empty. However, I don't think the correct decision was to leave the method the way it was.

So now let's enter the land of hypotheticals in order to think more about the principle of least surprise.

What if, instead of being a boolean function, IsValidState instead acted upon a StateArgs object being passed in (and its name was changed to ValidateState). Let's suppose there is some reason for this, and that part of the design is a given.  Suppose there's a Value string property with the State and an IsValid boolean property. (ASP.NET Validators, specifically CustomValidators, work like this: the validation method get an "args" object, and you can act upon it by manipulating args.IsValid). What would the correct behavior be then if args.Value is null? Clearly, args.IsValid shouldn't be set to true. So, should it be set to false, or should it just be left unchanged?

In this circumstance, ValidateState is probably one method call in a series of validation method calls (probably with some polymorphism involved with the parameter instead of a specific StateArgs class). So it seems like the least surprising thing to do would be to not make a decision (option A in the above source code). Since ValidateState does not return a value, it's not required to make a decision.