Inheriting Code

Have you ever inherited badly written code from someone else? It's a nightmare isn't it? Even well written code can be hard to digest - mentally speaking. You often need to spend days studying it before you can add just one extra line. Why did they do it that way? Where did they get that from? Why are they bothering to do that? What's that all about?

Part of the problem is you need time to build your own mental model of the software before you can deal with it. The software documents the solution but you need to understand the problem space too. Wouldn't it be good if the cost of bootstrapping a programmer's mental model could be lowered? To enable a new programmer to start juggling quicker.

To achieve this the problem space needs to be intimately tied to the solution space - stuck together: Goo-style. A new programmer inherits the existing software solution but it's really the problem space they need to know to start making a difference. So we need to intimately stick the code and the problem together. The programmer can then context switch quickly between "why it's a problem" and "how we solved it". Every line of code and module needs to relate to the problem it's trying to solve. For that matter every artefact (Thing) in The Goo should be associated to its underlying raison d'tre.

I see the association as: Pain -> Problem -> People -> Solution. A new programmer must freely traverse this scaffold so they can start sticking their own artefacts together - quick!