We’re excited to bring you an interview with Jim Siddle. Jim is a software engineer with a London-based publishing company, and has past experience as an IBM Software Engineer based at the Hursley laboratory in the UK. Jim has worked with software patterns for several years, and is closely involved with the European and Worldwide Software Patterns communities. He has a strong interest in the application of patterns to real-world software projects, and has published several articles and journal papers related to this topic. Some of the articles discuss his work in using patterns in developing aspects of WebSphere Application Server and WebSphere Business Events. We’d like to thank Jim for sharing his experiences with patterns and the impact that they have had on his projects.
And now, on to the interview…
PBE.net: What challenges did you encounter in using patterns?
Jim: The two big issues I’ve encountered are varying quality, and the time it takes to really understand a pattern. There are lots and lots of patterns out there with different provenances and applicability, and finding a suitable, high-quality pattern can take time. Working with published patterns books can help narrow your search, but authors often take different approaches to presenting patterns and have their own expectations about how you will apply the patterns. So even when you’ve found a suitable set of patterns, it takes time to really learn how to use them.
PBE.net: What do you think is the main impediment to the spread of Patterns?
Jim: I believe there are several impediments to the spread of patterns – in fact I based my MSc thesis on this subject! In the thesis, I identified six different problem areas including things like inconsistency in format, unknown trustworthiness, the manual effort required to apply patterns, and the fact that pattern selection rationale can be lost, among others. The underlying issue is that finding, understanding, and using patterns takes time and effort, and that’s a big hurdle for a lot of people.
The thesis proposes using tools to tackle some of the problems. The idea is to capture patterns as electronic documents, then to provide a pattern explorer to allow designers to easily explore patterns and their connections in a rich environment such as a web browser. The proposed tool also allows patterns to be added to a design document iteratively, capturing pattern selections, relationships and rationale.
Another initiative that attempts to encourage the spread of patterns is Grady Booch’s catalog of patterns, available on his Handbook of Software Architecture blog (registration required to view the catalog). This is an example of a pattern repository, which many in the patterns community have proposed as a way to help the spread of patterns.
PBE.net: How did the use of patterns benefit your application?
Jim: One of the oft cited benefits of using patterns is productivity, and personally, I’ve found my own productivity is better when using patterns. For example, the first thing that now comes to mind when I think about notification style problems is the OBSERVER pattern – having this solution ready to hand when needed boosts my productivity when developing OO programs.
However I only gain the productivity benefit if I already have an idea of which pattern to apply or can find the right one quickly and easily. If you’re unfamiliar with patterns for the given problem domain, it can be difficult to find the right one. Building a ‘repertoire’ of patterns helps, and I like to have a few patterns books to hand so I can gradually build up my repertoire, either by dipping in from time to time, or by experimenting by trying out the patterns.
The other main benefit is better quality, whether that’s in code, design, tests, etc. The qualitative benefits depend on the pattern you’re applying, but will usually be spelled out so you know how things will be better when you’re done. For example one of the main benefits of the OBSERVER pattern is that notification of changes to an object can be delivered to interested parties in a loosely coupled way.
PBE.net: How did you evaluate the value of a pattern?
Jim: It’s very hard to measure the value of patterns when they are used for guidance rather than for automation. When automating, the productivity gains are obvious, but if a pattern guides your thinking process, how do you measure the benefits? One option is to look at the benefits claimed by the pattern – so for OBSERVER, is your resulting design loosely coupled?
If your resulting system has the qualities that you were looking for, and were claimed by the pattern, then it could be argued that the pattern improved your chances of making that happen compared to a design created entirely under your own steam and based on your own experience.
PBE.net: How do patterns help you in collaborating with others?
Jim: One of the ways that patterns can help collaboration is by providing, or contributing to, a shared language for problem solving in a particular domain. The original Design Patterns book is perhaps the best example of this, because terms like Observer, Strategy, and Template Method are now widely understood in the Object Oriented Development community. Pattern authors often give patterns catchy, easy to remember names to help the adoption and communication of their patterns. However in my experience it takes a long time for the patterns to really take hold; and of course there is a filtering process – the really fundamental patterns persist, and work their way into the shared vocabulary. Conversely many patterns have a relatively short lifecycle, and may only be known by a small community or used for the duration of a particular project.
PBE.net: How have you shared your patterns?
Jim: I haven’t written any 🙂 My interest in patterns has always been around using existing patterns rather than writing new ones, however I have written a few articles in this area. A couple of articles about using patterns on real-world projects were published on IBM developerWorks, and two others have been published (or are in the pipeline for publication) in the patterns journal “LNCS Transactions on Pattern Languages of Programming”. The latter is a journal created by the Hillside patterns community to publish selected works from PLoP conferences, which help pattern authors and writers to improve their work through writer’s workshops.
PBE.net: How did you recognize the opportunity to use patterns?
Jim: I tend to go by instinct. The more patterns I’ve read and used, the more the ideas embodied by the patterns are “bedded in”. So I’ll be working on a particular piece of software and be faced with a problem, and bing – a pattern to solve the problem will pop into my mind.
That said; the patterns that come most readily to mind are the ones I’ve applied in practice. One of my MSc modules at Oxford University was on design patterns, and we applied patterns during the practical exercises and coursework. This really helped me get my head around the patterns I was working with.
Also generally speaking this is something I like to do more and more…I’m reading Effective Java by Josh Bloch at the moment and as I go I’m writing lots of fragments of code to test the ideas, principles and practices that are discussed in the book. It’s enormously satisfying, translating an abstract idea into working, running code in front of your eyes.
PBE.net: Can you offer any insights into how your patterns fit into your development efforts? For instance, did they support modifications to code after application? How did you manage your “source”? Did they fit into an automated build process?
Jim: Because I’ve mainly used patterns as design guidance, the patterns essentially become incorporated into the system and disappear. That’s great from modification perspective because the code that results from the application of a pattern is just like all the other code. The downside is that you don’t get the productivity benefits of automation.
When using patterns in this way, it’s important to avoid over-doing it – for example on one project we tried to use patterns for everything. This was great in the cases where the patterns were a good match to the problem, and provided good solutions. But there were a several cases where we hadn’t quite understood the pattern, or were really keen to apply a pattern so ended up with a less than optimal solution. The moral of the story is to be judicious in your use of patterns. Use them where it makes sense – whether that’s for design guidance or for automation, but don’t try to force the use of patterns if it doesn’t feel right.
PBE.net: Did you achieve the expected ROI on the project in which you identified and built your patterns? Also – have the patterns been used on others projects?
Jim: ROI is something you can measure on a project using patterns for automation, but when you’re using patterns for guidance rather than generation it’s really difficult to measure. To be honest it’s not something I’ve ever tried to do, because of the effort involved. Measuring the ROI of patterns used for guidance would make a good PhD topic, if it hasn’t been done already.
PBE.net: Are you using patterns in your current project? Have you identified new patterns?
Jim: I just wrapped up work on the MDM Server Workbench, which uses code patterns to generate development artefacts. My most recent piece of work was to integrate the MDM Workbench User Interface Generator with a remote glossary. This particular piece of work didn’t require the creation of any pattern implementations, but I did use the DEPENDENCY INJECTION pattern extensively while developing classes for synchronizing with the remote glossary. This is one of my favourite patterns, written up by Martin Fowler here. Dependency Injection allows classes to be ‘injected’ with the objects they need, and is the ideal complement to Test Driven Development because it allows mock objects to be injected into production classes to enable testing.
PBE.net: How did you decide between pattern specs and pattern implementations?
Jim: For me, the two have significantly different use cases, though they are related.
I’ve always been interested in the idea of capturing great design ideas in a form where they could be reused, so was naturally interested in the GoF and POSA patterns, that kind of thing. This style of pattern is better suited to projects that have longer term goals; products and technologies will change, so capturing expertise or knowledge in an artifact that will outlast the current project is a long term investment.
Pattern implementations on the other hand are great for rapidly automating certain key development processes or best practices and gaining big productivity gains as a result. However they have a fairly tight focus (for example, on a particular tool or technology), so have a shorter lifecycle in the wider scheme of things.
I like to think about the relationship between the two in terms of ‘elevation’. That is, a pattern implementation may have some fundamental quality or significance which suggests it is worth investing the effort required to capture the core idea in a more permanent form, e.g. in a pattern specification. Significant, fundamental patterns may however be manifested in other ways, for example in a repeating design across multiple projects, so remember cast a wide net when looking for them.