Conscious mental resources are severely limited. You can only hold onto so many things at any one time. There’s an upper limit on a size of a mental model you can hold in your head effectively.
Ideally, when doing some programming work, the only thing that your mental model contains is the essential complexity of the system you are building — just the bare bones, straight-forward, business requirements.
But it’s never that simple. We code in general-purpose languages most of the time, so the problem of expressing business requirements in code are also a prime concern. In practice this means that your mental model needs to contain both the business rules, and the mapping from these abstract rules to functions and modules and objects and tables.
If that was it, it would still be fairly manageable. But it gets worse. Say there’s a value files in the code that you’re reading. You may think “okay, somebody has a list of File objects — we’d better make sure they are closed properly when processing is finished. So you read a bit further, and realize that files is actually file names, a list of strings, not open File objects. Annoying ambiguity arising from poor naming. Now you need to add something to your mental model — when it says files, it actually means filenames. Every time you read that value’s name, you need to mentally remap from the crappy name to the real meaning. And then, in some other function 20 lines below, you see files again, and this time it actually is a list of File objects. Okay, you need to update your mental model’s remapping to only apply in one function, not for every case of files. This is getting complicated.
By now I hope it’s easy to imagine that the more of these mappings you need to actively track, the less brain power is left for other types of work. This is “cognitive overhead” — unnecessary expenditure of mental power on things that have nothing to do with the essence of the problem you’re trying to work on. Poor naming is just one example. There are lots more. But the general pattern is the same:
The more incidental, non-essential stuff you need to keep in your mental model, the less resources are left for actually doing your work. In a poorly managed code base, the cognitive overhead can be extremely high, slowing development speed down a crawl. Thus reducing cognitive overhead has one of the highest ROI of all the things.
Comments
Post a Comment