The Guidance of Goldilocks

We are often advised to include just enough of this or that in our designs. It’s good advice. It doesn’t teach, it just reminds us to optimise, well, everything. Our development environments can often benefit from a substantial dose of just enough. Our designs too. Documentation. Our tools and methods, and how we use them, often cry out for some just enough. And don’t get me started on processes!

Take architecture as an example. Every design needs just enough architecture. Because projects vary in just about every way, just enough architecture for one is too much for a second, but too little for a third. Just enough architecture is the right amount of architecture for the project in question. It’s not a fixed thing that can be codified, followed and forgotten. Optimisation is a dynamic and continuing process. You need just enough of it, of course. 😉

Everything Goldilocks chose was ‘just right’, or just enough, in our parlance. This also embraces “Make things as simple as possible, but not simpler” (usually attributed to Einstein). I.e. Employ just enough simplicity.

Desperation can lead us to take a crude average and call it an acceptable compromise. Goldilocks is no such thing. It advises us to employ just enough up-front design, which is to say, the right amount of design. Given that this advice is offered to designers, it reduces to “Do your job right”. This is good advice, but a designer will do this anyway, so it’s a null command. This is why we stick with the phrase “just enough”. It means the same, but it evokes the spirit of the Einstein quote. It reminds us that too much design is sub-optimal, and too little design is sub-optimal too. Specifically, it tells us there is an optimum amount of design, which we should discover and apply. This optimum amount is not a theoretical chase after the perfect design (whatever that is). It is a practically achievable aim.

Repeat just enough to yourself at least once daily. But don’t restrict it to the amount of up-front design you should apply. Your design needs just enough documentation. The documentation should contain just enough detail, with diagrams that contain just enough information to maximise clarity. Your code needs just enough unit-tests to meet your needs. And so on. The Guidance of Goldilocks applies usefully at all levels, throughout your development environment. So, although it reduces logically to nothing, it still offers something useful. Good, eh? 😉

Porridge, anyone?

The Guidance of Goldilocks