// all posts
- Questions that should be asked during a developer interview, but probably won't be.
- Australian software development salaries lurch higher
- Australian programming language hit parade Jun 2017
- Larry and Sergey.
- Is it reasonable to expect job seeking programmers to answer questions about object oriented programming?
- Unfortunately, we'll reject most developer job applications.
- Great Australian software developers: Nick Gammon & G-Pascal.
- Making a job offer? Lowest isn't always best.
- 50 Characteristics of a great software developer
- Design patterns have (mostly) flopped
- Stuff you must know: your tools
- Stuff you must know: object-oriented fundamentals
- The skills matrix
- Coders who don’t read
- Evidence of passion
Design patterns have (mostly) flopped
Sat 25 Sep 2010
Are you sitting near a computer programmer right now? If yes, then here is a simple practical exercise for you to complete before you read past this first paragraph. Corner your programmer, ask them these two questions and write down the answers. First ask them "What are design patterns?". Second, ask them to "Name every design pattern that you can recall". Make sure you ask these questions one-on-one, otherwise all the programmers in the cubicle will chime in with their answers. If you are a computer programmer then write the answers down yourself before reading on.....
The idea behind design patterns is that they are tried and true solutions to recurring problems in software development. When a programmer encounters one of these recurring problems they implement the appropriate design pattern to solve it. Design patterns have been worked out by some of the smartest computer scientists and tested over time so they are solid and known to be good solutions. With design patterns, the programmer does not need to come up with their own solutions to a whole range of programming challenges; instead they use pre-rolled design patterns. Design patterns save development time and lead to more flexible, reliable and robust software. Design patterns is about reusing the conceptual ideas, solution design and thinking of other people. It's a great idea and make a whole lot of sense.
But here's the awful truth: design patterns have (mostly) flopped.
Design patterns depend on programmers recognising those recurring problems as they encounter them. But if the programmer doesn't recognise the problem then they don't know that it has been solved before and they don't know that there is a design pattern for it. Instead of applying well known solutions to common problems, programmers who don't know design patterns are constantly reinventing the wheel and coming up with their own (probably sub-par) solutions to those problems. They are taking more time to write less reliable code.
Design patterns have flopped because most programmers don't know design patterns well enough to recognise the recurring problems that they solve. If you don't recognise the problem then you can't solve it with a design pattern.
In the recruiting work I have done I've asked thousands of programmers to explain the concept behind design patterns, and to name as many of the common patterns as they can recall. The vast majority of programmers either don't know at all what design patterns are, or their knowledge of design patterns is so thin as to be useless when it come to recognising and applying those patterns. Few programmers display a comprehensive understanding of design patterns. Very few can name more than four or five design patterns. Fewer still can describe the problems that the patterns are meant to solve. This means that most programmers are encountering common problems on a daily basis and instead of using the well known solution (the design pattern), they are coming up with their own solution.
Programmers who don't know design patterns will be puzzled when they encounter a design pattern implemented in source code that they are working on. They will fail to understand that some other programmer is using a tried and true design pattern to solve a problem. Such programmers will fumble and bumble around in the code not recognising either that the problem is a well known one, and where they encounter design patterns in code, not recognising that they solve common problems.
Design patterns are also meant to be a lingua franca - a universal language for programmers to be able to discuss complex solution concepts in terms that everyone understands. But design patterns have flopped here too; you can't communicate in a universal language that you don't know, and most programmers don't know design patterns well enough to be able to be able to use them as a conceptual shorthand. Design patterns are a universal language that few people speak, a sort of Esperanto for programmers.
Design patterns haven't flopped entirely; many smart programmers know and apply them. These folks are the exception rather than the rule. They are the programmers whose hard work has resulted in design patterns like Model View Controller being well known even to programmers who have little knowledge of the broader topic of design patterns.
Design patterns have mostly flopped because the vast majority of programmers have little or no knowledge of this important field of computer science. Many employers look for a knowledge of design patterns in potential employees. If you are a professional programmer then you should have a thorough, expert level understanding of design patterns. You should commit to memory the problems that are solved by design patterns so that you can recognise them. There's no excuse for having patchy, incomplete knowledge of design patterns. Go and do the work required to become an expert on design patterns - put in the hard yards and really become an expert. There needs to be a critical mass of programmers who have become experts in design patterns. If enough programmers become experts on design patterns then maybe one day we can say that design patterns are a success.
Okay now pull out the questions and answers you got at the start of this blog post - was your programmer friend able to fully explain the concept of design patterns? How many design patterns were they able to name? Were they able to explain the problem each design pattern solves? Let me know at:
Copyright © SuperCoders 2010 - 2011 All Rights Reserved.