Moneyware: Comparing baseball and computer science cultures

"I think, really, that this is one reason that so many intelligent people drift away from baseball (when they come of age), that if you care about it at all you have to realize, as soon as you acquire a taste for independent thought, that a great portion of the sport's traditional knowledge is ridiculous hokum."
... Bill James

"It is not the task of the University to offer what society asks for, but to give what society needs."
.... Edsgar Dijkstra

My sons have prompted me to read Moneyball by Michael Lewis. Anyone interested in baseball should find this a fascinating read. While contemplating Moneyball I found myself making comparisons between baseball and software development. The book tells the story of Bill James who began to statistically analyze baseball data and his results showed that there were skills that weren't recognized as having appropriate value. Value is considered in terms of what wins baseball games, contributions to runs. His efforts to convince the baseball establishment were met with stiff resistance. His message, although statistically sound and rational, was not synchronous with an irrational and stubborn baseball culture. I wondered whether the baseball phenomenon was similar to the resistance of the academic computer science culture to incorporate new proven methods, such as unit testing, into fundamental programming courses. This "we don't need no stinkin tests" culture leads to the creation of professionals who haven't been taught a very valuable skill that is sorely needed in the contemporary IT work place. A parallel example in baseball is that as youngsters, baseball players are not taught to be more selective about which pitches they swing at. Just as it has been shown that on base percentage is a more meaningful (in terms of contribution to runs) statistic than the batting average, we still announce a player's batting average when watching a televised baseball game. When was the last time you heard a baseball announcer tell the player's on-base percentage? We are a culture paying attention to statistics that focus on a less important aspect of the game. In software development, although it has been shown numerous times that unit-tested software increases ROI, our industry still suffers from >50% failure rates in large IT projects. Nevertheless, just as in baseball, we continue to go about these projects in the way the culture dictates instead of following proven practices. Even worse, we educate future programmers the same way we did fifty years ago. Isn't it time to re-evaluate how we are educating our future software developers?

Moneyball describes the development of the science of baseball to the point where people began to analyze the game from the perspective of derivatives in the stock market. However, to accomplish this, a better system was needed to analyze baseball events. For example, when a person hits a double in baseball, there are so many factors in play, that from an analytical perspective the term 'double' did not contribute enough information. An entirely new system was designed to analyze the events in baseball. The same is needed in software systems development and in the educational process at the undergraduate level.

Over-Engineering and Design Patterns

I began studying design patterns in roughly the same period that I read Beck’s treatise on eXtreme Programming (Beck,1999). There is a conflict between the two schools and it’s important to consider it. The design pattern mantra is that we have identified a pattern that occurs often in programming and we have a way to solve it. No sense reinventing the wheel, there’s a pattern that solves the problem in a way that creates desirable software architecture. By learning these patterns we are creating a system of best practices which includes a richer vocabulary. By applying these patterns, we create more loosely coupled systems that are easier to maintain and change. From a pedagogical perspective, this is important to learn and a key stage to development. The process of understanding your system’s responsibilities and identifying these patterns is important in the development of OO thinking - which is entirely different from procedural thinking. But then the student encounters the “Stop Over-Engineering” people and becomes confused.

After passing through his phase of studying, understanding and applying design patterns, Kerievsky (2002) wrote a short paper entitled, “Stop Over-Engineering.” He thoughtfully describes his evolution to the following recognition: “But over time, the power of patterns led me to lose sight of simpler ways of writing code.” After relating a story where he realized, while pair-programming, that his approach to solving a problem was "… like applying a sledgehammer when a few light taps with a small hammer would do," he proceeds to describe what I believe is the next pedagogical stage in a programmer’s education, refactoring.
Nevertheless, a student of OO programming can’t stop over-engineering unless they know how to over-engineer in the first place. Kerievsky’s insight and subsequent treatise (Kerievsky, 2005) is the product of an active consultant in the software construction business. Students must learn the difference between the teachings of a professor and the teachings of a professional. The latter isn’t necessarily concerned with the entire pedagogical structure - their audience includes those who have mastered the stages leading up to their current level of understanding. The Kerievsky teachings are not for those who haven’t already studied design patterns. So, in my opinion, learn to over-engineer first (Gamma et al, 1994; Metsker, 2002; Shalloway & Trott, 2004;Martin, 2002 ) and then begin your studies of Kerievsky (2005) , Fowler (1999) and Beck (2002).

REFERENCES:
Beck, Kent (1999) eXtreme Programming eXplained: Embrace Change [ISBN 0201616416]
Fowler, Martin (1999) Refactoring [ISBN 0201485672]
Kerievsky, Joshua (2002) Stop Over-Engineering [http://www.industriallogic.com/papers/StopOverEngineering.pdf]
Kerievsky, Joshua (2005) Refactoring to Patterns [ISBN 0321213351]
Martin, Robert (2002) Agile Software Development: Principles, Patterns and Practices [ISBN 0135974445]
Metsker, Steven (2002) Design Patterns Java Workbook [ISBN 0201743973]
Shalloway, Alan and Trott, James R. (2004) Design Patterns Explained: A New Perspective on Object-Oriented Design, 2nd Ed. [ISBN 0321247140]