The Software Development Game

There are games about skiing, about playing the guitar, about managing a team of soccer players and other real-life activities. Could there be a game about programming? What would it be like?

I will begin answering this question by rephrasing it. First I will explain why an actual programming game does not sound as exciting to me as a software development game, then I will describe a software development game. If you are not interested in a comparison, just skip ahead to part 2.

1. The Programming Game vs. The Development Game

Software programming is a subset of software development. Software development is the process of bringing a piece of software to life, by all kind of means. Software programming means actually tinkering with the code to create the software. This is a job that requires little interaction with other people, and allows you to devise all kind of contraptions that you deem to be useful - primarily useful to yourself.

Programming code is a highly self-referential, self-ordering and ultimately, self-sufficient activity. It makes for a pretty bad game. Of course you start with a requirement, a goal, but from then on it is entirely up to you how to get to that point. You can break up your tasks into multiple smaller tasks, bind each task to a segment of your completed program, or you can write everything into one chunk and get to the same solution less elegantly.

A programming game would play quite much like "The Incredible Machine" or any other similar physics game, except that you would have an infinite number of parts to apply, and time would be your only enemy. The less parts used to reach your goal, the bigger your score would be. "Crayon Physics Deluxe" almost plays like such a game, and I found it way too easy, because there is always a stupidly simple way to hack your ball around the obstacles.

Perhaps you might find such a game interesting, and certainly it is for a while, but I have been there, and I find real obstacles to be much more exciting. Real programming obstacles are neither processing power nor the size of computer memory. You can either stack up on hardware, or change your program to make more efficient use of resources. There is no point at which you are ultimately bound.

Real programming obstacles are of social nature, or less elaborately expressed: what other people want and/or reject. Some people have trouble with the solution that you invented. Some people want you to add a different solution on top. Other people have patented your solution already, and ask for compensation or replacement.

Although such issues can be solved through programming - by changing the programs implementation - such steps might prove to be less economic than other instruments of software development: writing manuals, incorporating third party solutions or plain negotiation.

In a software house or larger development community, all these slots are filled by different people, and sometimes, especially in the beginning, everything is done by the same guy. Yet all these things would not be necessary if other people would not exist, and you would only program for yourself.

When other people are involved in a game, it always gets exciting, at least for me. When the game offers a battlefield for multiple factions, requires getting to know other people to communicate your interests, be successful and avoid defeat, there is a myriad of delightful situations to be explored. As a plus, if the set of rules is confined, nobody gets hurt.

Such a game would even be interesting to programmers, because it deals with the big picture rather than its details. Often enough, programmers seem to know a lot about the details of programming, but little about the big picture of its social implications: when I tinker with my program, I would rather not be bothered by the outside and work in solitude. However, it might be my secret wish to be respected or even well known for what I do, and that, in some way, luckily, requires a quite extensive amount of human interaction.

Now, on to the fun part...

2. Developers, Developers, Developers!
(Rules of the Software Development Game)
I'm going to describe the game as a simple list of rules from which you can deduce all resulting game situations.

1. This game is a real-time or round based strategy game for two or more players.
2. The game is best played against multiple opponents.
3. The game can either be played against AI or human opponents.
4. You and your enemies play as software developers on the free market.
5. You may produce one or more applications.
6. For each new game, the free market is designated to only one specific niche, such as: browsers, chat programs, games, office suites, operating systems, programming languages and other fun categories we can come up with. (Adware?)
7. The free market is populated by computer users.
8. When an user installs your application, your market share grows.
9. When an user uninstalls your application, your market share shrinks. (Most people never bother to uninstall and just stop using crap, but for the sake of simplicity let's assume they do!)
10. The goal of the game is to get a 90% market share. That is as much as the Microsoft Internet Explorer had on the browser market in 2001. (This rule is negotiable, since goals of developers diverge in the real world: being profitable, filling a niche, etc. Market shares are a traditional way of measuring success though.)
11. When a developer achieves a market share of 90%, all other players have lost and the game ends. (In the real world, Firefox would then start kicking your ass, though.)
12. The free market is realized as a two-dimensional circular plane, where distances between users and apps represent interest.
13. Applications are represented by colored circles.
14. Users are represented by gray circles.
    
15. Developers start at the borders of the free market, starting with one application in beta stage, one programmer and a budget of $0.
    
16. In the beginning of the game, users sit in a neutral circle at the center of the free market. They don't know about your application. Each user has $100 to spend.
17. Time passes in days and years. One year is approx. one hour of playing time.
    
18. You can advertise your application for free by releasing a new version. In the real world, blogs and Twitter would pick up the news and propagate. In the game, all users will know instantly about your new release and reconsider their choices.
    
19. Applications possess three values which are attractive or repelling to users: performance, quality and cost. Cost is measured in Dollar. Quality is measured in bugs. Performance is measured in features. (I'm also thinking of other values like ease of use and total cost of ownership)
    
20. When an user is attracted by your application, he will move towards it. When he reaches the application, it will be installed and evaluated within a trial period of five days.
21. Features make the user happy. Bugs make the user unhappy.
    
22. If the user gets too unhappy on his trial period, he will uninstall the product.
23. When the user concludes the trial period, your software is still installed and the app costs money, you will be payed. (*cough!*) If the user had a competitors software installed, that software will be uninstalled.
    
24. If a user uninstalls your software in favor of a competitors software, you will still keep the money.
    
25. An advertising campaign will do the same as a version release: users will reconsider their choices. The more money you spend on your campaign, the more users will know about it.
26. Users will also tell others about the software they used or are using. This has the same effect as a version release and an ad campaign, but on a small scale. Only users around that user are affected.
27. To improve your app, you may hire programmers to work on it. A programmer obtains a fixed salary per month and fixes bugs on a daily basis and implements features on a weekly schedule.
    
28. Depending on salary (equaling experience value), the programmer performs better. More features are added per week, more bugs are fixed per day.
    
29. Cheap programmers produce more bugs.
    
30. As users encounter bugs, they become known and can be fixed. You don't know how many bugs your app has before the bugs have been found.
31. You can hire quality control engineers to find bugs before your users do.
    
32. You may release libraries from your application. Libraries are of little interest to users, but of big interest to other developers. Using libraries improves performance and quality of applications, depending on the quality of the library. A library is only as good as the application from which it has been singled out.
    
33. Developers can either buy your libraries or copy them for free, depending on license. When releasing an app or library, you may pick one out of three possible license models: commercial, open source and public domain.
34. Public domain means (PD): volunteering and hired programmers may work on your software. Only public domain libraries may be added. Your software is available for free. Commercial and open source software may use your software.
35. Open source means (OS): volunteering and hired programmers may work on your software. Only public domain and open source libraries may be added. Your software is available for free. Only open source software may use your software.
    
36. Commercial software (C) means: only hired programmers may work on your app. Commercial and public domain libraries may be used. Your software may be available free or for purchase. Only commercial software may use your software.
37. If your license is non-commercial, volunteering programmers (longtime users of your software) will turn up and commit patches. Some will fix bugs, some will add features (and more bugs). Quality control engineers may also volunteer for testing and find bugs for you.
38. If your license is non-commercial and you have hired additional programmers, the quality and frequency of voluntary patches increases as well (less bugs).
39. When singling out libraries from software, you may change licensing if the software is your work and not bought/copied from someone else (unless it was PD).

That's it so far. I'm sure the list of rules is not complete within the set I set up, but it should give you a pretty good overview of social aspects in software development. I would very much like to see such a game realized, and I would love to see the conclusions.