It's an amazing book. Reading it makes you feel that
- Every other book on software project management is just a rehash
- The description of the craft of software development is still correct - so assuming it was correct when originally written, nothing has changed
The first experience is of course unfair to the later literature. But still, the second experience does indicate that researchers in the field of software project management have failed to make any significant progress.
My reading of the book was well timed with my reading of the cover story of the latest issue of Technology Review, about the poor quality of software today - and how it appears to have gotten only worse lately. There are two things in particular that interest me in this connection:
- The failure or non-failure of object oriented programming as a silver bullet in software design.
- The implications of the explosive growth of the trade on the advancement of the 'standard professional skillset'
The second point is the easier to address, so let's do that first. There's a standard figure about the expansion in importance of science that says that of all the physicists ever working, 90% are active today. I imagine that number is an understatement for the case of software developers. In a trade that is as heavily expanding in importance and sheer volume as software design, maintaining a standard skill set, and standard technical literacy is an almost, if not fully, impossible task. This is both an issue of the throughput of the education system and an issue of the mental ability of the majority of software developers. The demand for developers therefore implies that the majority of the "technical community" that is software developers will be at at the beginning or intermediate level of professional ability, and moreover I suspect that they have grown up using mainly tools and environments designed specifically to be easy and approachable, not necessarily expressive and exact. Contrary to popular opinion I don't believe that ease of use of a tool necessarily makes the work- product produced with the tool better (although I will have good things to say about good tools later). So most of the developers in the world are conversant in JavaScript, VB Script and Visual Basic, and few of them are good LISP programmers. As mentioned earlier some of the most expressive and efficient development environments - for the trained user - are also some of the less accessible environments.
Back to the first point: Why did Object Orientation (OO) fail as a silver bullet for software design? Answer: It did not fail. It just succeded in disguise as component based development.
In OO design books the pervasive practice of component based development is often ridiculed as being only object based instead of fully object oriented. What we should learn from this is that the key component of object orientation (pun intended) is encapsulation, and the localization and naming of complicated things implied by encapsulation, not the entire bestiary of what you might call ontological linguistic devices available in full OO development environments. By referring to OO as ontological I mean the focus on things and their properties and making statements about them.
As it turns out the usefulness of active philosophizing (i.e. working explicitly with the ontological aspects of things, by doing OO modeling) is thoroughly dominated by the usefulness of simply having name and language for the concrete objects themselves, i.e. components. I'm not sure that it is surprising that there is more expansive demand for object users than for object makers The object maker ends up having a role similar to the language designer and the tool maker, and the trade of object making is therefore a much more select profession that that of the object user.
This development is related to another interesting development in software design, namely the birth of Software Pragmatics. This is important enough to merit capitalization.
To explain the grand statement, in linguistics pragmatics refers to the study of the relationship between language and context-of-use (This definition quoted from Speech and Language Processing. Among the topics of lingustic pragmatics are discourse analysis, and how language is used to model the world (semiotics). Software Pragmatics does the same thing for software development. The key discipline in Software Pragmatics is the pattern movement inspired by the well-known Design Patterns book. And of course there's the very influential book called The Pragmatic Programmer which is almost against theory, but just emphasizes everyday pragmatic thinking. I still think it's authors manage to make a great deal of very valid and general points, even though the scope of their book is not as grand as the scope of the patterns movement. Thirdly there is the new situation and conversation oriented project methodologies such as Extreme programming, which also fit the mold: Orienting the development of the craft towards elevating the quality of the work process and communication as opposed to a more theoretical rigorous invention of new technique which is the classical model for development of the trade.
The collection of books just mentioned have had a remarkable influence. I believe that the familiarization of huge numbers of programmers to component based development on the Windows platform is sort of the illegitimate father of this success. It certainly wasn't the heavy smalltalk bias of the original Design Patterns and Extreme Programming inventors. The component based development approach is exactly focused on reapplication of effective work processes as opposed to a more invention-like approach.
This brings us back to the original question of why Brooks' points on software development still apply. As pointed out by Brooks there have been numerous grand schemes to change the face of software development: Automatic programming, Generative programming, Expert systems, etc. Why the success of Component based development ? And why does this work where the grand schemes fail. When thinking about this I am reminded of Steve Mann's concept of Humanistic Intelligence. Humanistic Intelligence is a concept for intelligent signal processing that emphasizes the human brain as the intelligent processor of signals, as opposed to other concepts of machine intelligence, where the effort goes into adding intelligence to the machine. The idea behind HI is that it is orders of magnitude simpler to enhance the sensory experience of the human brain to include signals normally processed by machines as opposed to adding intelligent processing to the machines receiving the signals:
Rather than trying to emulate human intelligence, HI recognizes that the human brain is perhaps the best neural network of its kind, and that there are many new signal processing applications, within the domain of personal technologies, that can make use of this excellent but often overlooked processor
Software Pragmatics could be seen as an example of Humanistic Intelligence. The developers stays at the center of the development process, only his sensory experience is enhanced through better conceptualization via components and patterns and through better tooling. This also explains some of the more significant demographic shifts in the world of software developers. The rise of modern reflective languages like Java and Microsofts .NET platform are an indication that the most effective machine assistance in development is conversational/discursive in nature. Standard modern tools that programmers live by, like symbol completion and symbol browsing are examples of this. The developer is left in control, and automated programming is deemphasized (I consider the curse of the one-way wizard to be a step down in productivity).
Posted by Claus at June 22, 2002 10:27 PM