Cognitive Load And Software Quality

Software design is a constructive art of the combinations of condition and context. Implementing a highly imbalanced conditional state generates a system with a high cognitive load.

Cognitive load refers to the amount of effort that is exerted or required while reasoning and thinking. Any mental process, from memory to perception to language, creates a cognitive load because it requires energy and effort.

Implementing a highly imbalanced conditional state generates a system with a high cognitive load. High cognitive load has a derogatory effect on our health and well being. Not to be burned-out too soon, we must take care of the load we carry or others around us are carrying, and we must build a team on a bedrock of psychological safety.

The Agile Manifesto — Individuals and interactions over processes and tools.

Individuals and their interactions are affected adversely by cognitive load. When high cognitive load persists and actions are not taken immediately to rectify the conditions, our perceptive capacity deteriorates as we become incapable of communicating and collaborating effectively and efficiently. Ultimately, we fail to make the right decisions on time.?

Lack of collaboration and continued wrong decisions, stakeholders start to become unclear about the domain. The business process progresses from complicated, to complex and towards chaotic.?

People masquerade and playact busy in uncertainty. They seek easy assignments of low or no value to not to be overwhelmed, or be reprimanded, demoted, or even fired.Difficult tasks of higher significance are not persuaded or aren't realized as it would be challenging, demanding time and effort.

Survival mode kicks in and fuels negative feedback loops that creates a culture encouraging unproductive activities and demotivating diligent workers.

Onboarding becomes difficult because the learning curve is steep. Replacement becomes tough and or impossible as knowledge can not be transferred.

On the other hand, the system is just patched, dependencies pile and become entangled, muddling the entire process and creating a ball of mud when the load is not reduced.

Soon the system becomes legacy which can't be sunset due to the fact that business knowledge rests in the system and business might rest in peace with it.

Functioning in ambiguity becomes a norm. Hierarchies stand tall. Bureaucracy reigns.

Competitors emerge disrupting the niche that the business survived. Yet still the legacy remains, unfortunately, as a parasite while making return on investment a myth.

The bright side is that such projects, in the right eyes, are a plethora of knowledge and wisdom, as there aren't many surviving.

Battle tested, abused systems whose stories must be listened, and lessons must be learned from their morals.

Acknowledged, begin extracting the hidden treasures.

First and foremost, identify the core. Have an automated test harness that will provide safety and insurance that critical functionalities remain intact during migration.

Spend more time reading books.

Thinking in Systems by Donella Meadows

Refactoring Improving The Design Of Existing Code by Martin Fowler

Working Effectively With Legacy Code by Michael Feathers

By extraction, I didn't mean make it a completely isolated stand alone system immediately, but decouple the core logic and make it modular, in small incremental steps refactoring to regain clarity in business domain knowledge expressed by the code.

Polishing performance and usability in customer interaction areas must also take the priority. Retain the loyal. Approach directly and get much needed feedback.

Skilled team management is crucial to delivery. Various improvements demand particular traits. Build continuously, buy carefully. Accumulation isn't the target, value addition is.

Now we have a modular monolith, well tested, abundantly documented.

Are you thinking distributed? Ask. Analyze. Wait. Wait.

Why? What is the need? What are the benefits to the business? What are business problems that are not being solved by the current system? Was that the business process problem or technical? Do we have a strategy? Do we have the budget?

Is our culture DevOps? Do we have a sufficiently skilled FullStack workforce that can take the responsibility end-to-end completely? Do we have a full observability of the current system? Are we able to break down requirements into tasks that are doable in a day or two and deploy to production??

Remember!

Distributed systems bring uncertainty. Acknowledge it.?

Failure and incomplete information is normal. It’s not exceptional.?

Decide data quality. Develop other qualities around it. ?

It shouldn't be the first approach especially for greenfield projects. But still in our context, provide the modular idea to settle down plentiful.

Ambiguities lie in the domain, don't help it further. It is the source of imbalance. Introspect, retrospect continuously to find clarity and purpose.

We must introspect deeply to negate our biases in order to improve communication and collaboration to? generate and reinforce positive feedback loops. Mindful approach must be a part of our self-improvement process.

We must contemplate and find a balanced mental state. We should try to understand ourselves and others better. Thinking positively is helpful. I will treat myself and others better. I will be kind. I will be humble. I can learn. I can improve. I will help myself and others. Before judging others I will try to understand myself first and try to look from their perspective.

We must foster all of the participants' systemic thinking and streamline the process to enable better retrospection.?

The whole is more than the sum of its parts - Aristotle

From years of experience in legacy systems, inheriting the cognitive load they owned, while pursuing to build quality software, Systems Thinking has been a blessing, a relief, an eye opener.

System thinking is about seeing connections, their influences and consequences within a given or imagined context. When we understand and used it well, it enables us to identify where cognitive load is, when the cognitive load might build and how to prevent it.

Tolerance of ambiguity, curiosity, openness, strong interpersonal skills, strong communication skills, asking the right questions, navigating complexity and analytical ability are some of the traits required for systemic thinking.

Adding the ability to switch between microscopic, binocular and telescope views, we enable ourselves to explore dimensions we never realized. Our understanding of the system as a network of interdependent relations of various subsystems and their role is extremely important to our stay focused in our goals and strategy, and produce synergic team effect to meet them.

What we can not observe, we can not monitor. What we can not monitor, we can not understand. When there is no understanding there is no clarity, leading to an increase in cognitive load. Overviewing and pin-pointing ability gifted by systemic thinking is a remedy to isolate and reduce it.

The ultimate goal of building any system is to create a seamless interaction experience between either human to human or human and machine. From codified and strict API, to metaphorical and exploratory GUI, towards direct intuitive modalities with touch, gestures or voice.

Application Programming Interface (API) > Graphical User Interface (GUI) > Natural User Interfaces (NUI)

Therefore, we must understand what cognitive load is, how systems thinking can help us improve our system analysis and design skills to reduce the cognitive load. By keeping cognitive load low, we maintain quality of our communication and collaboration high that is reflected in the system, its components and their interfaces and interactions we design and build.

This is a small attempt to express some of my understanding in brief. A lot of people contributed with free resources which I am always thankful to. This time I would humbly like to thank all those sharing knowledge for free.

Feedback is much appreciated. Thank you.