My experiences at MSOE, Auburn, as well as my time with a professional training company, have solidified a very hands-on, pragmatic philosophy to teaching software engineering. The primary pedagogical approach at Internetwork Expert, Inc. was to introduce networking concepts, then demonstrate them via exercises. The material was reinforced through the repetition of hands-on labs and troubleshooting exercises. This strategy unintentionally incorporated five of the six learning domains in the revised Bloom’s Taxonomy; remembering, understanding, applying, analyzing, and evaluating. It was learning by seeing then doing. I believe this type of teaching strategy is especially effective for software engineering, as it introduces the concepts and gives the students exposure to the application of them in practice.
Imagine in 1994 the Bridge Building Group released a report that bridge builders spent $250 billion in 1993, building 175,000 bridges. Of these 31% had to be cancelled, 52% overran their budgets by nearly 200%, and only 16% of the bridges built were on-time and on-budget. Now imagine that in 2013 the Bridge Building Group announced that over the past twenty years bridge engineers had improved these numbers to only 18% failures, 43% over budget and late, and 39% on-time and on-budget. It’s disturbing that a profession could have such abysmal outcomes, yet that’s where we are with Software Engineering. These statistics were taken from the Standish Group’s 1994 and 2013 Chaos Reports on the state of software development. While their analysts attribute much of these gains to the advent of agile software development practices, it is clear that we need to continue improving our practices. I believe research into low-cognitive load techniques such as repatterning, can contribute to the agile body of knowledge, while ideas like process minimalism can shift agile to new places.