The circus and software

Yesterday I joined my family on a trip to the Circusfestival in Enschede. I enjoyed the show, and saw some really original performances, but by far the most crazy one was “Duo Sifolinis”. They built some weird construction with two wheels, see the picture. The thing itself turns around, requiring the guys inside to run to maintain their balance. They actually climbed on top of the wheels and jumped up and down, too. Given the size (12m high) and no safety lines or a net, that looked really dangerous.

I like the circus because it shows the interest to see and do weird and original things. In software development, things seem to be a bit less crazy, though don’t be fooled by first appearances. The circus discipline is a few hundred years old, and most circus artists are from a family of an old tradition, performing for generations. The difference is that the circus is supposed to look crazy and weird. Software development is supposed to look serious and tidy, but if you are in the know, then you’ve realized by now that’s just first appearances as well.

Now, how did I get from the circus to software development? Well, the most obvious reason I could think of is the acrobats on my business card and on the company banner. Some other parts of the official Info Support look & feel are inspired by the circus as well. The background image of our Powerpoint presention is the inside of a circus tent with a spotlight shining on the canvas (although you might have mistaken it for something else). Apparently, the image of the circus fitted the slogan, and seemed fit to convey a message of responsibility, ambition, discipline, training and creativity. But really, I just needed a backdrop to talk about some points made by Kevlin Henney on a Javapolis talk called “Perspectives on Agility”. He used an analogy with construction, but that’s boring, so I changed the examples a bit.

Kevlin talked about a lot in the presentation, but he emphasized a few original points for a software development process: governing principles and physical representation.

Governing principles are a set of ground rules that always apply to your process. For instance, when you are an acrobat in the circus, gravity is an important principle. So is training the human body for the act. No matter what kind of acrobatic stuff you are going to show, you cannot forget these principles. If you forget about gravity you are likely to think up some stuff that will never work. And if you forget about training, the risk level of performing an act raises exponentially, soon giving you a 100% chance to fail, and die and/or suffer horrible in the process.

Physical representation is about the human perception. Things that we can see, touch, smell and/or hear are more easier to understand, compare and to deduct than virtual things like text or software. Circus performers are masters of the physical representation. They use colourful suits, lights and sounds to emphasize their act, and use an attribute like height or speed to make the same stunt seem more difficult, just because they do it 12 meters above the ground. You don’t need to study on doing FPAs or have lot of acrobat experience to get an impression about the skill, difficulty or risks of the act. Your brain automatically categorize and label the observed activities, without you even having to think about it.

Software development still is a real-world process with human beings, so the above also applies to software development. In the software industry though, things like governing principles and physical representation are not explained or handled explicitly. We know stuff like that probably exists in software processes too, but their is no complete guide of all governing principles (although XP 2nd edition makes a fair attempt). In fact, I am having trouble (like Kevlin), to define even one undisputed governing principle for software development, one that will always apply, no matter what happens in the industry space. I encourage you to think of some though. 🙂

The lack of these governing principles could be one in itself: change. Any process in the software development should be able to accomodate change: change in methodology, change in people, change in tools, change in requirements, etc. Because it will change. Considering “change” a force of nature rather than something you can choose seems to make sense at this point in time. I think it’s an interesting way to think about a process, but “change” is a bit vague. If you narrow down the scope of the principles, e.g. “governing principles for my project/company/me/etc.” you should turn up with some other principles that would be a more useful guide in the development of your process.

The physical representation is the one we always know about, yet always tend to forget about in the software development. The most obvious ones are stuff like table reports with green cells for good, and red cells for bad results, or check lists you print out and keep on your desk, checking the paper as you go. Most agile methods actually promote physical representation even further, with things like crc “post cards” for user stories you can pick up, and just drop at a desk when you assign it to someone. Another thing considered “agile” is for instance connecting a lightbulb or a fog horn to your build server, which will light up or make noise when the build gets broken. In fact, it’s just trying to use a more natural and accessible way to spread information throughout your process. The only thing that’s agile about it is that you are willing to adapt the method of spreading information depending on the context of the information.

Both governing principles and physical representation are powerful concepts. Unfortunately, there is plenty of room for error. Governing principles like “build everything in our enterprise on technology xyz” or a physical representation like “this is 2.000 lines of code, and this is 2 million, so this is better” are superficial mistakes, bound to cause problems. That is why it is even more important to think about them for a while. The artists at the circus are at a level of maturity where they can do their job safe and efficient, in an environment where little mistakes could be literally fatal. They emphase their acts using simple tools and tricks, and make it very natural and accessible to watch. I should go to the circus more often, there is a lot to learn…