The Jigsaw Model of Software Development

Last night I came up with (what I think is) a pretty good analogy for coding. Coding is like a putting together a jigsaw puzzle.

Putting that last bit of code in place that makes the whole system work is just like fitting that last jigsaw puzzle piece in place - you get the same kind of feeling, whether it's a 'wow, cool' or a warm and fuzzy feeling. The difference is that when coding, you're not so much trying to find the piece that fits as making it.

Now, there are two ways to make a piece that fits. You can look at the specs to figure out what shape the piece should be, or you could look at the surrounding pieces and figure out what shape would fit in with them. When you're coding on a single person project, it's fairly easy - you know what the pieces should look like, and if one piece you spent hours on doesn't quite fit, you can change some of the surrounding pieces a little to make it fit. When you're coding on a project with lots of other people, it's more difficult. They might not have created their pieces yet, so you can't use those to create the shape of your piece; you have to use the specs. And you can't really tweak their pieces to make yours fit.

Of course, it's even more difficult when the specs aren't very detailed. Then you only have a vague idea of the necessary shape, and the developer coding the neighbouring piece may have a different interpretation.

It's even more difficult when you don't know the system. Then you're trying to do a puzzle without being able to see the neighbouring pieces, and without seeing the picture on the box.

And if you're really unlucky, you're sometimes not even sure which part of the puzzle you're supposed to be working on, and which part of the puzzle you're actually working on.

Modularity helps, though. If you can build up a chunk of the puzzle, then fit your entire chunk into place, you have fewer unknown neighbouring pieces to worry about. If you have to add two pieces here and a piece there, and you have only a vauge idea of what shape they should be, and the neighbouring pieces aren't in place yet (or they are, but you can't see them properly- i.e. they haven't been explained to you), it's extremely difficult.

Low coupling helps too. Sometimes your piece has to merge so much into another piece that it's more like one piece was torn in half, than two separate pieces.

You also have to consider the picture on the box, not just the shape of the pieces. Think of the picture being the coding style - how do you handle exceptions? Do you cache objects locally? Do you use factories, or do you just 'new' objects? All these things contribute to the picture, and while you may have the right shape, your piece needs to fit into the picture as well. And if you can't see the box lid, and the other pieces haven't been created yet or are obscured by bits of paper of lying on top of them, it can be extremely difficult to get the shape and the picture right.

So. Coding by yourself is like doing a small jigsaw puzzle - difficult at times, but possible. Coding a system with other developers can be like doing a little jigsaw puzzle that fits into a larger one - you get to complete a piece, and together you all make something that none of you could have done alone; or it can be like doing a jigsaw puzzle where you don't know what shape your pieces should be, you can't see the surrounding pieces, you don't know what colour and patterns your pieces should have on top, and you can't see the box lid.