As our first educational math game, Bubbly Primes, approaches completion, I’ve been reflecting on some of the philosophical aspects of software development. Although I’m writing about some technical aspects of the software creation process, I have the goal of this being interesting to non-programmers.

Image from Pre-compositional sketches for Romance for Violin, Bass and Orchestra. Copyright 2015 Alexander Bozman. Used with Permission.

The Art in Software

The threshold of chaos provides a wellspring of art, source of beauty and inspiration, and catalyst of revelation. Artists in many fields grow familiar with this.

Software development is rarely thought of as art outside of a few non-mainstream subgenres like musical compositional algorithms, and experimental games. In most software fields we simply don’t spend much time thinking about artistic issues, despite shocking parallels between the disciplines. And significantly – we usually try to keep our software safely away from the threshold of chaos.

The Formal Design

One of the most powerful tools for keeping this distance is formal design, which occupies a lot of energy in the software world, and raises a lot of the same issues that are of eternal concern to artistic work. There is a fortuitous pun here on the word formal. “Formal Software Design” connotes weighty official documents in massive notebooks, beginning with a page of legal-looking approval signatures, like formal dress at a ceremonial event. However, formal also refers to a description of structure, as when composers or musicologists discuss the form of a musical composition.

To me, good formal design really means carefully thought-through creative thinking and planning. We need it for the same reason it’s difficult to do. There’s a joy in implementing ideas as they come along. They build onto each other, and can create wonderful inventions that would have been hard to conceive ahead of time. However, even the simplest of software can quickly grow out of control, like a cute little baby pet alligator in a tiny apartment. Software design attempts to predict and organize complexity in ways that avoid the unwieldy tangles that spell trouble.

There’s plenty of common wisdom (and folklore) on the topic. The Joel on Software blog has a series of excellent blog posts advocating the value of up-front software design, as well as smart, practical advice on how to do it. But beware: medium and large projects are continuously tempted with overweight designs which attempt to pin down all the details, which they can’t, subsequently leading to a wide variety of flavors of failure. It’s a cliché that such software, when successfully completed, is frustrating for the user because its goal became “meeting spec” instead of becoming a useful tool for accomplishing user goals.

The Moderate Design

One excellent approach, like with so many things in the world, is moderation. Insufficient advance design can wend its through the gates of chaos, and continue deep into the kingdom. Too much advance design wastes time, chokes creativity and suppresses serendipity. Finding a balance? Well: somehow moderation can be easier to talk about than to achieve. A thoughtful analysis of this topic was written by Tynan Sylvester in his fantastic book Designing Games. Actually, Tynan proposes a much more sophisticated solution than moderation, advocating an adaptive approach. There’s some great thinking there, but it is not necessarily a generally applicable solution, and in fact probably wouldn’t have made sense for Bubbly Primes. We used the simpler solution of an appropriately moderate design that not only provided the right level of structure, but allowed a fascinating experiment to take place.

I’ll write about that experiment next time.

To Be Continued …