The Beauty of Live Art

Live Art as Duet DanceMy apologies if the title of this piece has misled you. My goal in today’s post is to point out a method of software and systems development that is proven to work very well for all parties involved. It’s been given lots of names over the years, none of them formal. In fact the whole approach is rather informal; probably much of the reason for its lack of exposure and use. (Management doesn’t like “informal” things, they’re too hard to quantify.)

The Live Art Method of Development

The central theory behind the Live Art Method is the assertion that the process itself is more organic “survival of the fittest” and less rigid pre-planned march to an end goal. While the goal can be maintained, the actual path to that goal will most likely morph radically during the effort. The Live Art Method is designed specifically to depend on this behavior.

Contrast: The Typical Project

Most modern software houses work from the precept that code modules make for the most cost effective and functional methodology. This is a well researched and proven truth, so no argument there. But the next step taken by most companies dooms them to repeating a failure already perfected by many others.

Code Modules are just that, modules of software that have well defined inputs and outputs. The magic that goes on inside the module is also well defined. With all that “well defined” flying around, it’s also totally natural to assume that the development team’s entire task is equally “well defined”. And if everything is so “well defined” then the schedule can be that “well defined”, and the progress can be … well, you get the point.

And the point … is dead wrong.

The Unforeseen

No matter how simple you think your task is, there will almost always be something you encounter that you did not expect. With luck and good planning, it can be dealt with in simple fashion. But sometimes the ramifications echo well beyond the origin. There are legends about giant projects sunk because some little tiny detail exploded into a massive fireball unexpectedly. Oops!

But how can you plan for that? How can you set a sensible schedule, hold to that commitment and still deliver functional software that meets the requirements? Simply put, by using Feedback.

Feedback Puts the Life in Live Art

Feedback is EssentialStop and think about everything you do in a day. You grab the car keys, the mobile phone, head for the door, etc. At every step you are depending heavily on your senses to tell you that you’ve successfully accomplished the task. If you just make a stab for the car keys and miss, you’re gonna look real stupid standing in the driveway without a way to get going. So you look, feel and perhaps even give them a little toss just to make sure you’ve got the right set of keys and they are firmly in your hand.

The dependence on our senses is so common to us that we barely even think about it. But it’s also a hallmark of living things. Plants depend on the gentle increase or decrease in light levels to tell them when to grow, when to seed and when to protect for bad seasons. Animals grow heavier coats of fur, get downright comical in their hormone-fueled frenzies, and basically follow the feedback their senses provide. Quite simply put, senses, the feedback they provide us, are what make us alive … and what allow us to handle The Unforeseen.

Building Feedback into the Module

This is perhaps where the real “Art” in Live Art Method comes into play. It is important that the Functionality Purpose of each module be defined not only in technical terms, but also in End-User Purpose terms. End-User Purpose means roughly what it does for the end-user and how they will interact with it. For example, the recent Viewer Managed Marketplace feature added to the SL Marketplace has an End-User Purpose of making it easier to put products up for sale. VMM also has a Functionality Purpose of making it easier to manage from the database server and “back-end” perspective.

In order to initially set the End-User Purpose, then to maintain and monitor it during development, the project team must include people that serve as end-users. This does not mean they have to actually BE end-users, only that they can perform as and respond as end-users would. Often you can borrow members from other teams to serve as proxy end-users. (However, us end-users would prefer being called on to contribute. But that’s another matter.)

The obvious change in protocol comes when status update meetings are held to assess progress and adherence to the schedule. Rather than the typical “Team Manager reads the report”, there is instead a two-phase presentation that includes both the Functionality Purpose (reported by the development team leader) and the End-User Purpose report. The latter should be given by an “end-user” from the development team, but at the very least must be heard by management and the other teams.

Documentation and Support

These are perhaps the most money-saving outcomes from the Live Art Method. Amazingly they are also often the most overlooked. The two-headed hydra of Customer Support and End-User Documentation not only feed off each other, they can quite easily become the most expensive monsters in any new project. With the Live Art Method, the End-User Purpose reports not only flag and document every instance of problems or issues, but also handily generate nearly complete end-user documentation. They also prepare the Customer Support staff with information as to what problems may occur, what choices were made during development to eliminate or work around them, and how end-users can avoid them in the future.

Normally these two incredibly vital functions are left as an afterthought, or at best they are assigned to someone in the “Documentation” department who isn’t really included in the development meetings or process and quite often has to chase people down to get answers. Once again the Live Art Method builds the creation of these resources into the overall design process, making them integral products and not (possibly) bolted-on patch jobs that someone realized were needed just a little too late.

The Case for Real End-Users

As mentioned above, it really is best to include real live actual end-users as the test End-Users during development. Most video game companies accomplish this in stages, using the developers and their friends as first-stage end-users, then eventually recruiting outsiders from random players in other games. The main reason to include real end-users is their ability to think of the entire product in full end-to-end terms.

Another of the unfortunate side-effects of modular software development is the tendency for the developers to restrict their thinking to “inside the box”. Even proxy end-users borrowed from other teams will bring that subtle prejudice with them. But people that actually use the end-product also understand its entire function. This gives them the ability to spot problems, conflicts and just plain dumb things way easier than someone that has a restricted perspective.

Getting It Right

This part is never easy. It always takes a few false starts to change a process over to the Live Art Method. By far the toughest change to make is doing away with the perception that everything must remain super secret … or else! There are times and means to protect truly proprietary details. But locking the entire process away in a dark hole is not the ideal way to include feedback in the process. (Like .. duhhh!!)

There are many examples of this process done properly. We do not need to look very far to find quite a few. Nor do we need to look far to find a glowing example of the exact opposite method, and the overall detrimental outcome to the “closed system” approach. With luck, maybe that number will be reduced to zero some day soon.

Visit the DGP4SL Store on SL Marketplace


Comments are closed.