Thursday, August 28, 2014

What A Piece of Plywood Can Teach Us About Software Design

When I was in high school and college, I was heavily into technical theatre (scenery, lighting, etc).  Today, I want to talk a little an experience I had studying stage design, and somehow try to relate that back to software design, business analysis and problem solving. 

A little background on on me.  I love to build things.  I love the idea of shaping things by hand, of and building things from scratch (it's also why I enjoy cooking).  I got into theatre through carpentry.  I started off building stuff, and eventually worked my way up to designing the stuff to build (hey, software parallels already!).  I loved the idea of designing and building these artificial worlds for characters to inhabit.  So, I did a bunch of shows, and also in college I took a few electives in scenic design.

In my scenic design course, I ran across a quote that was attributed to famous scenic designer Ming Cho Lee, one of the leading voices in contemporary stage design.  I'm unfortunately unable to find the original reference or citation here, so I can't swear to the source of the quote.  But this is more a story about me, so I'm not sweating it.  What Ming Cho Lee (allegedly) said was this: "Once you know a piece of plywood measures 4 feet by 8 feet, you will never be as good a designer again."

I want to pause here and explain why the size of a piece of plywood would be important to a stage designer.  While scenery can come in all kinds of shapes and sizes, there are two major building blocks that go into most designs.  First, there are upright framed pieces called flats, which generally make up the "walls" of most sets.  Second, there are heavy duty flat pieces called platforms or risers, which are used to make raised floors or levels.  Most sets are mostly made of combinations of these two basic components.  

As you've probably guessed by now, both flats and platforms are usually constructed from plywood - in both cases, a wooden frame of some kind covered by a piece plywood (thin paintable plywood for flats, heavy duty flooring grade plywood for platforms).  And since plywood comes in 4' x 8' sheets, the most convenient size of wall flats and floor platforms to build is 4' x 8'.  In fact, many theaters keep a stock of 4x8 pieces, which can simply be reassembled and repainted into any configuration the show requires.

So, anyways, I was pretty angry about what Ming Cho Lee (allegedly) said.  As I said earlier, I came up as a carpenter before being a designer, so I knew exactly how big a piece of plywood was.  I had always considered my knowledge of how to build scenery an asset to my work as a designer - when I designed something, I knew how it would be built.  I knew I wasn't designing anything with impossible geometry.  I could draft up plans for my carpenters, anticipate their problems, and have good conversations.  I'd seen a number of student designers get into trouble from not realizing that there was no way to get out of that exit door, or that the walls couldn't come apart like they were anticipating for the final scene.  I never had those problems.

Knowing about construction (I felt strongly) made me a better designer, not a worse one.  So I interpreted Ming Cho Lee's alleged quote as something an artist who was too avant garde for their own good would say.  Something like "the true artist doesn't concern themselves with the mundane details of how the art is executed" or some such.  I saw it as impractical nonsense - hey, dude, however "pure" your art might be, we're going to build it out of plywood eventually.  Screw you, person who might be Ming Cho Lee!

I didn't really revisit my opinion of (possibly) Ming Cho Lee for a long time.  But a decade later, and after moving into a job where I help build things out of 1's and 0's instead of plywood and 2 by 4's, I think  I finally get what (possibly) Ming Cho Lee was trying to (allegedly) say.

What I think he wanted to do was to draw a distinction between the problem of design, and the problem of execution.

An empty theatre is a magical place.  It can be anything and anywhere, from a Viking long boat to the palace of a king to a shabby apartment to a merry-go-round.  Whatever fits the needs of the show we've chosen to put on and what we're trying to say by producing that show.  The designer's job is to envision a world for these characters to inhabit that looks right - right size, right feel, right flow, right colors.  This is a highly artistic endeavor.  What's right is what looks right in the designer's head (generally communicated in drawings to the rest of the team).

When it comes time to actually construct the design, we might make certain tradeoffs for practicality - if the walls in the drawings are 8'3" tall, we might ask if we're OK shrinking them down to 8'.  If the stair landing measures 3'10" x 4'2", we'll ask if we really want to construct something custom, or if the 4'x4' platform we have in stock will do.  Often, if it's not a big deal, we'll tweak the original vision slightly to make the execution easier.  Sometimes we won't - "look, I realize 8' walls are easier to build, but we really need 10' walls here to convey the grandeur of a Victorian mansion."  Sometimes this is a construction convenience, sometimes this is budget - "I'd really like 6 over 6 divided light windows, but the windows we have in stock are single pane, and we don't have the budget to buy new ones, so we'll use them."

But regardless of how much freedom (and budget and time...) we have, what we want to do is design the thing that's "right," and once we know what that is, consider making tradeoffs for convenience in execution.

But now consider what happens if our designer isn't thinking about what looks "right," and instead tries to think about the execution first - the designer who's thinking about the plywood and not the design.  Rather than designing a properly proportioned space with the right "feel," they'll start lining up 4x8 flats across the space until it's "close enough" to the size we need.  Rather than thinking about what the right proportions are for that balcony hanging over the garden, they'll start by assuming we'll take a 4x8 platform we have in stock and putting it up on legs.  They'll never consider a wall that's taller (or shorter) than 8 feet, no matter what the show is.  They'll never consider a transition into the sunken floor of the living room that's not a straight line across (and a multiple of 4' long).

And this is where they've stopped designing.

It's no longer the case that we're adapting a vision to fit practical reality.  It's that we've never worried about a vision at all.  We've never considered any elements that weren't easy, or weren't "standard" sized.  We'll wind up with a set that's probably functional, and certainly easy (and cheap) to build.  But we've never really considered whether it was "right" for show.  We've abdicated being an artist to instead be a draftsman.  And the art (by necessity) suffers.

OK, so why am I talking about this in a blog that (allegedly) about software in general, and business analysis in particular?  Because I think the same logical trap of the set designer stacking up 4x8 blocks applies to someone designing a piece of software.

The heart and soul of business analysis (to me, anyways) is to understand our users goals, objectives, and desired outcomes, and understanding how we'd know when those goals were achieved.  It's about the "why" and the "what," not the "how."  Eventually, of course, we'll need to work with the rest of our team to define the "how," and the "how" is what we'll actually implement.  But thinking about the "how" too soon can turn your brain off - you stop listening for the goal, and simply start "stacking up" the tasks we need to do to make whatever they asked for "fit" in our current solution.

For example, let's say we're working for an e-commerce company.  They've done all their business to date on a "sales" model, but now they also want to add "rentals."  As we're working with the customer to understand how rentals work, we think to ourselves "OK, we already have an "Order Type" table - we can just add another Order Type called "rental" and it will flag all the rentals.  OK, customer is talking about returns now - we'll just add another "Return_Type" for rental return.  Easy peasy.

Except that we've really stopped listening halfway through the conversation.  We envisioned an easy solution, and started filtering everything the customer said through that lens.  We stopped thinking about what was different for rentals, and started thinking about how we'd make them fit our existing paradigm.  Which might be disastrous.  Because there might be a whole host of things that might be critical to launching a rental business other than just having another order type.

Is rental a separate kind of inventory?  Do we need to asset tag them separately from "purchase" inventory?  Don't we need a way to track which item is where?  What happens if we get something back "damaged."  When do we allow someone else to rent something that's currently rented to someone else but is expected back soon?  Just having two more order types ignores a whole host of areas we might want (and need) to explore.

We need to understand the problem first, and only when we've got that down should we worry about what our options are for implementation, and which options are easier.  The approach that's simplest in our architecture is OFTEN the best approach.  But if we assume an approach too early, we miss the opportunity to discover other options that may be superior.

Listen to your customers, understand them well, and then be the best designer you can be. 

No comments:

Post a Comment