(I originally posted this on my MSDN blog.)
I’m about 2/3rds of the way through Object Thinking by David West. I picked it up on Mo Khan’s recommendation and it’s definitely worth a read. It’s not a new book (published in 2004) but the principles it explains are pretty timeless. I found the historical and philosophical explorations in the first couple of chapters to be particularly interesting. David West describes the long-running struggle between two schools of thought in software development; hermeneutics and formalism, or, in the words of Michael McCormick, “the scruffy hackers versus the tweedy computer scientists”.
Formalism is, generally speaking, a worldview that everything functions according to a finite set of unambiguous rules:
“Central to this paradigm are notions of centralized control, hierarchy, predictability, and provability (as in math or logic). If someone could discover the tokens and the manipulation rules that governed the universe, you could specify a syntax that would capture all possible semantics.”
Unsurprisingly, computer science has its deepest roots in formalism. This colors the way practitioners have approached the software development process:
“As a formalist, the computer scientist expects order and logic. The ‘goodness’ of a program is directly proportional to the degree to which it can be formally described and formally manipulated. Proof – as in mathematical or logical proof – of correctness for a piece of software is an ultimate objective. All that is bad in software arises from deviations from formal descriptions that use precisely defined tokens and syntactic rules. Art has no place in a program.”
Conversely, hermeneutics is a worldview that espouses interpretation, heuristics, and emergence:
“The hermeneutic conception of the natural world claims a fundamental nondeterminism. Hermeneuticists assert that the world is more usefully thought of as self-organizing, adaptive, and evolutionary with emergent properties.”
Hermeneutics has a long tradition in software development, though it’s been rather a minority point of view in that field. It has weighty implications as well:
“The hermeneutic [developer] sees a world that is unpredictable, biological, and emergent rather than mechanical and deterministic. Mathematics and logic do not capture some human-independent truth about the world. Instead, they reflect the particularistic worldview of a specific group of human proponents. Software development is neither a scientific nor an engineering task. It is an act of reality construction that is political and artistic.”
The school of object-oriented (behaviouristic) software design, XP, Scrum, design patterns, and other practices under the Agile umbrella are clearly hermeneutic in heritage. They disavow the idea that software development is merely a quest for a more perfect process and instead embrace the messiness and uncertainty of reality. That’s not to say that those practices are inherently undisciplined. On the contrary, they require great discipline. But they also celebrate and take full advantage of the human mind’s ability to cognate in ways that can’t be neatly summarized in a formula. To put it bluntly, Agile practices insist that people matter.
It’s impossible to say that one approach is clearly superior in all aspects. They each have their uses. I’m not sure you could make meaningful progress in fundamental computer science without a formalist approach. The formalists give us the raw building blocks upon which the software industry is built. However, when you turn your attention to the task of building real-world software for real-world people in real-world environments, you discover something disconcerting . . . the real world is friggin’ messy! Yeah, this job would be perfect if it weren’t for people. Computer science formalism tends to break down as you scale up in the real world and that’s where Agile hermeneutics steps in with its focus on flexibility, adaption, heuristics, and ultimately, delivered value.
Does it necessarily have to be that way? Is formalism intrinsically unsuited for the real world? I don’t know. I do know that formalism simply doesn’t yet have enough “precisely defined tokens and syntactic rules” to deal with the overwhelming complexity and ambiguity that we humans introduce to the equations. To some extent that merely demonstrates the relative youth and immaturity of the field. I have no doubt that formal computer science will continue to grow and bring deeper and more powerful understandings to bear. However, it seems that the more formal tools we have at our disposal, the more we overreach them in trying to solve ever more complex problems. I have no idea where our industry will ultimately end up but Agile practices are definitely here to stay for the foreseeable future.
It was interesting to observe the Alt.Net Seattle 2009 conference with these ideas in mind. Take, for example, the Open Spaces process we used to run the conference. It’s a very squishy sort of process, and almost (dare I say it?) mystical in its flavor. But somehow it works, and works well. In fact, I was struck by the group’s acceptance and willingness to go along with the opening and closing exercises, which aren’t typically what you’d expect engineering types to tolerate. It helps that the Alt.Net participants are predisposed to that way of thinking, I guess. All in all, the experience helped to confirm for me that yes, these people think in a different way.
I tend to be a formalist by nature and training. However, there’s a part of me that recognizes and embraces (with great relief) the value of aformal thinking. In my experience, it’s simply a better fit for many of the challenges I face in my professional and personal life. As West writes:
“ . . . object thinking and agile thinking are not a means for solving software problems; they are a means for creating better people and better teams of people. Object thinking and XP will produce a culture, not a technique; they will give rise to better people capable of attacking any kind of problem and able to develop systems on any level of complication and scale.”
SaintGimp 