Software Puzzle Analogy

Software people love analogies and metaphors. A well known (and perhaps over-wrought) one is the analogy with building construction. Here's another one: Developing software is a lot like solving a jigsaw puzzle.

Have you ever assembled a jigsaw puzzle? People always seem to start the same way, at the edges. Then they may move inward from the edges or they might start assembling a few pieces -- call them "islands" -- that will ultimately go somewhere in the middle of the puzzle. Islands will grow and new ones may spring into life. Islands may be joined together to make bigger islands or islands may be joined to the edges to make make peninsulas which eventually will connect to other edges to make isthmuses (isthmusi?). At some point the puzzle transitions from a collection of edges and islands into a single interconnected, but incomplete whole. Where there were once islands there are now holes. Then the holes are filled in, a piece here, a piece there, until only a few pieces are missing, and then in short order the puzzle is finally completed.

I started thinking about this when I realized that software projects tend to start at the "edges" too. Software projects are never conceived in isolation. They're supposed to fit into an existing environment. The already-existing things that make up this environment can be all kinds of stuff: the operating system on which the software will run, the hardware which it will interface with, the other software applications it's supposed to inter-operate with, or even existing business practices the software is supposed to automate. You can think of these things as edges (of other things) that will touch the "edges" of the fully realized software system. I can't necessarily speak for other programmers, but I know I always tend to start at the edges on a new software project, and maybe I do so for the same reason the solver of a jigsaw puzzle starts at the edges -- it's easiest simply because that's where there are the fewest choices.

Sometimes, though, I might start with a random piece that belongs somewhere in the middle of the system, with nothing that we might call an edge. "I'll start with the beta transmogrifier," I say, not because the beta transmogrifier is particularly important, but because it crossed my mind the other day, and kind of stuck there. Now that I've been thinking about it a while, I can sort of see how to start, so I do. I work on it for a while following each little piece with another logical piece. After a while, I really can't see how to take it farther, so I move on to another part, maybe back to an edge that I was working on before.

After a while, most of the edge parts are completed, and the islands like the beta transmogrifier have been connected to other islands and soon there's not just a bunch of more or less independent parts but the connected skeleton of a system. It's not complete, and not even really usable yet, but it's now all in one piece. Now I can start filling in the holes until eventually there are only random little holes left, which can be fairly quickly filled in. Then, in short order, the last piece is plugged in, and the system is complete.

-- CurtisBartley

When I first started thinking about this it seemed unlikely that this analogy would hold water in the light of day, if I may mix a few metaphors. I think the value of this analogy is descriptive and not predictive, but even so I think it holds up better than it has any right to. At first this left me, well, puzzled. Now after musing it over a while, I think I understand it. Puzzles and software have virtually nothing in common. This analogy works because puzzle solvers and software developers have a lot in common. It's really about how people attack problems that are too big to fit in their heads all at once.

-- cb

Curtis, you've nailed it on the head with "it's really about how people attack problems that are too big to fit in their heads all at once." I've pondered this in the past, particularly in relation to how many people do BigDesignUpFront with jigsaw puzzles? --DanGreen

The "islands" sound like WorstThingsFirst. -- JeffGrigg

Sometimes the "islands" are worst things first. It's worth pointing out that they could just as well be "easiest things first", though. It's just that you've got to start somewhere. -- cb

Are the island like a kind of early deliverable? When you've done an island you can see you've at least done an island and there's some clear "end-user" value in that. A complete island is a big enough chunk that it creates constraints and restrictions for the other pieces (which makes the other pieces easier, not harder - see FormLiberates). -- DaveHarris

The islands can be early deliverables (and maybe should be, more often than not). Note that all I'm saying above, though, is that there are islands, nothing about what kind of islands there are -- the islands may not be well chosen, but you pretty much have to create islands of some kind in the process of building software. You are exactly right about how "constraints and restrictions" created by "islands" (or "edges" and "peninsulas") makes the other pieces easier. That was one of my key points, although I only stated it explicitly about "edges". -- cb

My wife does BigDesignUpFront with jigsaw puzzles. At least, after she's done a puzzle a couple of times she seems to know where every piece goes. It's scary, but maybe that's just because I don't spend as much time on jigsaws as she does and so I don't get to know all the pieces of all the jigsaws we have. So I DoTheSimplestThingThatCouldPossiblyWork: i.e., leave the jigsaw puzzles for my wife to do. --GarethMcCaughan

I've found that solving the same problem several times also makes BigDesignUpFront easier in the software realm as well. -- JimWeirich

Jim -- I have found exactly the same thing. I also think this is where the BigDesignUpFront guys go wrong. They want to make it as easy to build a program the first time as it would be to rebuild it from scratch the second time. This is an admirable, but apparently difficult goal. I think they should think outside the box -- maybe we don't necessarily need to get it right the first time. See HowFastCanYouWriteCode (or for that matter RefactorMercilessly) for discussion along those lines. -- cb

This post:

    http://groups.google.co.uk/groups?selm=1107829738.090845.112680@g14g2000cwa.googlegroups.com

compares the scientific method to puzzle solving.

CategoryPhilosophy