Chapter 1: Introduction

Introduction

Software engineering is one of the youngest and most dynamic fields in engineering. Naur and Randell helped formally define and introduce Software engineering as an area of study in 1968 with their landmark NATO software engineering report. (Naur and Randell 1969) The most striking finding in the report was the startling conclusion that 68% of all software projects fail. Since then, researchers have investigated many different approaches to extract software from the “tar pit” (Moseley and Marks 2006). Explorations have spanned a variety of both technical and non-technical solutions, spawning research in areas as disparate as software cost and estimation, software architecture and design, and software project and process management. Nevertheless, despite the dedicated effort of researchers and practitioners, in over 40 years since the landmark initial paper, research has made minimal ingress against the problem. A follow-up report by the Standish group in the 1990s suggested that overruns are still close to 189% (Hastie and Wojewoda 2015), though the numbers are in dispute (Jørgensen and Moløkken-Østvold 2006; Glass 2006). The 2015 CHAOS report shows that 52% of projects are challenged, 19% failed (Hastie and Wojewoda 2015).

One possible root cause of this churn arises from the inherent difficulty of the base activity of software engineering: computer programming. Leading software engineering practitioners argue that there are better ways to engineer software (Martin et al. 2016; K. Beck et al. 2001), the Agile software philosophy. Tools such as Test-Driven Development (Kent Beck 2002; Hendrickson 2008), Design Patterns (Gamma et al. 1994; Freeman et al. 2004), and Object-Oriented Programming (Booch et al. 2007; Shalloway and Trott 2004; Kent Beck, Cunningham, and Services 1989; Wirfs-Brock, Wilkerson, and Wiener 1990). Unfortunately, there is a dearth of empirical evidence supporting these practices (Wilson 2010) (Briand 2012). Moreover, software engineering has yet to develop a strong, unifying theory that can serve as an conceptual framework for software engineering study (Johnson, Ekstedt, and Jacobson 2012) (Jacobson and Spence 2009).

In parallel, cognitive science developed from the frontiers of psychology into a broad, impactful field that enhanced understanding of the human brain. Developing quickly from George Armitage Miller’s insight about the limits of human working memory (MILLER 1956), cognitive science blossomed into a myriad of disciplines exploring different aspects of human cognition. One of these fields emerged in the 1980s when John Sweller studied problem solving and developed Cognitive Load Theory (CLT) . Based on the work of Miller, Baddeley’s working memory model (Baddeley 2003), and collected evidence about short-term “working” memory, Cognitive Load Theory studies effects the arrangement and presentation of learning content has on learner memory and performance. From years of development across a variety of domains, CLT has shown evidence for particular phenomena such as the Split-Attention Effect (Tarmizi and Sweller 1988) and the Redundancy Effect (Sweller and Chandler 1991). Instructional Designers adopted the findings of CLT into their materials and began to achieve measurable, repeatable results that validated these findings and produced more efficient learning material.

These two fields are evolving independently, in parallel. But should they? Fred Brooks describes software as complex to build because “The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures...” (Brooks 1995) Additionally, Kent Beck describes the purpose of programming as "What is it that we want to get out of code? The most important thing is learning. The way I learn is to have a thought, then test it out to see if it is a good thought. Code is the best way I know of to do this." (Kent Beck 1999) Elements of memory, organization of information, and learning appear prodigiously through software literature, but ties to CLT are scant to nonexistent.

The question of whether CLT could inform the theory and practice of software engineering and its fundamental activity of computer programming drove this research. In this dissertation, I showed that it can. I suggested that a sampling of the best practices of object oriented analysis and design corresponded to conceptual best practices in Cognitive Load Theory. Using this premise, I designed an experiment similar to traditional CLT experiments that measured the efficiency of programmers to debug and fix software as a function of time to resolve an issue, defects introduced, and perceived cognitive load. I found that amongst both novice and experienced programmers, more people were capable of fixing a bug in refactored code, and that it took less time and introduced less average defects. I found that the subject’s internal measurement of Cognitive Load in the refactored code was less than the original code. This suggests that CLT can make a promising contribution into the scientific understanding of the complexity of software systems, providing a basis to evaluate software designs and understand technical debt.