Long-haired programmer; loves cats and dogs but doesn't have any.
The title is a reference to David Rees’s site and book, but actually this blog post is about filing (and programming, of course).
Software architecture is similar to filing systems.
What is a filing system?
43 Folders is a filing system. There is one folder for each of 12 months, and another folder for each of 31 days. To file an appointment or other dated task:
Double-entry bookkeeping is a family of filing systems. If you have a transaction that touches 2 accounts A and B (and most transactions touch at least 2 accounts), then you file it in 3 places, first (chronologically) in a folder called “the journal”, and also (chronologically) in each of two folders “A” and “B”.
Bullet Journaling divides journal items into six categories: Task, Event, Note, Task Complete, Task Migrated, Task Scheduled.
A filing system very roughly splits the mass of stuff into categories, like a hydraulic log splitter.
The key aspect of a filing system, for my purposes, is the checklist that allows you to figure out where something should be. You use it when putting things into the filing system, and you use it when looking stuff up in the system. Ideally, the checklist should be simple and concrete enough that you achieve a lot of consistency, between different people if your filing system is used by a team, or between one version of yourself and another version of yourself, if you are using the filing system at different times.
The previous examples of filing systems were sufficiently simple that the checklist is implicit, communicated simply by the names of the folders. However, a bad or complex filing system might have an explicit checklist associated with it, explaining each folder. Borges’s Celestial Emporium of Benevolent Knowledge is obligatory to mention here:
The slogan is “keep it simple - no, simpler than that”.
Getting Things Done is a filing system, with eight categories of “Inbox”, “Trash”, “Someday Maybe”, “References”, “Projects”, “Calendar”, “Waiting For”, and “Next Actions”. The checklist is complex enough that I won’t try put it here.
One simple software architecture is Model View Presenter. The names of these three folders are not quite as clear as the May, December, Fourth, Fifth, and so on used in the 43 Folders scheme. So there is an associated checklist for where code goes.
This is a very crude approximate checklist, but this is not a blog post about Model View Presenter, it’s about the analogy between filing systems and software architecture. A particular application will have multiple models, views, presenters, and they will act as subcategories/subfolders. But the ideas that there is a checklist-like description of where the code is or should be, and “keep it simple - no, simpler than that” is still applicable.
Another simple software architecture is Entity Component System, which (again very crudely) goes like this:
Again, a particular application will have multiple components, systems, and entities.
I believe that successful architectures oversimplify, that the best case is for the gnarly complexities of the real world to be shoved, like kitchen utensils, into a few overflowing drawers. If you have a nice and natural place for each exception and special case, then you’re either working with a toy example or you’ve overengineered your system. A few bulging suitcases is actually easier to deal with than an enormous pile of cases, each one customized in size and shape to its contents.
But I might be mistaken.
Opinions expressed are solely my own and do not express the views or opinions of my employer.