Design Patterns vs Agile Development
I don't think there can be a professional developer out there that isn't aware of the term Design Patterns. Put simply these are standard solutions to common program architecture problems that have stood the test of time and have been abstracted to the point of being applicable to a number of different domains without needing simplification first. As part of my Continued Professional Development, I've obviously kept an eye on Design Patterns, reading books like the Gang Of Four's seminal work and other great books such as Patterns of Enterprise Application Architecture. Of course, I've also implemented my fair share of them over the years.
The problem comes from the fact that in a modern web development (B2C or web application) running in an Agile way I'm not sure how often they are applicable and I think they often complicate a solution unnecessarily from a very early stage. Indeed one of the corner "Patterns" of Agile Development is YAGNI - You Ain't Gonna Need It. With Agile Development currently being "The One True Way" of developing Web Applications, are the two mutually exclusive?
Some Patterns Are More Useful Than Others
Some of the patterns described by the former books are very useful in a large number of situations, for example the ActiveRecord pattern as implemented by Rail's surprisingly named ActiveRecord gem. This is a pattern to neatly abstract away the details of accessing a database from a higher level programming language such as Ruby on Rails. There are other patterns that are applicable such as TableRow? that do a similar job and are potentially equally as applicable. To be honest, most professional developers have probably written their own ORM (Object-Relational Mapping) layers for years before switching to something like ActiveRecord (or Propel/Doctrine for PHP).
Then there are more traditional patterns such as Singleton that only allows a single instance of an object to exist at any one time (the normal way of doing this is to make the constructor of an object private and have all access go through a public static getInstance method that has an internal static variable that holds the only instantiated object ready to return). The Singleton pattern is often over-used, and indeed over quoted when interviewing potential developers on what design patterns they are aware of, but that aside it is very useful.
Traditional Patterns
There are however other patterns that are suggested to be used within an application (or portion of it) that really overcomplicate what is a currently simple requirement. For example, take the situation of three different network environments (development, staging and production) that each have a different URL for a particular web service. The simple solution is in the callService method (or similar) of the class that interacts with the web service to have a simple switch statement that returns the correct URL for the current environment.
However, often there will be a lot of solutions suggested regarding making abstract factories and other such lofty ideas as it would extract the whole environment in to a single place. Now, don't get me wrong, there are times when this is desirable (and the example I suggest is probably not a good one) however when it comes to teaching new developers the system and them walking through code it's much simpler to have it in the place it's being used (if it's only currently used in one place) or a simple function call, rather than by calling some object that passed in during the constructor, instantiated somewhere else and has a method within it to just do a simple switch statement.
My Favourite Pattern: YAGNI
One of the cornerstones of Agile Development is that you only develop the functionality you need right now. Try not to predict too much how it will be used in the future and create automated tests so that you can be sure the system works. This is absolutely a godsend, far too many times over my career have I been asked to add a certain feature in to code (either a user feature or an architectural feature) only to find that it was never used (yes, internet synchronisation through an awful perl application in a 1990s Delphi Application, I'm looking at you).
Sometimes I do find the "only implement what you need" to be a bit too much when it comes to TDD/BDD. The original books (I haven't read any for a while) all recommend only implementing the first step of a test, then only implementing enough code to make it pass. That's all well and good, but when I know from the higher level feature plan (User Story in our Scrum-based development environment) that data will need to be stored in the database to be shared among many servers, there's no point as a first step just implenting a lot of return "foo" statements so the initial tests pass. You may as well write tests that should work against the final code and implement it immediately in the way you are going to anyway.
Refactor to Patterns
So, am I saying Patterns are evil and shouldn't be used? Definitely not! What I am saying, is like Donald Knuth's famous quote "Premature Optimisation is the Root of All Evil", using Design Patterns that you don't actually require at that moment without having a real current need is a terrible idea. By all means follow Martin Fowler's advice and Refactor to Patterns as the need becomes necessary or implement patterns straight away if you need them in the here and now, but don't put them in anticipating some future need that you don't have in the here and now.
Don't just use them without thinking - you should be writing the best site/product/application you can, not preparing CV fodder for yourself with a long list of Design Patterns you've implemented.
What do you guys think? Let me know in the comments...
5 Comments so far
Hates_ wrote on 28 November 2008 at 17:29
I totally agree that you shouldn't run around with a case of "patternitis", but I don't agree with dumbing down design to achieve "quicker" delivery or make things easier for new team members.
Patterns and Agile go hand in hand. Even just employing something like TDD forces you to think about your design up-front so that you can test parts in isolation. And to overcome those design decisions you can fall back to patterns to help you along.
It's certainly not easy to find that balance though. Even the author of Refactoring to Patterns talks of over-complicating the design at times. It all comes with experience. When you first start your career, you don't know anything and your code's a mess. Then you pick up some patterns and in your over-keeness implement them everywhere and still create a mess. Then eventually you calm down and still create a mess, at least a bit more of a robust and timely one.
Khuram Khan wrote on 16 December 2008 at 15:19
How true this is:
"When you first start your career, you don't know anything and your code's a mess. Then you pick up some patterns and in your over-keeness implement them everywhere and still create a mess. Then eventually you calm down and still create a mess, at least a bit more of a robust and timely one."
JK wrote on 19 December 2008 at 18:29
Completely and wholeheartedly agree, and it's been a continual struggle to voice an opinion like this with the recent influx of "pattern stampers" flooding most niches of enterprise development. I concur that every pattern has its use and place, but until you need (or foresee that need in the *immediate* future), following the principle of YAGNI makes everyones life a whole lot easier.
Code simple. Refactor mercilessly.
Mikhailov Anatoly wrote on 06 January 2009 at 07:12
Telling the truth, Rails is based on design patterns. Just look at these: MVC, STI, Singleton, Observer, State and more.
We are using these patterns as often.
What do you think?
Andy Jeffries wrote on 28 February 2009 at 20:33
@Mikhailov I agree that we're already using a lot in Rails (and I mention in the post that Rails uses them). I agree that they're useful and correct. My post was meant to point out that thinking in terms of patterns from the outside may conflict with YAGNI or even TDD's philosophy of writing the simplest code that satisfies the requirements at the time.
I don't think Rails are evil...
Click here to have your say...