Everybody wants their computer to work. They want to be able to run any application without running into any problems. But as software developers know, it’s never that simple. All applications have bugs - some easier to find, others harder. Many of them are known and are being worked on. For example, Mozilla’s bug tracker have more than 10,000 bugs filed for Firefox. Most of these bugs most people will ever run into, but they do exist and they need to be fixed.

Most Linux users have heard of a program called Wine. This “program” lets you run other programs that were designed to run only on Windows - on Linux. Some may say that this almost drives Linux adaptation since it allows (more) seamless migration for current Windows users.

But Wine has more bugs than almost any other program, since it has to re-invent the wheel. But now comes an interesting matter of strategy, discussed at http://yokozar.org/blog/archives/48 . The question is - in what order should you fix bugs? That is, since you can progressively make people “happier” (by having their applications work in Wine), but how do you do it in a way that makes more people “reasonably” happy before having everyone be very happy? The article provides a simulation of several techniques for picking bugs (such as pick a reasonably happy person and make them very happy), and shows some interesting findings. In fact, it seems that the best solution to this problem is probably to take a “reasonably” happy person and make them very happy.

However, looking further into the article we find that it neglects a certain diminishing returns phenomenon - there are some bugs that are just annoying - they don’t affect usability, and other bugs that stop applications from running. From this light, this looks closer to an economics problem with a hint of network effects. When we pick a bug to fix, we incur a cost of how long it takes to fix the bug, but we also make all the people who need the bug fixed slightly happier. But the degree to which we make them happier depends on what kind of bug this is. This is the network part of the problem - users want applications working, applications have certain bugs associated with them, and users have different “values” to each bug being fixed. The problem is then, given only a certain amount of time (not enough to fix all bugs) how do we maximize the net happiness?

This in itself is a very general question in software development, and is very nontrivial. Network effects kick in very quickly to pick bugs for developers, instead of the other way around. So now the question is, given a realistic strategy (ie most votes for a bug, pick someone and work on their bugs) does it work well? In fact, Arrow’s Impossibility Theorem applies here. If we instead treat these as values as weights (giving a weight of 0 to bugs that don’t apply), we have a ranked set. And we know that the only way to rank a set is Dictatorship - or exactly what the article finds! (for the wrong reasons) So the optimal model for software development is actually to pick a person and make them happiest.