In this podcast episode, I introduce the concept of design patterns in software development and explain their importance in improving code quality and readability. I give examples of design patterns in everyday life and emphasize how they can speed up the development process by providing tested and proven development paradigms. I also highlight the confusion that can arise when design patterns are not followed correctly.
Or listen at:
Published: Wed, 17 May 2023 15:59:41 GMT
Links
- Laws of UX: Jacob's Law
- Wikipedia: Design Patterns
- Gang of Four book - "Design Patterns: Elements of Reusable Object-Orientated Software"
- Enterprise Integration Patterns
Transcript
Hello and welcome back to the Better ROI from Software Development Podcast.
Last week I said I'd talk about design patterns - during my break from podcasting, I started to explore the Actor pattern - so in this episode I wanted to talk about what design patterns are and why they mattered to software development. And in the next episode I'll talk about the Actor pattern specifically.
A design pattern is a generally reusable solution to a commonly occurring problem. We see and use design patterns in our everyday life generally without even knowing it - in many cases because the solution has become so ubiquitous. We can see design patterns in architecture, products, software, media, pretty much in everything we interact with.
For example, if you fit a blank door, what would you do to allow someone to open it?
You would add a door handle.
It's such a ubiquitous solution that many doors will come with a handle already attached. We are so used to it, we are expecting it. It's such a universal solution to the problem of opening a door. It's a design pattern to solve a commonly occurring problem.
And you've probably seen examples of confusion where the design pattern isn't adhered to - for example, putting a door handle on the side of the door that needs to be pushed. I've certainly been caught out trying to push a pole door because there is a handle, even with a sign next to it saying Push. Our brains will instinctively follow the conventions that we are used to.
Another example, in media when reading a news article, we would expect the headline of the article to be in a bigger, bolder font than the article content. This allows us to easily identify on a busy page where we want to focus our attention. Again, that pattern is so ubiquitous that it's actually followed into digital media.
Interestingly, as with the handle on the wrong side of the door example, the Laws of UX website recommends reuse of ubiquitous patterns.
The Laws of UX website provides a number of laws for good user experience. The site describes itself as "Laws of UX is a collection of best practices that designers can consider when building user interfaces."
One of the laws covered by the site is Jacob's Law, which says:
"Users spend most of their time on other sites. This means that users prefer your site to work the same way as all the other sites they already know."
While of course the context given is in the use of websites, I believe the same is true of product with any user interface, including the handle of our door - a user of the door wants to get through the door. They will have learned expectations from having used many doors previously. They are unlikely to want to experience a new solution as part of everyday use. While a complex series of levers and buttons to open a door in an escape room is appropriate (after all the user is there to solve a puzzle), using that same mechanism to move between one room and another in an office building may seem novel, it is just an inconvenience from the user achieving their goal - which is getting to the other side of that door.
As an aside, I find the Laws of UX a fascinating website and definitely worth reviewing if you're producing any form of product, website or app - I'll include a link in the show notes and will likely to come back to the website in future episodes.
So how do Design Patterns relate specifically to software development?
Well, obviously something like the Laws of UX will help us with the user interface of our software, such as a website or app - for the rest of the episode, are we talking about how it helps us with writing our actual software code.
From Wikipedia:
"Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Freshly written code can often have hidden subtle issues that take time to be detected, issues that sometimes can cause major problems down the road. Reusing design patterns helps to prevent such subtle issues, and it also improves code readability for coders and architects who are familiar with the patterns."
So there are two key benefits to using design patterns within software development: * higher quality * and easier understandability.
Let's take each of these in turn;
Higher Quality. Because a solution to a given problem becomes so ubiquitous, it has gone through many iterations to ensure the quality both in form and function are excellent. While we can obviously get door handles in many shapes and sizes, there is a level of quality that we can reasonably expect. If we pull under the handle, we expect it to remain attached to the door. If we hang washing on the door handle, we do not expect it to fall off. If we slam the door in the middle of an argument, we don't expect the door handle to fly off across the room.
We can be fairly certain that all of the more fragile options have been lost during the design patterns evolution. Thus we don't make door handles out of jelly.
And in software development, the same is true.
The design pattern will have been arrived at through a series of independent attempts to solve the same problem. Commonly the same solution or closely rated will be arrived at over time and use that solution is then refined and improved until such point as any fragility has been iterated outta the solution. So much so that many software design patterns have been codified into books and taught in courses as tried and tested solutions to known problems.
Let's move on to Easier Understandability. Because these common patterns are available in books and courses, they can be a common understanding in their use. They can make conversations easier when referencing a known pattern. The software code can become more comprehensible due to those known patterns.
Similar to how we have known patterns in laying out a newspaper, we have known patterns for laying out our software code, making it easier to read and amend. And given that software code is read considerably more than it is when it is written or amended than anything that helps in that comprehensive hens ability is a good thing.
Now, you may have noticed that I stressed that "can" be a common understanding in their use.
While the ideas of design patterns is well known, there is a variety of design patterns available with differing levels of complexity and adoption.
Most but not all software develop will at least be aware of design patterns in the Gang of Four book - or to give its official title "Design Patterns: Elements of Reusable Object-Orientated Software" - released back in 1994.
Fewer developers will be aware of the patterns in the "Enterprise Integration Patterns" book released in 2003.
Fewer developers will be aware of niche design patterns arising from specific industries, tools or approaches to work.
Few developers will be conversant enough to be able to describe the majority of patterns in a meaningful and correct manner - and I certainly did not count myself amongst that number.
And in most cases, we are lucky if a developer understands a handful and is able to apply them correctly.
This may prompt you to question their usefulness if there is such a low understanding within the software development community?
I would suggest, however, that within a team, adopting design patterns can and should be used as they give you that benefit of great quality and understanding.
It is likely that a relatively junior team would maybe adopt one or two design patterns initially, making sure that everyone is aware of what it is, when to use it and why.
And over time the team can grow and adopt more patterns - I've certainly see this become an explosion of learning opportunity for a growing team - and in a more mature team, you can expect them to have a good number in their collective tool belt.
As with all things, this comes down to time to learn new things.
In this episode, I wanted to introduce the idea of design patterns as a generally reusable solution to a commonly occurring problem.
They help us provide higher quality and improve understanding.
They are used everywhere without us even realizing it.
Software development is full of design patterns - and well outside of the scope of this podcast to be covered in depth - I would however, like to cover one in next week's episode, the Actor Model.
Thank you for taking the time to listen to this episode and look forward to speaking to you again next week.