Software patterns - useful or over-used?

Recently, on the MSDN forums I had someone comment that design patterns are largely over-used. The answer I gave to a question involved the use of a design pattern for a developer who was clearly inexperienced.

The comment was that the developer should learn proper OO techniques rather than simply saying that they "would use that pattern". I would tend to agree that understanding proper OO principles is a pre-requisite to most jobs in the software industry these days. That got me thinking, does using design patterns give rise to a set of developers who understand that they need to use a pattern rather than understanding the intent behind it?

I would say no. If said developer is using a pattern because someone said so rather than because they know that it fits their requirements, perhaps they need some career counselling.

That brings me on to patterns. A pattern is a well define solution to a particular programming problem, and that solution may in fact consist of a number of patterns to make up the full solution.

It is very true that you could use TDD, and evolve such a design, or pattern, and that might be the acceptible way to approach the situation, it certainly would be if you're using pure TDD. It just seems that having an idea of possible approaches, a solution space, if you like is a great idea. It gives a set of scenarios to consider, or a set of implementations that you must consider, which is a good thing.

Then, if you're not doing pure TDD, you might want to adopt a pattern, which is a well understood way forward to implementation. If you're an experienced developer, you'll probably have implemented these patterns before without calling them patterns, so in that case, it's a descriptive label to put on an "experience catalogue". It means other developers who have also developed using those same algorithms can have a common understanding of what you're talking about.

Primarily, I see this as the major force behind patterns. The ability to communicate a shared understanding of a design, in a short and succinct manner.

People have often asked me what they need to do to make the code a such and such pattern, or instead, which falvour of the pattern is this, I want to use this pattern, how can I covert it from a similar pattern to that pattern? These sorts of questions seem strange to me. The pattern is there to help you think about the problem in isolation, decoupling, and good things like that. Whether it has one name or another name is really irrelevant, it's all about whether the software does what it is supposed to, and does it in an efficient manner.

I have also come across situations where people try to follow the pattern to the letter. To me, a pattern is a template, but there is no reason why that template can not be extended to fit the problem space, so long as that design is well considered.

So in commenting that software patterns are over-used, that really is kind of like saying that experience is over-used and overrated. Patterns, whilst they're not a new idea should be used more, if nothing else so that it is an enabler for communication.

Risk, Who needs it?

Hello,

You're a software developer, you love to live by the seat of your pants, right? You can't function without loads of pressure, and the vast amounts of coffee that goes with it right? You'll probably want to stop reading this then!

So many projects and features for a piece of software get into a project plan without consideration to the risks involved. The client wants it, therefore it must go in. Is that a realistic proposition? Well, it might be, depending upon what the feature it is, and whether the inclusion of the feature overrides the risk involved in its implementation.

Something to consider, if late inclusion of a feature into an existing project is going to take that software back to a beta version, and the risk is unknown, would you do it? I wouldn't. You need to know the risks, and you need to be able to predict the worst case scenario, and describe what aspects of the software will be affected.

Given these assessments of impact and risk, you can attach a dollar cost to the cost of implementing the additional cost, versus the cost of not doing so, and always look at the worst case.

Imagine the number of features that started life as a throw away comment, and ended up being a major feature in a piece of software simply would not be there if decision makers knew the true cost of doing someting versus the cost of not doing something.

Need help with architectures, or coding?

Hi,

If you need help with requirements, architectures, development code and the like, leave me a comment in here, and I'll help you out.

Cheers,

Martin.