Time for a Paradigm Shift in Programming Pedagogy

### CODE ALA BUGS ###

A long-standing problem in software development is the detection and elimination of bugs. Numerous procedures such as Design by Contract , Cleanroom Software Engineering and Test-driven Development (TDD) are known to minimize bugs. Thus, one wonders why such practices are not used extensively in contemporary practices. Michael Feathers has recently noted that the common attribute among these practices was that they all required contemplation of the code’s purpose.

As an educator this lack of certainty regarding a programmer’s ability to write effective code triggers the question whether we are teaching programming courses appropriately.

### PEDAGOGICAL PRACTICES ###

Examination of current programming texts reveals the general approach to how programming courses are taught. This involves the reading, lecturing and discussion of the programming concept, studying code examples implementing the concept, and problem solving. The later generally requires the student to write a simple application involving the use of the above-mentioned concept or principle. The code correctness is easily determined because the application is simple. The application can be executed with a varying set of input data and the results determine the correctness of the code. This approach works adequately in such simplistic circumstances but fails when programming larger and complex software systems. Nevertheless the beginning programmer learns to depend on this quick method of verification during this important developmental stage.

### DENIAL AND INTERVENTION ###

The troubling aspect of this approach to teaching programming is the denial ensconced in the approach to the solution. The approach assumes the programmer will write code that will do what the programmer thinks it will do. The denial lies in the failure to recognize that the code often doesn’t do what it was written to do. In the words of Kent Beck
“I am good at fooling myself into believing that what I wrote is what I meant.”1
Even worse is the inability to alter behavior to compensate for this failure. Could contemporary computer science faculty be responsible for permitting this state of denial? Is it time for intervention?

### UNCERTAINTY IN PROGRAMMING ###

Programming students should learn about the uncertainty inherent in writing code; that all programmers, even excellent ones like Kent Beck, are susceptible to this uncertainty. Programming students should be taught that along with the recognition of the uncertainty implicit in the process of writing code, comes the realization that their solutions must be considered hypothetical. Hence, the validity of their hypothetical code solutions relies on how extensively the hypothesis has been tested. But wait! – isn’t this the scientific method every school kid learned in their K-12 years?

### PROGRAMMING AS SCIENTIFIC PROCESS ###

Considerable evidence exists that software creation is riddled with uncertainty and thus untested code represents at best a guess at a possible solution. Shouldn’t this be the fundamental principle taught to programming students? Why isn’t testing the validity of the hypothetical taught as the foundation of programming? In the face of the problems currently found in software development, why do we continue with a failed approach to programming pedagogy? Isn’t it time to confront the denial ensconced in the assumption that we can write code that will do what we intend? Hasn’t the time come to teach programming as a scientific process?

### SCIENCE & TDD ###

Test-driven development (TDD) defines a process whereby the programmer first writes a test which determines whether the intended function accomplishes its purpose. After the test is written, the function is then written to pass the test. Inherent in this procedure is the recognition that to truly understand the function one must understand how to test whether the function works as intended. This act is what Michael Feathers calls the contemplation of the code which is required to practice TDD along with other processes such as Design by Contract and Cleanroom Software Engineering. However, also implicitly assumed is the recognition that writing code is fraught with uncertainty and although the language of TDD is not that of the scientific method, the intent and the results are equivalent.

### REFERENCES ###
1. Beck, Kent (2000) Extreme Programming Explained: Embrace Change, Pearson Education, [ISBN 8178086670]