Minimize cognitive footprint

Cognitive footprint is the sum of cognitive load over the life of the item in question. This may be an application, a framework, a project, a process, or something else.

Cognitive footprint is the area under the cognitive load curve.

You can think of cognitive footprint as the boot on your neck crushing the life out of you bit by bit. It is a measure of how much effort (time, money) you will have to invest to achieve your goal.

Cognitive footprint is important in many enterprises. It appears in many forms. Too few people stop to consider its effects.

Cognitive footprint determines in part the Return on Investment (ROI). This is because it is a large factor in Total Cost of Ownership (TCO).

It is true whenever you choose between different approaches. Or services, frameworks, architectures. Or whatever. And that determines profitability.

The questions we should be asking are:

• How much cognitive effort (hence time and money) will we need to invest to create this thing?
• How much cognitive effort (hence time and money) will we need to maintain it?
• How much cognitive effort (hence time and money) will we need to retire it?

In short, how much mental energy (brain work) will we have to invest over the lifetime of this thing?

When we choose a new framework, library, service, or language, too often we contrast the price vs. the benefits and nothing else. We forget to investigate:

• How hard is it to learn to use it?
• How hard is it to use it?
• How long will it take to train up users?
• Are skilled users readily available? Do we have any? How expensive are they? How rapid is their turnover?
• Is there documentation? How good is it?
• How rapidly is it changing? How much effort must we invest to keep up with those changes?
• How hard will it be to replace it with something else at end of life?

We should consider all the things that affect cognitive footprint. Letʼs not overlook how hard it will be to find trained workers. Or how hard it will be to train them internally. And then how hard it will be to keep those workers and to keep that training current.

For learners, cognitive footprint determines the time and effort needed to learn the skill. And it determines how much of our working day we will need to devote to maintaining that skill.

And it is not only a matter of the cognitive footprint involved. We should also be asking both do we need it and do we need it now? Best to learn just in time.

It goes well beyond choosing the right language, framework, service, etc. How you write your code is as important.

Do you make your intentions clear? Can you keep it simple? Did you use the least power? Will you plan properly and do it right the first time? Are you coding just in time or have you gotten way ahead of yourself?

The previous Craft Code methods have all been leading to this one.

Minimizing cognitive footprint means writing easier to understand code. That means creating fewer bugs. It means easier maintenance and evolution. It means limiting features to the necessary ones — avoiding feature creep. It means a design, both visual and mechanical, in which every item has a purpose.

In short: as simple as it can be, but no simpler. Put another way:

Minimizing cognitive footprint is about making everything we do much, much easier.

Hence, it is great for developer experience (DX) as well. And it benefits the bottom line for both the business and the end user. Nice! Itʼs win-win-win!

We recommend that you keep cognitive footprint in mind in everything you do. It is more than the cognitive load of this moment. Itʼs the sum of that load — the footprint — over the life of the evolution, whatever that evolution may be.

Look down those paths before you tread them. Then choose the shortest, simplest, easiest path that still gets you to your desired destination.