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:
- If it is this month, you put it in the folder labeled with that day of the month.
- If it is further future than that, put it in the folder labeled for that month.
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:
- Those that belong to the emperor
- Embalmed ones
- Those that are trained
- Suckling pigs
- Mermaids (or Sirens)
- Fabulous ones
- Stray dogs
- Those that are included in this classification
- Those that tremble as if they were mad
- Innumerable ones
- Those drawn with a very fine camel hair brush
- Et cetera
- Those that have just broken the flower vase
- Those that, at a distance, resemble flies
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.
- Would it need to change if we switched from one user interface (such as the web) to another (such as voicexml or command line)? Then its part of the View.
- Would it need to change if we switched from one database (such as mysql) to another (such as postgres)? Then it's part of the Model.
- Everything else goes in the Presenter.
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:
- Data goes in a Component.
- Code goes in a System.
- Nothing goes in the Entity.
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.