Boxing the Infinite Design Space

When I work on a puzzle I start by making piles of pieces that seem like they go together.  When I find a distinguishing feature on a piece (like an eye or a unique color for example) it helps me fix a position and I can start connecting pieces together.  If I can figure out where a pile or set of connected pieces should be relative to one another I try to place them approximately in the right spot on the table relative to the other piles I've made.

The most important pieces are the corners.  The only problem is that there are only 4 corner pieces (out of thousands) and in some puzzles it's impossible to determine just by looking at the piece, in which corner that piece belongs.  Edges are helpful too but without some kind of context it's difficult to know if an edge belongs on the right or the left, the top or the bottom.

With each puzzle piece slowly being discovered and placed, I am slowly exploring the available options for putting the puzzle together.  By identifying essential landmarks, I'm defining boundaries that let me explore within a specific context without venturing too far into the weeds.

Jigsaw puzzles are technically finite (there's only 1000 pieces in a box), but I wonder if there is still something to learn from puzzle building strategy when approaching a software design problem with theoretically infinite possibilities.  How can you quickly explore the design space so that you focus your effort on the design decisions that matter most?  Is it possible to efficiently draw a boundary around the seemingly limitless design options of a software system?

Boxing in the Design Space

This is the start of a workshop idea aimed at "finding the corner pieces" with the intent of developing a more systematic strategy for exploring the plethora of solutions that can exist within the design space.  I haven't tried this workshop yet, otherwise I would provide some specifics on facilitation and examples -- so if you try it out please let me know how it goes!

Exercise:  Quickly and collaboratively create 4-5 designs that are built to the extreme for specific, desired system properties and still achieve required functionality.  The general idea is that you would work in pairs or small groups to "turn the dial to 11" on specific quality attributes.

Outcome:  With these designs in hand (at least one per quality attribute) you now know what the outer edge of the design space will look like for any given property.  You cannot go beyond the extreme.  Your design lies somewhere in the middle as either a blended solution or some combination of boundary designs.

This workshop has some possible key advantages.

• The outcome of this workshop should help define the furthest extremes, effectively creating a boundary around what is realistically possible.
• In some cases you'll be able to expose tension between designs and this tension will be more obvious because you have concrete examples demonstrating how some system properties conflict.
• At the same time you will likely have concrete examples of mutual promotion -- cases where the same design can promote different quality attributes.
• In addition to boundaries, the various designs created also enumerate some alternative branches that might be possible.  For example, by identifying tactics that satisfy a quality attribute.

There are also some possible disadvantages to this workshop, reasons why it might not work as hoped.  The biggest one is that in all likelihood, the best design is not a direct combination of "best fits" for system properties, but instead might be an altogether different design completely.  Gordon Glegg shares some poignant examples of this common phenomenon in his book "Selection of Design".  In his book, Glegg points to the evolution of the gas engine as an example in which revolutionary design was required to find a satisfactory solution - evolution or the naïve combination of "best designs" actually resulted in worse engine performance.

So while this workshop may help to bound the design space, and in many problem domains for software it will likely work extremely well, when revolutionary design is required other methods of exploration may be needed.