IT#7 Technical Debt and Excessive Cognitive Load

 

#ITManagement #SoftwareEngineering #CognitiveLoad #TechnicalDebt

You can detect areas (user facing interfaces, pipelines, services, organizational workflows etc.) with significant Technical Debt by the presence of an excessive Cognitive Load. This is not a correlation, this is causation. Reduce technical debt by reducing the cognitive load required to deal with that area.

What is Technical Debt?

Technical debt is anything in your system that increases your IT operational costs without a benefit.

 

As a bottom line, you have Technical Debt whenever your IT operations leak money. “Leak” means "spending without short or long term benefits". Just like a leaking faucets in your bath room or a forgotten light in the closet.

Here are a few examples:

• Fuzzy and hard to use UI, API or feature set that forces users to contact your Customer Service with expensive customer support calls.

• Prod processes that fail too often and require a lot of oncall disruptions, investigations and work to fix.

• Processes (pipeline, services, etc.) that are not engineered for troubleshooting making each prod incident more expensive to investigate and fix.

• Oversimplified design that makes it very hard to add new features.

• Overengineered design that makes it more expensive to add new features.

• Breaking the original paradigm of your system design without proper refactoring/rewriting that results in a service/object-oriented spaghetti code.

• Using a wild zoo of various technologies (languages, platforms, services) requiring more headcount or more educated and expensive workforce.

• Design that increases cognitive load on your engineers.

• Organizational workflows, e.g. your highly-paid architect does every code review in your organization. For a large company, when every new feature requires a dozen or more approvals from some originally unclear set of people, so that you had to build a separate tool to find those people and track the approvals.

What is Cognitive Load?

Cognitive Load is the amount of information an engineer needs to operate at the same time to solve the task. Cognitive Load for an area or your company is the amount of information an engineer needs to operate at the same time to solve a typical task.

Basically, cognitive load comes from the amount of unrelated questions from different areas an engineer needs to answer to get to the solution. Cognitive Load may be evaluated by the number of topics that the engineer needs to know to solve a task. Example: Linux, Java, Java libraries, you custom Java libraries, AWS storage, AWS elastic computing, dockers, Cloud security, your application subject area, build environment, version control, components and services in your system, UI screens and API calls you expose to your customers... That's 15 areas.

Throw into this mix C++, Go, Google storage, Google Computational engine, and you get 19 areas.

Important: Cognitive load is not measurable exactly, this is more an intuitive value, but just like with organizational complexity, a rough number describing cognitive load is not linearly proportional to the number of areas, but at least quadratic (for a rough number). Say, in the above example the load jumped not from 15 to 19 (26%) , but from 225 to 361 (60%). That rough number gives you an idea of how much money you would have to spend maintaining your solution.

An intuitive reasoning about the quadratic dependency comes from consideration of questions, an engineer must answer. For example, how a click on button “Profile” that calls RPC GetMyProfile from my Go-based service will connect to MySQL data base if they are hosted on AWS EC with multiple instances and the service is in Dockers. That's not even quadratic, that's exponential.

However, most of this exponential complexity falls not on the company wallet but on the brains of your engineers. You have to hire more expensive engineers (or in some extent just more engineers), but since a difference between a good engineer and average engineers is huge and in times, your expenses are not growing exponentially. And if they do, there is likely a different reason like “#IT5 Corporate Parasites”. Still, technical debt costs money. Again and again and again.

Why Excessive Cognitive Load is a predictor of the Technical Debt?

Naturally, some cognitive load is needed. Your engineers need to know at least OS, language, basic tools and, of course, your product, at least the areas of it they are responsible for. What is bad is when you create (or let your engineers) create an excessive cognitive load.

Why is that so critical? Simple. When you throw something in the mix of required knowledge, the speed of doing things (fixes, new features development, etc.) is going down. Your engineers spend more time to do more or less the same thing. The time you pay for. How problematic is it? Let consider numbers from the balance sheet of large IT companies. For reference, compensation for your engineers and managers usually falls into R&D bucket:

	Google 12/30/2022	Microsoft 6/29/2022	Facebook META 12/30/2022
Total expenses	207B (19%)	115B (22%)	88B (40%)
Operating expenses	82B (48%)	52B (48%)	62B (56%)
“Research and development”	40B	25B	35B

You see? Employee compensation is roughly half of all your operating expenses. And we are talking about the companies with a lot of data centers filled with tons of computers and consuming a lot of electricity all over the world. And maintaining all these buildings, computers and infrastructure, buying new computers, opening new data centers, and all the electricity necessary to run them, all that costs roughly the same as your workforce.

Increase cognitive load and your expenses will go up.

So, for good engineering (and better balance sheet) follow the advice of Albert Einstein: “Make everything as simple as possible, but not simpler.”

But can technical debt come from a different reason than cognitive load on your engineers? Yes, here are examples:

• Confusing UI or API of your user-facing service that results in extra calls to customer service. Here you've put cognitive load on your users.

• Poorly written pipelines and services that fail in prod and result in higher expenses for oncall.

Technical debt may come from other reasons, but excessive cognitive load always results in technical debt, and usually this is the lion's share of your technical debt.