Archive by Author

Seven Wisdoms From The Theater World

16 Oct

One way to think outside of the box is to actually get outside of the box, and see how other industries or disciplines solve problems.  This cross-pollination can spark some creative approaches to handling issues. It can also reinforce good practices as well as deliver reminders about nonsense that should be avoided. I recently had a chance to jump outside the box and to immerse myself in the production of a play. This was a process that was not only enjoyable in its own right, but also offered ample lessons to apply to my daily toil of creating software.

I had often thought that the process of developing an application had a lot in common with putting on a play. There is a group of people who come together to conjure a creative work out of an idea. My participation in the Rockville Little Theatre’s production of “A Flea in Her Ear” confirmed that the similarities are striking. Both start with an idea that is wrought into a workable design. Based on the design a team of people with the necessary talents is assembled and a schedule is fleshed out. As the team begins to work towards its goal, time and money constraints shape decisions, design flaws are uncovered, and various obstacles and mishaps slow the project’s progress and shift its direction.

I will not belabor the metaphor any further, but here are the seven wisdoms that I will take back with me to the world of software development.

Delivery Trumps All

A play has a hard deadline.  The theater is rented and the publicity has started before the cast has even been assembled.  Delivery is not only a feature, it is The Feature. There is a countdown calendar to opening night and unlike software development  – no way to slip the schedule.

This hard time constraint forces the director to get the play into a deliverable state as soon as possible.  It might not be pretty after three weeks, but it gets the job done. This restriction also leads to a ruthlessness with features that cannot be made ready in time – be it a piece of set decoration or the blocking of the scene.  If it doesn’t work, it is stripped down to its serviceable minimum to focus the limited time available on what can be made to work.

The possibility of slipping the schedule in software kills its most important feature – delivery.  Users can’t use what they can’t touch. Better to cut out features that won’t make the date and put them in the next release.

Be Iterative

The production of a play cannot be incremental — it must be iterative.  The director knows she must deliver three acts on opening night, so all three are worked on throughout the rehearsal window.  The acts are made workable, then the outline is filled in, adding the layers of design and features that take the play from functional to fabulous. The director will not wait until the final moment to “bolt on” the last act, because two kick ass acts followed by 35 minutes of junk is unusable.

My colleague, Tim Plourde, has a wonderful chart from Jeff Patton ( ) in his cube that illustrates the difference between incremental and iterative approaches…

Software development should be iterative, get the basics working and then add the depth, color and texture as time allows.  Get it out there, get feedback from the users, change and repeat.

Banish the Creep

There is no scope creep with a play, no temptation to add a fourth act or change characters or transform a farce into a tragedy – because this will cause the end product to suffer.  The producer didn’t tell the director, “Hey, while you’re working on Act II, why don’t you add in a new character that moves the couch while singing ‘Back in Black’.”

We’ve all heard these phrases “well, it is only a few lines of code”, or “while you’re in there” too many times. And too many times, we have all been beaten on the head by the law of unintended consequences when these little creeps devour the timely completion of a project.

Do the Critical Bits First

There was one critical set piece that wasn’t finished until the day before the set was loaded in the theater.  It was then discovered it would not work in its initial form unless one of the actresses could replicate the vertical leap of Michael Jordan while wearing high heels.   It all came together at the end (as will happen when you have a talented team), but it caused a small cascade of other design changes that made for angst filled tech week, with work on the set continuing until just before the opening curtain.

The temptation in any endeavor is do easy bits first, and get them “done”. But if one of the pillars of the software design turns out to be faulty, it can cause even the easy bits to be redone or morph into hard bits themselves.

Share the Vision

Everyone on the cast and crew has to be intimate with the vision for the whole work.  While the actors have to know their parts, they also have to know how their roles mesh with the entire production, so the decisions they make are aligned with the vision for the play.  This provides the cast the framework for forming their roles and making suggestions for how various interactions between characters could be more effective in making the vision a reality. Our director did an excellent job in communicating her vision and outlining how every part fit within the whole, and reminding us from time to time what we were aiming for.

When developers and business analysts know the why – the what, the how and the when follow much more easily.  Design and implementation decisions are better made with context than in a vacuum.  Often the shared vision is assumed, and this can be a faulty assumption, especially once developers dive into their particular bytes. It is  good for the product owner to reiterate the vision from time-to-time to keep the developers from getting lost in implementation silos.

Right People In Right Places

The play provided a clear reminder that placing people in roles they can succeed in makes for the best possible outcome of any endeavor.  We did not have a few roles filled when rehearsals began. The delay and extra auditions were worth it to find the right cast.  As every part is critical to the functioning of the play, it is better to fill a role with someone talented, even if they are too old, too young, too tall or the wrong gender than to weigh it down with someone who meets the role’s description, but can’t play the part.

Setting up the right team is often the difference between success and failure of a software project. As the agile manifesto states, the key is people over process.

No Room For Divas

Finally, the cast and crew did more than was asked if them. They found myriad ways to help the production succeed, and did not have tantrums, even when they might have been warranted.  The overwhelming approach to problems was “we can figure that out, we’ll make it work”, and everyone pitched in to make that happen.

This generosity of effort is one of the things that I really enjoyed during the play, and one that we fortunately have in the culture at Fortigent. People take the time to make sure the whole is healthy by taking on the unglamorous tasks when necessary, even if that requires personal sacrifice.  Having this kind of environment makes it fun to come into work in the morning.

While I will miss working with the wonderful cast and crew from my sojourn into the theater world, at least I will be able to take back some lessons into my daily software wrangling. This adventure has already strengthened my belief that Delivery is The Feature, iteration rules and it’s the people that make it all happen. And it has already provided some creative ways of looking at problems, which should help me not only think outside box, but get outside of it too.