2 Programming practice

2.1 Tribeflame

In order to learn something about programming, we need to take a look at a programming process. In Chapter 3 (Programming theories), we will study the models of programming processes that are already found in the literature. But any model of programming processes must necessarily be an idealisation, to some degree; and while we are interested in finding out the ways in which these idealisations are useful, we cannot begin with the models. We have to start from the concrete, real work processes that the models represent.

Therefore in this chapter, we will study the work process of the company Tribeflame in Turku, South-western Finland, during four weeks in August and September 2011.¹ Tribeflame is a small company that makes computer games for tablet computers, primarily Apple’s iPad. At the time of the study period, Tribeflame had completed six games. Over the course of the study, the company worked on developing three different games, though most of the time was spent on one of these. At the time, Tribeflame consisted of the two founders, two programmers, and two graphic artists, though out of the six one worked part time, and one was only employed for the summer.

Is the development process used by Tribeflame typical? There is no reason to doubt that it is a typical small game company.² However, we are not really interested in the question of whether Tribeflame’s process is typical of programming in general: any real process will have its own peculiarities and in this sense be atypical. We are looking for some cultural traits and constraints on the possible forms computer programming can take, and for this purpose Tribeflame serves very well as an example. In Chapter 5 (Safety critical programming), we will take a look at some very different development processes.

2.2 The development team

Björn and Andreas¹ are the founders and owners of Tribeflame. They became friends in university and started Tribeflame together after having worked as employees for other companies for five or six years after graduation. Björn acts as the company’s Chief Executive Officer (CEO), and takes care of most of the administrative side of running the business. The largest part of his work, however, is to do the game level design for Tribeflame’s games. That means thinking up the puzzles that the player has to solve when playing the games. Björn has the final say regarding how the games look and work. Andreas acts as the Chief Technological Officer (CTO): he works mainly as a programmer, and has the final say in technical decisions.

Mickie is employed full time as a programmer. Before Tribeflame, he worked as an employee elsewhere in the IT industry. Björn, Andreas, and Mickie all have technical IT degrees from the same Finnish university.²

Matti is employed as a full time graphic artist in Tribeflame, responsible for producing almost all the graphics for the games. Fredrik, a programmer, is finishing his education at the university while working part time; he is about to start his own company in an unrelated business, which means that he is slowly ending his time with Tribeflame. Kati is a graphic artist who was employed for the summer to replace Matti while he was on vacation.

Tribeflame mostly works as a team of individuals with specialized competences. The graphic artists Matti and Kati do not have the skills to do what the programmers, Andreas, Mickie, and Fredrik, are doing, and vice versa. Decisions about running the business are taken jointly by Björn and Andreas and do not involve the employees. Besides the administrative decisions, Björn and Andreas share the formal decision competence, with Björn being in charge of product decisions and Andreas in charge of strategic technical decisions. However, most of the decisions regarding the products (the games) are arrived at in a common process of discussion and decision that involves everyone in the company.

2.3 The rhythm of work

The work at Tribeflame has a certain rhythm. Most of the work takes place in the company’s office, a single room in an office building next to the university’s IT facility in Turku (see Figure 2.1). At times, everyone is focused on their own tasks: the room is silent except for the clicking of mice and the tapping of keyboards, and the concentration is almost palpable.¹ At other times the room is alive with laughter and jokes – people constantly interrupt each other and show each other games and graphics on their screens. On frequent occasions, everyone leaves their desks and gathers together around the table in the centre of the room in order to have a meeting.

In Figure 2.2 we see the three main activities that are usually carried out alone, and how often they happen. Coding refers to the part of programming that is actually entering the programming code on the computer, as opposed to planning and talking about it. This task is done by the programmers. Graphics and animation refers to drawing the pictures and animations used in the games, and this is done by the graphic artists. Level design refers to thinking up the puzzles the player has to solve and entering them into the game in a suitable form. This task is done by Björn, the CEO.

We can see that these tasks are very frequent. Coding and graphics work happens every day; game level design happens whenever Björn is free from more important duties, though still quite frequently. These are the tasks that directly contribute to the games, so it is not surprising that they occur so often.

However, equally important as the time spent working alone is the interaction within the company. Figure 2.3 shows the occurrence of team meetings, which happen almost as frequently as the activities that contribute directly to the games. Occasionally the meetings are short but commonly last for an hour or two. On Fridays the meetings sometimes take up most of the day. During the final two weeks of the observation period, Björn instituted a daily meeting. Note that Figure 2.3 shows only internal meetings in the company – Björn and Andreas also have meetings with external contacts.

This means that the work within Tribeflame is forever rhythmically shifting between working more or less individually on tasks, and coming together to discuss the tasks. If viewed from above, the work in Tribeflame looks like the schematic drawing in Figure 2.4: the developers move from their desks at the periphery of the room to the meeting table in the centre; then they move back away from the centre to the periphery, and so on and so forth.

The meetings at the central table are not the only form of exchange between the developers. As shown in Figure 2.5, interaction is just as frequent in the form of discussions, informal chat, banter, evaluation of each others’ work, or working together on solving tasks. Schematically, the drawings of Figure 2.4 have to be complemented by the one in Figure 2.6, which shows the interaction that takes place between the developers when they are not in meetings.

The time spent on interaction is significant. As an example, Figure 2.7 shows the work interaction of Andreas on an ordinary Wednesday.² On this day, everyone spent more than half their time working with others. Over a third of the time was spent with everyone in a meeting around the central table (four people were at work during this week). Around a fifth of the time was spent in interactions in smaller groups, discussing and chatting.

As we see from Figure 2.7, there are two main blocks of time spent alone: one in the morning and one after lunch, beginning at around 220 minutes. Each of these blocks are followed by a meeting period involving everyone. Other types of interaction are spread throughout the day. Thus we see both the rhythmic movement between centre and periphery, which is illustrated in Figure 2.4, and the individual interactions shown in Figure 2.6.

The lesson of this is that the Tribeflame work process is not only a coordinated effort between specialized individuals – it is also an intensely social and communicative process in which common discussions are central. The function of the discussions is to build understanding in the company. Decisions are then made on the basis of this common understanding, which is constantly evolving and corrected by the developers. Though the developers have specialized roles, they all contribute to the common direction of the company’s games, and it is important that they are all heard. For example, though Kati is a temporary employee she is expected, even on her last work day, to participate in the development meeting and contribute her opinions,³ regardless of the fact that she will not be involved in the development process anymore.

The focus on common understanding and consensus-building discussions means that an authoritative decision is rarely made. For example, after a lengthy discussion between the developers about where on the screen the game menu should be placed, Björn finally takes a decision because agreement cannot be reached: “In the end I decide that it will be moved to the right. Sorry guys.” ⁴ Though Björn clearly has the authority to make the decision, and it is socially acceptable for him to do so, the fact that he feels the need to give an apology shows that this is not the normal way of reaching a decision in the company.

The focus on understanding also means that the kind of communication that could be called “information sharing” is relatively infrequent: if we understand information sharing to be a process whereby one person gives some information to another person, who mainly listens and can ask clarifying questions. As can be seen in Figure 2.8, information sharing is much less frequent than the more collaborative meetings and discussions shown in Figure 2.3 and 2.5. That the communication patterns in Tribeflame are characterized more by discussions than by information sharing is somewhat paralleled by the decision process, which can better be described as “decision reaching” than as “decision making”. The term “decision reaching” emphasizes that agreement and exchange plays a much larger role than in a process where decisions are simply made on the basis of the best available information.

2.4 Playing and planning

Playing the games that are being developed is an important part of the work process. For this, I use the term “playtest”. The developers continually run the game to see how some detail has turned out, but this is not what is meant by playtest. Rather, it is playing the game for a longer period to see how it works as a whole and how much fun it is. In this sense, there are two kinds of playtest: one when the developers themselves play their game, and another (“external playtest”) when they get someone from outside the company to play it and talk about their experience.

Figure 2.9 shows the frequency of internal and external playtest. It indicates that the developers do not start to perform playtests until near to the final week of the observation period. At this time, however, playtests become a nearly daily occurrence, and the tests have a large influence on the discussion topics and meetings in the company. For the external tests, the developers ask colleagues in the game industry, colleagues in other branches of industry, relatives, spouses, and even me – almost everyone with whom they come into contact and can persuade to try the game.

Besides playing their own games, the developers also frequently play other companies’ games and talk about them. Figure 2.10 shows the frequency of playing other games during working hours. Since the company was only observed during work hours, there is no data on how often other companies’ games are played outside work hours; but this clearly happens as it frequently features as a topic of conversation.

Planning in Tribeflame is neither very systematic nor very long term. There is a general idea about where the game is headed, but this is rarely written down or captured in a form other than concept sketches or similar. Tasks are usually planned one week ahead at the Friday meeting; they are written on a flip-chart or whiteboard and crossed out during the week as they are completed. New tasks that are discovered during the week are added to the whiteboard immediately. The tasks are frequently discussed during the course of the work. On an individual level, the developers sometimes write “to-do lists” for themselves on a piece of paper.

A humorous illustration of the ad hoc approach to planning in Tribeflame comes when Björn has difficulty wiping the whiteboard clean of old scribblings before a meeting. Instead of going in search of some spirit meant for cleaning he uses a small bottle of Minttu (Finnish mint liqueur) that happens to be standing around in the office, exclaiming: “whatever”.¹ Though the gesture does not strictly have anything to do with the planning process, it illustrates very well the mindset in Tribeflame towards planning: do whatever works.

From a business perspective, the goal of Tribeflame is to produce games that can be sold and generate enough profit to sustain the development. This, however, does not explain what it is that makes it possible to sell a game, or how to make one. Mickie explains that “the code is just a means to reach a goal”.² The game customers do not care about Tribeflame’s business goal: they have their own goal, which is to have fun.

Consequently, many of the discussions at Tribeflame revolve around whether the games are fun and what it means for a game to be fun – both their own games and those developed by other companies. The developers are conscious that what they are doing is a form of entertainment. When giving a presentation about the company, Björn says that “entertainment is the constant in the company.” ³ Andreas justifies charging money for the games by comparing them to other forms of entertainment: “it’s a form of entertainment, it’s fair to pay for games. People pay ten euro for two beers at a café” ⁴– meaning that the entertainment value justifies charging more than the production costs.