Monday, February 15, 2010

Why Bother with Programming?

By James Paul Holloway
Arthur F. Thurnau Professor and Associate Dean, College of Engineering

James Holloway
Like most schools of engineering, the College of Engineering at the University of Michigan requires all first-year students to take a class introducing students to fundamental algorithms and programming.  Our class, “Engineering 101, Introduction to Computers and Programming,” has been running for 10 years in its current form, and similar classes go back many decades. 

But the reality is that after leaving Engineering 101, few of our students will write significant programs.  They might write simple data analysis codes or a few spreadsheet macros, or they might modify a few Matlab scripts provided by their instructors, but the longest codes they write from scratch during their years at Michigan are probably in the first year (students in computer science, computer engineering, and electrical engineering are an exception). 

Why then do we use a precious four credits of our curriculum teaching them to program in Matlab and C++? Is it because all of our graduates need to know how to program after they leave?  There is precious little evidence of that.  Indeed, what survey evidence we do have is to the contrary.  Apparently, most of our graduates will never program anything after they leave Michigan, and the 2003 CACHE survey bears this out more widely.

But our students will repeatedly use the mathematical logic that they learn in Engineering 101 and their other math courses. Engineering 101 teaches students to think algorithmically while simultaneously giving them concrete tools to design, construct and test algorithms. The class, in this way, combines learning a certain precise logical approach to the solution of problems with the experience of engineering design and prototyping.  This is its true value.

The fundamental constructs of algorithms -- sequence, iteration and selection -- along with the idea of combining simple building blocks in precise sequences to solve complex problems, are at the heart of deductive reasoning and systems-thinking.

Further, Engineering 101 allows students to better understand number systems and representation, as they learn twos-complement and the binary floating-point representations of numbers.  Indeed, the entire idea of using a data representation combined with well defined operations to manipulate that data is intensely powerful; it’s an essentially human capability that allows us to give meaning to information.  This idea becomes alive and concrete when the student realizes that the same physical representation -- really a collection of stored charges -- could mean the word “lion” or the integer 1852795244, or the floating-point number 1.85236e+28.  This understanding -- that symbols can be given meaning by our interpretation and by the design of operations upon then -- is a key to mathematical reasoning.

Introductory programming courses are active, because the essential learning takes place in the projects that students undertake.  In Engineering 101 most of these projects require students to think through and really understand mathematical concepts -- many overtly so: optimizing a function, or root finding to solve an equation, or doing numerical integration.  Even before students take an class in ordinary differential equations, we can have them integrate differential equations to predict the path of a body in the solar system or predict the population of a predator-prey system.  Many other problems are combinatorial -- a search for anagrams or creation of a sorting algorithm or building a Sudoku puzzle-solver.  This kind of tight coupling of mathematical content with problem-based learning is rare but surely helps to develop a good engineering mindset.

But most importantly, because such classes are project-based, they require students to be creative. Creativity is the means by which the future will be realized, and our educational system is increasingly lacking in means to develop student creativity.  We do little to help our students discover the value of their own ideas or to discover the power of their own minds.  But presenting students with problems that have multiple solutions, where no single implementation is correct and where they have to make choices in their work, breaks students out of the find-the-correct-answer mold in which they lived too long in their earlier education.  The challenge is not to make an introductory programming class like Engineering 101 relevant; it is to make the subsequent engineering curriculum just as challenging and demanding of creativity as Engineering 101.