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 SpaceThis 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.
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.