In the business of software development, things change rapidly. Computers get faster, development platforms, languages, and paradigms shift year to year, even month to month at times. The shelf life of the average technical book can be measured with an egg-timer (anybody want a copy of the VB4 bible?).
At Net Objectives several of our most popular courses center on Design Patterns; even our course on Test-Driven Development includes much pattern-related material. However, if you ask the average developer where Design Patterns come from, (s)he would most likely point to "Design Patterns, Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson, and Vlissides. Most people refer to these 4 gentlemen with the affectionate nickname "The Gang of Four" and thus call their book "The GOF book".
As of this blog writing, however, that book (published November 10, 1994) is over 16 years old. 16 years in our industry is an age, or in fact many ages past, and anything written that long ago might therefore be considered ancient and hokey.
How different is our business now as compared to then? Consider…
To say things have changed is a vast understatement. They are essentially the opposite. I've pointed this out before in other blog postings… but here my point is that it is quite understandable for the GOF Book to be seen as being from that bygone age since that is when it was written, and therefore probably has little or no relevance to our effort today.
In fact, these same people would point to agile development techniques like Test-Driven Development, Scrum, and the like as being "of our times", not the ancient and hokey concept of Design Patterns. Design Patterns, they say, are part of the "Big Design Up Front", or BDUF theory of software development, which is pretty much seen as defunct.
I disagree. In fact, I think the patterns are more relevant today than they ever were in the past, and in fact would point out that the reason for this is that the book was not very relevant in 1994.
All of the particular patters delineated by the Gang of Four have in common a very sharp focus on containing variation by encapsulating it. In most cases this is accomplished by hiding… hiding types, hiding variations in the cardinality (1-1, 1-2, 1-many) of relationships, hiding different implementations and workflows, etc… The notion that anything which is hidden is easier and less-expensive to change informs just about everything the book recommends.
This encapsulation, especially in the technologies of the time, usually involved adding layers of delegation, limiting coupling to abstract types, and the use of virtual methods to create polymorphism. All of these things do, when correctly applied, make change easier to achieve because any given change is likely to affect relatively fewer parts of the system. But, as with most decisions that result in a gain of some kind, they exact a price: performance.
Layering increases the number of jumps in memory and the depth of the stack. Virtual calls and the use of abstract types will increase the number of delegations as well, with yet more performance costs. When the GOF book came out in 1994 most developers reacted by saying, essentially, "this is a great set of ideas but I cannot afford the performance cost to follow them."
Another way of saying this is that the GOF were willing to sacrifice performance in order to gain maintainability. But in the time of their writing, remember, hardware lacked power and was expensive. Why take steps that tax the computer and make the developer's life easier? Maintenance, after all, is a developer cost. We always favored making things "easier" for the computer at the expense of the effort expended by the programmer. They were cheap, and probably didn't have quite enough to do anyway.
Today hardware is cheap, and solving a given problem by adding more processing power, memory, or disk space is typically the least expensive approach. Asking more of the development team is usually the most expensive approach. Making maintenance easier means making change less expensive, and if we have to make the computer work a little harder to achieve this, most of the time this seems like a fair trade.
Finally, in terms of agile process and the notion of incremental development, change is obviously at the center of the equation. In fact many agile proponents suggest that we must "embrace change" if we are to reliably create software that has significant and persistent value.
I actually believe that agile processes do more than require you to embrace change. I believe they create more change. When you open yourself up to regular and frequent feedback from your customers, you are essentially giving them more opportunities to change their minds…or have insights later in the process, often based on what you show them when you ask for validation. This is a good thing if you are looking to create highly-valuable software. But if the system is vulnerable to changes, an agile process can cause more problems than it solves.
So, a good blaster at your side is not a bad idea. But I would not throw away that light sabre if I were you…