Software Mind Palace

Sherlock Holmes:
Get out. I need to go to my mind palace.

Dr. John Watson:
[about Sherlock’s “mind palace”] It’s a memory technique, a sort of mental map. You plot a… a map with a location – it doesn’t have to be a real place – and then you deposit memories there that… theoretically, you can never forget anything. All you have to do is find your way back to it.

Lost time & energy – Too many times, the software engineers spent a lot of energy and time to find a feature in a big & messy code.

Other industries – Imagine that you will ask the engineer that has designed a car: where is the mechanism X or piece Y? You will have the answer very quickly.

Software: where is the feature? – Similar features will be found in different modules in different types of classes or design elements. A big God Class – usually “MainPanel”/”Main Frame”- could contain a half or more from a module code. You can find anything there, but very hard. More… a lot of features are “distributed” among the events or without any specific logic. Such code has these main symptoms: fragility, rigidity and immobility.

Complexity – yes, software specifics are incertitude & complexity. There is a reason that makes software domain harder. The question is, how much is inherent complexity and how much is undesired, unnecessary complexity related only to poor design?

Design Patterns – software development already has some instruments to fight with complexity. Design patterns, for example, are “reusable solution to a commonly occurring problem within a given context in software design” (Wikipedia). There are more good sources or sets of design patterns with proven effectiveness when being used properly.

Classical Patterns hype – if we will study a software product with a good design and good economics, only a minor part of this success is related to classical “design patterns”. Separation of Concerns or Single Responsibility Principle alone will be more effective than 20 patterns. Why? A design pattern will solve one or two specific problems, while these principles will drive all your design elements. Still, developers will talk much more about patterns than about these principles. A tool is always more attractive than a concept.

Readability hype – good design will offer readability and readability is something very useful for building & maintaining the software. Still, readability is presented too often as a solution, not as a desired outcome.

Hidden complexity & hidden patterns – Pattern: “reusable solution to a commonly occurring problem within a given context in software design“. How much we really study our context & our problem space to discover our specific recurring problems? Let me explain. Let suppose that in a software system the problem space will be decomposed in 1000 smaller problems with 1000 associated solutions, where some of them will be recurring problems/solutions. In software systems with a good improvement loop sometimes we could also observe this trend: from initial 1000 problems/solution tuple, we will evolve to 200/100 or fewer problems with a higher degree of recurrence. What’s happening? The developers will discover much more patterns, not necessary the ones from GoF or another book, but applicable in the context. Where is the hidden complexity? We usually try to solve a much complex problem than the real one, because we do not allocate enough effort & skills to discover the problem decomposition.

Mind Palace – readability is not enough. What are the Sherlock Holmes “memory locations“? Here is a theory: he was able to decompose the real world information in a very effective model, with a deep understanding or real-world recurring patterns. This model is his Mind Palace, a structure with minimum undesired complexity. Complex problems are decomposed in simple & known structures.  We could do (and sometimes we already do) that also for software. Consider the software itself as Sherlock Holmes memory. We could have, in fact, much more control over the software than over the deep mental structures.  We need to find a natural location for each piece and the result will be a Software Mind Palace.

Software Mind Palace symptoms:

• We know where are the features and pieces without reading the code
• we could navigate along the flows without looking the code. The surrounding context in this journey is always simple and familiar
• sometimes, we could perform remote (from code) “debug”
• … please discover yourself some others symptoms