One of the very first things you learn as a programmer is that you can’t comprehend every part of a system (at least, not at the same time.) Like with many other complex tasks, we break programming down into simple chunks which we can tackle mostly without concerning ourselves with the intricacies of the rest of the system. What these chunks are varies with specific needs and circumstances, but they are, all the same, bits of problem-space we’ve abstracted away, to be solved and then re-integrated into the final product.

The important thing to note is that this abstraction doesn’t just stop at one step. Each time we break off a conceptual piece of the puzzle, we do the following:

• See if we can break down that chunk into sub-chunks.
• Hook those subchunks together so that the chunk works as a whole.

What’s interesting is that, for the most part, systems design is entirely about putting off the work of ‘implementing’ a chunk, such that eventually, that need disappears. When we fully expand a system, breaking down each piece into progressively smaller parts, what we find is that the real software – the stuff that does the work – is the structure.

But what does that imply for us, as people who create these systems? It means that we need to think carefully about the way we structure our system – the way we break it down into chunks. Too few chunks and you aren’t letting structure handle any of your burden – you may be duplicating code that you could easily factor out into its own chunk; too many chunks and it may be difficult to climb back up the conceptual tree and hook everything together.

It also means that we need to spend time mapping out a project before we dive in, lest we find ourselves neck-deep in shark-infested waters. A little goes a long way, though. It’s not impossible to make these jigsaw pieces fit together, and when they do, you’ve created software that will last.