“Hokey religions and ancient weapons are no match for a good blaster at your side, kid.” – Han Solo

February 14, 2011 — Posted by Scott Bain

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…

  • In 1994 most businesses considered the hardware to be the expensive part of automating a business. The developer time needed to create the software was probably the cheapest part.
  • There was not a lot of software in the world, and much of it was not mission-critical to the businesses that depended on it. Most business processes were still manual.
  • Computers were many orders of magnitude slower than they are now, and disk space and memory were extremely expensive (and severely limited).

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…

 

Author: 

Share this:

About the author | Scott Bain

Scott Bain is an consultant, trainer, and author who specializes in Test-Driven Development, Design Patterns, and Emergent Design.


Comments

I recall in 1994 a lot of people were telling me that hardware was cheaper than developers, pointing to the mainframe as the example of developers being cheaper than hardware. Hardware is not getting faster anymore - we are giving you more computers: using extra computers (cores) is a much harder way to get more speed than buying a faster computer.

Truth is there is always compromise. There is always the 1% of code that is a bottleneck, and therefore it is worth sacrificing maintainability for better performance. Note that I specified 1% of code, not 1% of YOUR code. There are large types of code that are plenty fast and fully maintainable. There are other types of code where more than half is worth sacrificing maintainability for better performance. You have to figure out where the compromise is worth making, remembering that every time you compromise long term costs go up (I assume it is obvious that before considering this compromise you have already eliminated all waste that doesn't require any compromise).

Many people assume that maintainable code is necessarily slower code. It is not.  If you are writing in C++ you can emulate polymorphism with a combination of includes, typedefs and macros.   Maintainable code is more in the way it is designed and thought of, not necessarily how it is implemented.

Alan Shalloway, CEO Net Objectives

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, SAFe, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile