A while back I was part of a team that made a small advertisement movie. We planned this back in June, and finally made the shots in early September on a single day. There were quite some lessons I learned from them, and how they worked. Even though I didn’t get to work with Steven Spielberg, I was still able to see parallels in the movie profession to my life as a software tester and software developer. Time to reflect on that.

High-tech, low-tech

One of the most prevalent things I noticed is the use of both, high-tech as well as low-tech tools to aid in the movie-maker’s jobs. While filming some of the scenes, the movie staff had a camera dolly, a movable vehicle where you place the camera on. Almost all scenes were taken from a static as well as from a movement point of view. While rehearsing the different takes, the driver of the dolly used little strips to indicate where he had to stop, where he had to turn the wheels, or simply to indicate the trajectory of the movement.

While surrounded by high-tech cameras, the power strips on the floor as indicators seemed to be very low-tech to me. Indeed, the combination of both seemed to be a pretty good mix. Later that day, I noticed that the crew used more strips to indicate where the actors were positioning themselves in the different scenes. The strips were black in color. On a dark floor this means that you won’t see accidental takes of the strips in the final movie as well.

Another occasion for low-tech tools was the lightning setting. They had pretty bright lights with them. But from time to time these were too bright – considering outside weather conditions (we had a warm day with much sun, but also some clouds outside). So, in order to match the conditions, when the different light brightnesses hit their limits, the director used simple paper to shield away some of the bright light from the room. Here again, we had high-tech lights combined with low-tech mechanisms to match the current situation – the paper.

I think in the software world we make too much use of very high-tech tools, where low-tech tools would suffice as well. One example is screen capturing software, that records every keystroke you make during an Exploratory Testing session. Sure, you may spend the 200 bucks for that, but you might also reuse your smartphone to take a real camera shot of the keyboard and the screen – well, at least partially. For the taskboard on Agile teams, I also like to use sticky notes. In quick design sessions sometimes a piece of paper suffices as well. Oh, and notetaking during Exploratory Testing is best kept on a notepad of paper, since I haven’t found a way too draw something I have in mind down in a quicker way – actually using a tool might be a trap for testing in this case.

Rehearsal rehearsed

For each take it was clear that we will have multiple rehearsals, as well as a final take. First, there were several takes from different angles for each scene. Some show the room situation, some show the face of the speaker close-up. In the final cutting, these are combined. This usually means that you can vary the text quite a bit from take to take, but it should be consistent. In the end, what matters is the close-up take for the spoken language, as it’s way harder to re-fit the lip movement there.

In the software world I like to distinguish between practicing sessions, spike solutions, oblivious programming, and production code. In practicing sessions, I want to push myself one step further. I want to learn something new. It’s ok to fail at that, since I do it in a safe environment. It’s as if the camera is turned off for the moment, so that I can practice.

In a spike solution, I know I’m going to throw away the code. So, I try to do a good job, but I also don’t go for the perfect code. It’s ok to get close enough, the experience will help me write the production in the end. This is a pre-take with the camera turned on, but to check finally for light conditions.

Sometime I do oblivious programming when I configure a spreadsheet, or when I write an acceptance test using keywords. Some of the time I am aware that I am actually developing software right now, but sometimes I am oblivious to that, and just ignore it for the sake of making progress. When exercising a sentence at a movie shooting it’s oblivious acting. You might classify it as a practicing session, but it might also be oblivious acting. I watched some of the professional actors getting used to the vocabulary of the surroundings in such settings. Maybe it wasn’t oblivious in that case, still the camera was turned off, and it was not the “official” rehearsal.

When I write production code, I consider myself being in a close-up position in a movie. Everyone will watch me, everyone will see everything I do. When I test software, everyone will watch my finger tips. But it’s not depressing for me. Since I rehearsed all my movements, I know exactly what I am going to do next. I am in a safe position to go forward. I have been through this at least three times beforehand, just to get this one moment now – so I go for it.

In the movie shooting we had at least one rehearsal with the camera turned off, one for lightning settings, one as a backup, and one final shooting. Sometimes we had way more shootings. When I check what most of my programming and testing colleagues do in their profession, I get really upset. If ever, there is a single production shot, and then head for the next round – sometimes even without reflecting on what we can learn from the rehearsal experience. I wonder how many movies you saw which were shot with just one take. Would you call them professional?

Domain knowledge

I have rarely seen people learning about a new domain that quickly as I saw the movie crew. Yeah, right, I had to correct them from time to time, but usually I could provide an example of a phrase that I would use, and they could repeat that easily while it sounded naturally. This was pretty awesome.

When testing software, I want to gain an understanding of the problem domain. Often this means that I will create a (mental-)model of the program, and see where it matches my own expectations of that domain. When programming, I will have to understand the domain of the problem as well, but I have to understand the circumstances on a way more theoretical level at that time. From time to time I can do both, sometimes I prefer one over the other, but I have at least two different ways to gain an understanding of the problem domain.

Similarly the actors adapted a natural style of a programmer by language, gestures, mimic, and body movement quite easily. Over the years they learned these skills. For me, it seems as if they have a different perception of themselves, and with the exercise they notice different things about themselves, that I would ignore completely.

I think we would do better in software development using more low-tech tools, rehearsing our products more often, and learning how to learn new domains so that we may reflect them more quickly in code. I saw these skills were pretty evolved in a movie crew that I would call professional. I am not so sure about most software development (read: programming and testing) teams on that.