I got an idea for a videogame-based study that can help bridge the gap between software developers and academics.

The video game itself would be a simulator of a software development company, similar to what SimCity does for cities, SimAnt for ant colonies, and SimSewageSystem for the less-than-pleasant aspects of urban planning. I am aware of one software development simulator video game, SimSE, developed at UC Irvine by Emily Navarro and others, and used for educational purposes. There are many other software simulators, but they are not really supposed to be video games, and they are not fun.

In my game your company can of course take software projects, hire personnel, and have them deal with every aspect of software development, from setting the office layout to implementing XP or the CMM or the methodology of your choice. You deal with requirements changes, data corruption, and programming egos. You need to decide whether to ship your product with lots of known bugs, and who knows how many undiscovered ones, or to keep pouring money in a seemingly never-ending fix cycle in order to minimize the chances of wreaking havoc in your users’ lives.

What’s that you say? It’s not fun? Well if you think so you haven’t tried SimAnt. Or Patrician. In Patrician you’re a Hanseatic League merchant, and you get to do crazy stuff like expanding your warehouses, hiring drunkards in the tavern, and deciding how much money you donate to the local charities. And it’s fun.

Anyway, that’s not the point. What I’m trying to get at is that this game would give its players the capability to alter its simulation parameters. Let me explain. All simulators require some parameters, and the choice of parameter values generally reflects the assumptions of the game designers. In SimCity you can’t really expect your city to grow unless you cut taxes, and no matter how much money you pour into the health system your citizens won’t stop complaining. In The Sims you need to make friends with your whole neighbourhood to advance your career, and happiness largely depends on your furniture. Etcetera. Simulations of software development make similar assumptions: if you don’t do requirements work your costs will go up later in the project by 90%; the best developers are 3 times more productive than the worst; the best current tools can send your productivity up by 50%. I just made these figures up –for most simulators, if you disagreed you’d have no choice but to go with these assumptions (or stop playing the game).

Simulators, then, reflect the way that their designer sees the world, and since most software simulators are created by academics, they reflect an artificial account of how software gets developed in the real world. But in this game that I’m proposing, you allow players to set the simulator parameters the way they see fit. What happens then is that you have a much better chance of understanding how they see the world, and what is important to them.

So this is the study: We get people both from academia and industry to play this game (don’t ask me how because I haven’t figured that out yet). Each player sets the game parameters the way they think best reflects reality. I’m thinking of having about 10 parameters, in the form of questions with a slider that they can adjust. They can try out the game, and adjust the parameters again if necessary until satisfied.

And when they’ve all played the game, we compare their parameters. We don’t care how well they did in the game (though that would be interesting too). What we care about is how are the choices made by industry people and academics different. Do they assign similar values to people, processes, and tools? Do they intend to reward some strategies over others? Are each of the two groups internally consistent? The result would be a map of the perceptions of both groups with regards to priorities and success factors in software projects.

The reason why answering these questions is important is that there is a big divide between software engineering academia and industry, and we need to reduce it. At the last ICSE, for instance, which is largely an academic conference, I heard many variations of the wish of “making software engineering more like the other engineerings”, but I’ve hardly ever noticed such a need from the people that actually earn their bread from writing code. If we do nothing to address this divergence of goals and expectations, we risk pushing our field into irrelevance. If, on the other hand, we make the differences in perception explicit, we can begin to discuss them and fix the problem in two ways: by adjusting our research goals, and by educating developers on research that has been empirically demonstrated to work but that seems counterintuitive for them.

Playing this game, then, really is a bit of a convoluted approach to get people’s perceptions on software development. There are other methods to do so, such as a simple questionnaire. But I’d argue this method is more reliable than simply asking them to fill out a survey, since one can answer it as one pleases and forget about it, but investing effort and emotion in a simulation makes one more likely to consider these questions seriously, and to reconsider one’s answers in the light of their consequences.

So that’s the gist of it. The problem is, there’s no game yet. I’d like to develop it, or to help develop it, but mostly at this point I’d like to get your feedback. Is this feasible? Stupid? If you have any ideas on how to make this project better, or if you’d like to participate in any way, send me a note. It doesn’t appear to be a short project, but it might be a fun one!

Like this:

LikeLoading...

Related

About Jorge Aranda

I'm currently a Postdoctoral Fellow at the SEGAL and CHISEL labs in the Department of Computer Science of the University of Victoria.

Although you overestimate the effects of coffee, and with the obvious exception of the cleavage thing, I’d say the items in your list contribute to higher productivity by attracting people with better skills, rather than by increasing the productivity of those already in the company.