Viridia.org

Although philisophically I agree with the goal of improving working conditions and wages, my personal experiences with unions have been mostly negative. As a result, my stance towards unionization is more nuanced than simple “pro” or “con”.

The one-sentance executive summary of my position is: “Unions are a net benefit when labor is a commodity, and a net cost when labor is a specialty.”

To make sense of this, I need to examine what is a union, and what is a commodity.

• A commodity is a kind of good in which all units are more or less interchangeable. Copper is a commodity – there’s no fundamental difference between copper mined in Australia and copper mined in the US.
• A union is most fundamentally a cartel of labor. That is, it is an agreement by workers not to undercut each other on the price of their labor.

I use the term “commodity labor” to mean jobs in which workers are more or less interchangeable. This may mean that the work is simple enough that anyone can do it – like for example, washing dishes. Or it may mean that the techniques involved are highly standardized and legislated, so that there is little difference between workers. An example of this would be electricians and plumbers.

Specialty labor, on the other hand, is where each worker has a unique skill set that is not easily replaced. This is true in almost any creative field; The one I am most familiar with is software engineering.

For commodity laborers, unions provide an important benefit of maintaining a decent wage. Normally, in an unrestricted free market, the suppliers of a commodity will underbid each other until the price of the commodity drops to just above its “replacement cost”, i.e. the cost to actually produce the commodity. For labor, the replacement cost is called “starvation wages” – the lowest possible that you can pay someone and still keep them alive and producing children. Before the development of unions, such working conditions were common.

Unions are at their most powerful when they have a means to prevent independent workers from undercutting the union price, when they in effect have a monopoly on labor. This is a classic prisoner’s dilemma – an unemployed individual might gain a temporary advantage by agreeing to reduced wages, but he is better off if no one else does the same.

In a specialty labor market, things are quite different. For one thing, workers aren’t competing with each other directly on price, since workers aren’t as interchangeable. If I need someone to work on Windows device drivers, I not only need to find someone who knows about that specific application domain, I need to decide how much I want to pay vs. the skill level I am likely to get – that is, I can get someone really good and pay a lot for it, or I can get someone not quite as good and pay less.

A programmer who is highly skilled at these tasks has a great deal of bargaining power and can command high wages. They have no need for a cartel to increase their bargaining power, and in fact such a cartel would merely act as a leveler. Even a mediocre engineer with a poor track record, who doesn’t have quite as much bargaining power, still has a great deal, and they can imagine that someday they might have more. As a result, they are unlikely to want to enter into a system where wages are negotiated collectively rather than individually.

Specialty labor markets are also where the negative effects of unions are most apparent, especially when the union is in a monopoly position. Unions can be a drag on innovation and creativity in a number of important ways, such as by requiring that promotions be based on seniority rather than pure merit. They also create barriers to entry (such as the exorbitant fees required for joining some unions) which might drive away impoverished but enterprising young workers.

A young, inexperienced worker with new ideas who is not weighed down by preconceived notions might fare better in a non-union environment, especially if they are in an industry in which individual creativity and enterprise are well rewarded.

This is sort of a follow-up to my earlier post about game designers.

I get a lot of questions from people about the game development process. One question that comes up a lot is why so many games suck, even ones that have huge budgets and development teams. By “suck” I mean that while many games are technically and visually impressive, they leave a lot to be desired in the “fun” department.

The answer I give is this:

There’s no way to tell how much fun a game is going to be until you’ve actually built it.

By “built” I don’t mean finished – I mean that the game engine and rules are in a sufficiently developed state that the game is actually playable.

Now, I am sure that some of the readers out there aren’t going to accept this assertion of mine without some justification, so here is a more detailed set of arguments:

We do have a number of scientific theories about fun, but those theories are non-constructive. In mathematics, a non-constructive proof tells you that something exists, but not how to find it. There are formal methods that can be used to evaluate a game design; There are rules of thumb that can tell you what characteristics a good design ought to have; But none of these techniques can actually generate a new game design, they can only critique a design that already exists. And even these formal techniques can produce false positives.

What about non-formal, intuition-based methods? As I pointed out in my earlier post, there is a big difference between having fun and imagining having fun. I feel that it is difficult to estimate how much fun a new experience will be merely through imagination. The process of dreaming up a new game experience is in itself fun, and that feeling of fun gets confused with the fun of actually playing the game.

The most successful game companies – the ones that are consistently able to come up designs that are both novel and fun – are those who are willing to iterate on a design after the game engine has been built. In other words, they first build the engine, then collect empirical evidence on how enjoyable the game is (though testing and user studies), update the design based on that research, and repeat the process until the gameplay is of sufficiently high quality.

Note that this tends to make life hard for game programmers. In most parts of the software engineering universe, a programmer can expect (or at least hope) to get a detailed requirements document specifying what actually needs to get built. Once the software has been verified to meet all of those requirements, the job is basically done.

With game programmers, however, the problem is you don’t really know what needs to get built until you’ve built it. It means that there is an irreducible element of trial and error in the process of building a game. I know from personal experience that it can be frustrating having to re-implement the same game feature 20 times because the designer keeps “changing her mind”. It may even seem like a Dilbert-esque nightmare parody of the software development process. But at the same time, my frustration was tempered by the knowledge that the designer is just as much of a seeker and explorer as I am, and we both have the same goal in mind, which is to produce the best game possible.

Of course, the safest way to create a game is to use a game design that’s already been proven to be fun. This is why you see so many games that are clones of each other.