Mental models in software development

Mental models feature image

Software development is a horribly complicated enterprise. On the one hand, we have the inherent complexity of commanding pieces of silicon to do our bidding and n-levels of hardware, networks, systems, and frameworks between hungry users and awaiting restaurant owners (or whomever your business and its clients are). Not to forget bugs and mistakes on each of those steps. On the other - humans with their messy brains, unclear requirements, and deadlines.

To get things done reliably, the IT industry came up with a host of patterns and ideas, big and small. DRY, KISS, Clean Code, Clean Architecture, Design Patterns, TDD, Agile, Software Craftsmanship... and so on and so forth. The goal of this post is to present an approach one level higher - Mental Models.

A mental model is simply a representation of how something works. We cannot keep all of the details of the world in our brains, so we use models to simplify the complex into understandable and organizable chunks.

I discovered the notion of mental models on Farnam Street which you can see linked around my previous posts quite often. The idea seems obvious - find the big cross-domain concepts, understand them and use on a daily basis. The catch comes in work required since this is pretty much a life-long process.

So why even bother? Having a common language and underlying set of ideas that let you approach problems from multiple directions seems even smarter than memorizing current best standards for solving our local software development pains.

Example 1 - Feedback. Test Driven Development is a standard which we know helps in making good software. However, instead of focusing just on the TDD practice we can think of it as a manifestation of the idea of feedback in practice. Which opens up a significant discussion: 'what else can we do?'. If we commit to the idea of using feedback in the process, we can think of code reviews, retrospectives, usability testing, A/B tests, KPI monitoring, etc. And that's just on the software side.

Example 2 - Second (and n-) Order Effects. A lot of the things we do can have good first-order effects (we shipped without postponing a deadline) and negative or deadly further consequences (code became a mess, and we are now moving in a snail pace). Having this model embedded in your thought process not only makes you more likely to notice the problem before it materializes but also gives you plenty of ammunition to push back or at least plan mitigation of negative consequences down the line.

Example 3 - Antifragility. Is the software we are building fragile (fails all the time), just robust (can tolerate a lot) or does our process make it better with each failure?

The cited above FS guide is an excellent starting point with a broad overview of 109 mental models, split into different areas (e.g., Human Nature, Physics, Numeracy).

Check it out here