The Lemons Meme in Software

Posted by tibbetts Wed, 06 Jun 2007 11:52:00 GMT

A few weeks ago Bruce Schneier discovered a classic economics paper, "The Market for Lemons". The paper describes the behavior of markets where sellers have detailed information about the products, particularly the quality of the products, that buyers do not have. It uses the example of used cars.

In these markets, the price buyers are willing to pay is defined by average quality of good. Buyers lack information, so can only assume they are going to get a product of average value. Unfortunately, this lower price drives the best products out of the market, because sellers (who know they have the best goods) won't accept that price. When the best goods are removed from the market, the average quality drops, the price drops, and the next best goods are removed from the market. The conclusion is that in these markets quality falls until it matches the amount of information that buyers have.

Bruce applies this principle of economics to explain why there are so many bad security products. But others in the blogosphere have picked it up as a way to describe other parts of software. I first saw it at David Anderson's blog, where he talks about the lack of information when hiring software engineers. The most stark application to the job market comes in a Reddit comment through:

I just realized that it applies to the IT job market. Here the seller (the applicant) has all the info about himself, while the employer knows nothing. So what happens is that companies expect the average, and pay accordingly. That's why people who are smarter than average shouldn't go on job interviews, because they'll likely to get below what they are worth.
In the IT market it also helps to explain the pervasive use of certifications. Even if they don't indicate that a candidate is good, they do cut out the bottom of the distribution of candidates (the truly terrible sysadmins). Since top people will have already taken themselves out of the market for these jobs, it's ok to alienate them. Removing the bottom people pulls up the average, so prices (salaries) presumably rise.

As much as I like thinking about the talent market, my favorite application of this meme is Reg Braithwaite's The Not So Big Software Design where he applies it to tract housing (a pet issue of mine) and by metaphor to custom software development. The customers for both new houses and custom software are definitely ignorant, and they tend to buy based on what we in the software industry call buzzwords. For new home buyers, these are things like granite countertops, en-suite master bathrooms, the number of bedrooms, etc. Builders optimize for these easy-to-observe items, at the expense of things that can be critical to livability or maintainability of homes.

It's a good discussion of the realities of custom software. The metaphor does tragically fall down though. At least buyers of used cars and tract housing can resell them to the next ignorant buyer. Companies are generally stuck with their custom software.

Posted in Software Development, Business | 1 comment | no trackbacks

Stop Energy

Posted by tibbetts Mon, 23 Jan 2006 16:13:47 GMT

A friend just used the phrase Stop Energy to describe part of the open software development process. I hadn't heard the term before, and so I had to look it up. Stop Energy is the ambient energy in an open development process available to stop any forward motion. Stop Energy manifests as technical (and sometimes non-technical) stone throwing directed at anyone proposing any change. An excess of stop energy in a process is crippling. Unfortunately, stop energy seems to increase with the number of participants.

Stop energy isn't uniformly bad, in my opinion. Sometimes it is necessary to prevent bad changes from happening. But far more often is a free software project (or any other open process) killed by stagnation and a loss of volunteers than by an excess of development and participation.

I've personally witness stop energy in several groups. Sometimes stop energy is the result of curmudgeons who don't want anything to change, or of people who want to retain control of previous design decisions. But quite often Stop Energy and Yak Shaving go together. Yak shaving is a catch-all term for the work you need to do before you can do the work you should do. Often stop energy manifests itself as requirement creep. "You can't add a new method to the dispatcher until we totally redesign the dispatcher like I've been meaning to do for 2 years." This kind of stop energy can be particularly difficult for new participants in the process to overcome.

Having a term like Stop Energy I hope will help me to identify it in myself and others, and try to overcome it. It is potentially a very destructive force.

Posted in Software Development | no comments | no trackbacks

Subversion greater than CVS

Posted by tibbetts Sun, 29 May 2005 15:20:00 GMT

I recently finished upgrading Typo (the software that runs Nothing To See Here) from 1.6.8 to 2.0.x, and at the same time moved my local changes into Subversion. Subversion is a definite improvement over CVS. Being able to rearrange my repository (I did this twice before I was happy with it) was really nice. Once I was used to it, I gained the ability to just add things anywhere I want and figure I could sort them out later. The write-once nature of the directory structure in CVS had always created a lot of anxiety whenever I was starting a project. I think I will shortly be transitioning all of my personal projects to Subversion. All the cool kids are doing it. Of course, if I was a really cool kid I'd be using SVK, but I think I'm not cool enough for that yet.

Posted in Tools, Software Development | no comments | no trackbacks