Chapter 8: Future Directions

Future Directions

The measurement of Cognitive Load in the code was collected via a follow-up survey with Likert Scale on the blocks of code that were actively debugged and engaged. There is a possibility that the perceived ex post facto differs from the load experienced at the time. It would be useful to devise an IDE plugin or some kind of instrument that could get participant feedback in real-time. There may also be interesting results derived through the use of some biometric technologies such as eye tracking, EEG, or fMRI.

This study focused as much as possible on testing the validity of its hypotheses with “real world code.” The JodaTime library is at times arcane, complex, and has years of accrued complexity that many participants remarked on throughout the study. There are multiple ways it would be helpful to reproduce these results with different libraries. For one, there may be so much accumulated cognitive load in a large library that looking for smaller libraries with defined problem spaces like JavaPoet may be helpful. Attempting on general purpose code that works in different problem domains such as the Apache Tomcat web application server or the OpenJDK may serve as validation for generality or find specific domains where managing cognitive load produces novel results.

Finally, it’s often argued that programming languages themselves have differences in “expressivity” (Graham 2001) in a way that suggests the intrinsic cognitive load may vary between languages such as Java, LISP, and Python. It would be worthwhile to investigate whether the same techniques yield similar results across languages, or whether the effects are different and language-dependent. Moreover, many of the techniques we applied were harvested from Refactoring catalogs that had discovered analogues to Cognitive Load Theory based from the Object-Oriented Programming paradigm. It’s often argued by practitioners that Functional Programming is more cognitively available, though the pattern literature for FP was not as voluminous when the study began. It would be helpful to have a deeper investigation of the links between functional programming and Cognitive Load Theory.

The measurement of Cognitive Load in code remains an open area of exploration. In this study, I chose to measure based on blocks of cohesive code at the method/function level. It is an open question how to quantify and explore the cognitive load imposed by an entire class as “something more than the sum of the cognitive load of its methods.” The relationship between classes, their usage, and how that affects the aggregated Cognitive Load of a component is also worth exploring.

Finally, as systems move from a co-located in the same address space model towards distributed systems/service-oriented architectures, additional complexity is introduced with respect to consistency, availability, and partition tolerance (Gilbert and Lynch 2002). This complexity is often addressed through tactics that include retrying in case of network failures, caching, and consensus-based algorithms, all of which impose additional cognitive load. As software becomes increasingly complex and responsible for more of the important work of humanity–such as autonomous vehicles and intelligent personal assistants– understanding development practices to make software easy to understand and fix defects in becomes ever more vitally important. Cognitive Load Theory offers a useful set of principles that have already been applied in instructional design, this work suggests it can be useful in software engineering and may help us “escape the tar pit.”