Antistar

I usually don't feel the need to comment on technical or professional books, but I can't let "AntiPatterns" go without a comment. I just wrapped this treatise/catalog up last night, and am still reeling from the impact. It may be the most important book on software engineering that I've read in the past three years. The book is much older than that, but while part of me wishes I'd read it before now, I also recognize that I would not have been in a position to appreciate it before this point in my career.

Let me back up a bit. One of my all-time favorite computer science books is "Design Patterns," written by the notorious Gang of Four. I have a long and friendly relationship with this book. I first got a copy after winning the CS101 Programming Contest in Dr. Ken Goldman's class back in 1999. I knew that it was the required text for CS342, which I wouldn't be taking for another year, but I still enjoyed flipping through it and learning some new techniques. I hit the book hard once I entered Dr. Gill's class, and became an even larger fan.

Compared with almost all other fields in the arts, sciences, and engineering, CS is a very young discipline. Depending on how you count these things, we basically just have two or three generations of study and practice, and the field is evolving much more rapidly than we can establish best practices. As software grows increasingly complex, engineers keep encountering the same types of problem over and over again. These might include things like saving state in a program in a reversible way; creating a collection of objects that might be upgraded in the future; or re-using a legacy system for new development. Engineers often end up re-inventing the wheel, making mistakes as they do so. The idea behind Design Patterns is to present a collection of solutions that have been used repeatedly and successfully to solve a problem in different environments. Rather than roll the dice and try to come up with your own strategy for solving the problem, you can have more confidence in applying a well thought-out and explained approach.

Design Patterns isn't just, or even primarily, about solving problems, though. I think its greatest contribution is in establishing a shared language that engineers can use to communicate. Whether within the same organization or across entities, programmers need to expend a lot of time and energy explaining just what, exactly, they are doing; all too often the temptation is to say, "Oh, let's just look at the code," which is the truest description of what is happening, but is incredibly time-consuming and does not address the PURPOSE behind choices made in the code. Design Patterns is really about laying out a pattern language: it is a way of thinking, a way of organizing and presenting criteria, and a collection of high-level vocabulary that short-circuits tedious and confusing architectural discussions. Design Patterns has entered our vernacular to the extent where you can say, "Let's create an iterator over the widgets," and any programmer will immediately understand what you mean; or, if you suggest making a particular object a Singleton, they will not only know what course of action you are suggesting, but also can quickly grasp on their own why that may be the best solution.

One of the early, thrilling advances in my career was a summer internship I held at Raviant Networks. I remain convinced that at least part of the reason why I (a lowly sophomore) was selected for this opportunity was because I was able to speak intelligently about design patterns, giving a brief description of why the Singleton and the Memento were so elegant and useful. I still revisit this book every year or so, and while not every pattern in the entire catalog feels extremely useful, enough do to improve my craft.

With that background, you may be able to understand why I had an immediately negative reaction the first time I heard of "AntiPatterns." The purpose of the book seemed clear: it was opposed to design patterns! Those things that were making me a better engineer! Boo! Even after a co-worker read and recommended the book to me, I continued to resist - there are always enough things out there that I want to read without needing to expose my favorite texts to ridicule.

I eventually picked it up, and can report back that this book is just as important as DP. It isn't opposed to DP... well, at least not directly. The authors do have some legitimate complaints about the DP model. First of all, DP focuses on the solution catalog rather than the problems. After presenting a solution, they invent situations in which to apply it, which can feel contrived. They also complain (less compellingly, in my view) that the pattern language template is wordy and hard to understand. All that said, though, AP is fundamentally on the same page as DP. Both approaches seek to capture the collective wisdom of an industry's best minds; both seek to present that information in a useful and structured way; and both provide catalogs of their conclusions.

The "Anit-" part of "Anti-Patterns" does not, as you might think, mean "Non-Pattern" or "Against-Patterns." Rather, it means "Bad-Pattern." Anti-Patterns are recurring, chronically negative situations that arise in the software development process. Most of these will be familiar to anyone who has spent any length of time in development: Spaghetti Code. Fire Drills. Analysis Paralysis. They put the focus on the problem; then, once the problem is understood, they look at the reasons why the problem occurs and the forces that need to be resolved for the problem; finally, they present a refactored solution that can be applied to prevent the problem from arising in the first place, or to mitigate its effects once it occurs.

There are several ways in which AP feels superior to DP. Probably the most dramatic one is that, while DP focuses on software design issues, AP addresses all levels of development: from coding practices through design through systems architecture through enterprise planning through management through global strategy. I would not have been in any condition to appreciate this book a mere five years ago; I might have enjoyed the early AntiPatterns about coding, but would have thought that the bulk of the book was boring filler that didn't apply to me and was really more about politics than engineering. After spending years in a variety of sizes of companies, I understand that those political issues are incredibly important, and may have an even greater impact on the success or failure of a project than the engineers' individual technical skills. Too often I feel like I'm a craftsman who creates excellent work but is helpless to change the environment in which he produces it; this book gives me confidence that these problems can be identified and changed before they lead to disaster.

The best and most sickening part of the book is how familiar much of it feels. I've only been a professional developer for a bit over five years, but in that time I've already encountered a depressingly large number of these AntiPatterns. Management becoming obsessed with micro-levels of planning such that engineers spend much of their time producing Gantt charts and estimates instead of actually writing software? Been there. Buying software from a vendor over the technical concerns of the staff, then churning for months as it failed to deliver what sales promised? Saw that happen. Had a successful piece of demonstration software that was rushed into production without re-considering its architecture? Yup, and spent months in the bug-fixing mines as a result. A gigantic class that provides every piece of functionality in the application? Ugh, yeah.

I could go on and on, but you get the idea. Here too, I think it's probably a good thing that I didn't encounter AP as part of my undergraduate study. DP is a great and timeless book, applicable equally to the hobbyist programmer, the academic, and the professional developer. AP is a very different beast, focused on the real world in which commercial software gets written, and I just would not have had the context in which to understand or appreciate it before I had experienced it myself. It's kind of like the tough love school of growing up: you have to skin your knees a few times before you learn how to be careful. Now that I can recognize these problems, I am finally in a position to apply the tools this book has given me.

As with DP, the book isn't perfect. For me in particular, it seems overly focused on enterprise issues that presume huge companies that contain geographically disparate staff, a variety of technologies, and multi-year project plans. Those factors probably make the book even more valuable to people in those situations, but, while interesting, they don't provide me with a whole lot. The authors also could have helped things by providing more examples; they occasionally have a tendency to slip into lingo, and it can be hard to understand what they mean. When they do provide examples, they tend to be illuminating and well thought-out.

I checked this book out of the library, so I can't give it a permanent space on my bookshelf like I have for DP. Still, it's important enough that I want to give it that honor some day. I won't soon be forgetting the lessons it taught, though. To the extent that I become a more effective engineer and a leader of successful projects, I think I'll need to share some credit with this book.