Detailed Notes
We have had many discussions about software patterns and anti-patterns over the years. However, we have not talked about creating software patterns. That is an important topic because they have to come from somewhere, and the list will grow. This session from our mentor classes shows how to build on and document your experience.
Creating Software Patterns Has Many Steps There is a difference between learning any topic when compared to teaching it. Likewise, solving a problem once is only a piece of repeating or automating that process. Patterns and Anti-patterns follow those same progressions. We do things for a while, observe them, clean them, and communicate our findings. All of that takes time and is an excellent way to become a better developer.
The Mentor-Mastermind Group This series comes from our mentoring/mastermind classes. These classes are virtual meetings that focus on how to improve our technical skills and build our businesses. The goals of each member vary. However, this diversity makes for great discussions and educational value every time we meet. We hope you enjoy viewing this series as much as we enjoy creating it. As always, this may not be all new to you, but we hope it helps you be a better developer. Drop us a line to find out when the next one is so you can join our group.
Other series you might consider:
Creating a Product Catalog Software Design Patterns Anti-patterns and How Not To Build Software
Transcript Text
[Music] so this presentation comes out of the past few years we've numerous times talked about patterns we've talked about any patterns we've talked about software patterns and project planning patterns and how they apply to agile and and just so many places and all of these have been uh basically sourced from other people yeah it's it's either in books or out on the web or something like that and what i wanted to do is is spend a little time in this presentation talking about how do you maybe build out your own patterns and annie patterns and and how do you how do you make something and say hey yeah this is a pattern as opposed to maybe just a habit or something like that so i'm gonna in doing so i'm gonna talk just sort of revisit what's a pattern what are annie patterns how do you lean on your experience to build these out touch on the rule of three or a version of the rule of three and then how do you refine sort of your rough draft of what a pattern or any pattern is and then you know the the point of it sort of is how do you share your knowledge so software patterns in particular now there's numerous patterns that are out there uh in the it world but originally the idea was came from software patterns they're highlighted and described in basically the early 90s there's a book called design pattern software design patterns it's often referred to as the gang of four book because it's uh four authors that at the time it was and they've all got you know nice long names it's not like you know smith jones brown bob or something like that it's longer names and rather than have that big long list of names they just a lot of people just call it gang of four or even gof um it's just one of those things because hey we're you know we're i.t people we shorten stuff up a pattern a software pattern is just it really it comes out it's a common solution to a problem it's where you see this problem over and over again it's a pattern that says here is a way to solve this problem and it's usually comes out of multiple attempts to solve that problem uh usually you know successful attempts and what are the commonalities because every time we solve a problem there may be some slightly different facets to it sums are some are very very similar if you think for example like a login for an application the idea of solving the problem of how do i get a user into a system how do i give them some ability to log in how to have them uh what do i need to do to allow them to administer that you know like change password forgot password um maybe enforcing some sort of password strength or security those things may vary a little bit uh particularly like it maybe it's uh maybe you're implementing in a different language maybe the interface is a little different maybe the back end is a little different but overall uh one patterns are not gonna they're not tied to a technology they're sort of like a level above that uh but then two it's it's one of those if you can get 80 or 90 there with a a pattern with a process or a series of steps then that just that just jumpstarts you forward to get you to the stuff that are the more unique problems you need to solve so that's the key is software patterns help us quickly build new solutions based on past work either of ourselves or others and this is going to be higher quality because we're reusing the the lessons learned in the past all of the concepts and the the stumbles and the gotchas have been sort of baked into the pattern so that we're much more likely to have something that's going to be successful at least the the pattern part of it i mean we can always screw it up but it is something that we um we're gonna be less likely to because the the thing you know it's one of those things like knowledge gaps and not knowing what you don't know becomes less of an issue because other people have gone through this or we're reviewing what we saw in the past and using that to inform us for solving this particular problem any patterns followed after the idea of patterns is as people do people started looking at it saying well you know there's a lot of things that a lot of problems that we solve and we see how we should address this problem but then they sort of went to the flip side and said well what about all of the situations where we say here's a problem and these are the ways you definitely do not want to do it or here are the things you definitely do not want to get yourself into the probably the most classic anti-pattern ever would be like painting yourself into a corner and so those things exist all over the place as do the patterns and it made sense to say well let's start talking about any patterns much as we do patterns and sort of use them as cautionary tales maybe or warning signs that you want to avoid when you're building out a solution or designing a solution and really what it is is any pattern is a a common typical stumbling block that either reduces quality increases your chance of failure or maybe guarantees failure uh in some cases but it's not necessarily just in failed projects it may be things that occur in a successful project that in that you really just don't want to go through either it adds them the cost of maintainability reduces performance reduces scalability uh it's really just any patterns really come down to it they're not focusing so much on failures as much as uh you almost want to call like worst practices if you hear about things that are best practices if you do these things you're more likely to have a you know a better more valuable solution adding patterns are the opposite these are the things that if you do these it's it's going to really challenge your ability to produce the best solution so it's really looking at just let's let's find a way to sort of categorize document pass mistakes and provide a way that people can avoid making those mistakes and in doing so hopefully improve the velocity and quality of development efforts and the key to office is this our next little step here is we're going to lean on our experience because there are a few teachers that are better than experience it allows us to do things like avoid potholes you know those those bumps in the road those challenges we run into that take take up a lot of our time or cause us a lot of frustration where in retrospect we look back and say you know i could have avoided that like a a classic example would be if you don't back a machine up and your machine dies and you spend who knows how much time trying to recover what you lost you know that's something going forward you can say hey i need good backups i need regular backups of my sheen so i don't lose stuff but we also can get our experience we can find some algorithms we can find as we solve a problem over and over again we can take those specific solutions and turn them into general solutions it's something that we can do to speed ourselves forward because then we can basically reuse that solution now it's it's if we've made a general case for it um along the same ways is while we can find common solutions or general solutions we also are going to find among those general or common mistakes a good example in coding is not capturing um exceptions it's not handling exceptions properly and especially in certain languages and frameworks and formats and areas that we you know just environments we can get into where we can use some sort of error handling and exception handling it's not uncommon for us to just you know sort of go through and code the happy path and not really think about those other things well we can avoid doing so we can look back and say yeah i had this thing and it gave me just ridiculous headaches and if i had just properly tracked logged you know whatever output mistakes or exceptions errors or exceptions then it would have been a lot faster to handle experience also can teach us shortcuts we can look at stuff and say wow i went through all of this extra work but really i could have skipped three of those steps because they ended up being not very helpful or those things that i took steps solving that problem that were really kind of like research is i had to look into some options you know like maybe i was faced with three different options i ended up having to explore all three but now i know which one of those three options makes sense so i can take a shortcut i don't have to explore all three of those in the future in a similar sense experience is going to teach us common paths they're going to be problems that we solve sometimes they're going to be very different from past problems and you feel like you've been here before you maybe get sort of like that sense of deja vu and you're going to realize that oh this is something i've had to do before it may have been a completely different problem i was solving but the this step or these series of steps um i've seen them before and so i have a better idea now of how to go forward because they're it feels familiar it would be like traveling from one city to another and there's maybe 10 different ways but sometimes you're on uh you know sections of road or sections of the journey that you've been on before so you're like oh okay i know this so i know that you know there's a gas station up ahead or a restaurant or whatever uh likewise is experience that helps us along with potholes is avoiding the the treacherous past we'll call them you know the cases where yeah we can do that but it's it's risky or time consuming or costly or whatever it happens to be so we can uh we can also just keep our heads up sometimes you know if you've i'd be like climbing a mountain if you've scaled the side of a cliff and you know done free climbing or one of those kinds of things and i haven't but i'm going to assume that there are things that you learn going from one to another about just how the handholds are how far you can step how far you can swing what can hold your weight and what can't all those kinds of things that experience teach us it's basically that hey if if i do this if i take this path then here's some things i'm going to need to do to be you know to be safe or to increase my chance of success so we get a lot out of experience and now although this is through this one out there with the rule of three this is not the three laws of robotics which is a very different rule of three uh rule of three in general actually there's many ways that it shows up um we're going to talk about a specific one that we're going to call sort of a rule of three there are other ones related to sales and marketing and things like that but in this case we're going to talk about doing something three times because there's something sort of magical about that uh and maybe not magical it just it's um if you think of doing something like in a sweeping motion you know like if you i don't know like take a broom and sweep it across the floor the first time you sweep it across you'll get you know whatever it is 60 70 of the dust and if you do it again you'll probably take some more dust if you do it again you'll take some more but now you're you're down to probably very minimal amount of dust same kind of thing with doing almost any task and in solving problems typically what we do is the first time we solve a problem is we're really solving more or less for a specific case we may see opportunities where this can be used generally but we're we're still solving for that specific case the second time we see it now we've got two things to compare the pro you know the first attempt and the second attempt and that's going to help us to generalize the solution it's going to say hey now we've seen it a second time let's take this solution and make it more general case and then by the time we get to the third time now we should be able to see far more for lack of better term patterns in the problem and how we're going to solve it we've generalized it and now we've even sort of tested that generalization because we we did it for the you know we did the specific for the first time we created a general solution the second time and now by the time we see it the third time we're going to try to use that general solution and try to apply it to the third and there may be some you know some some refinements and and stuff that come in when we do it that third time but now by the time we've gone through three times we've essentially tested the solution three different ways um we've seen yeah we we may not have seen outliers but we've probably seen a good portion of what this problem's typically going to look like so by the time we get through three we we should be pretty confident what we've got is a good general case solution that doesn't mean that there won't be you know there aren't bugs that there aren't issues but do we get that third time typically it's going to get us you know really close to where we need to be you're not going to see you're going to see maybe a lot of we'll see a lot of changes the second time through because now you're you know you're really highlighting what's the same and what's the difference you're going to see a few changes probably the third time you do it but then as you go to the fourth and the fifth and the sixth you know it'll be maybe changes here and there but it's definitely going to be less should be unless you're doing it wrong less each iteration and eventually you're going to get into cases where you're you're also going to be able to determine that oh well this you know this should change but it's a it's really it's an outlier this is not part of the really that true general cases or general solution so thinking about that with the idea of patterns in any patterns is really it comes down to it's it's simpler than probably it sounds is it we're going to see problems and we're going to see the same problem over and over again so when we want to sit down and say what would be a pattern or when we want to start building out our patterns and anti-patterns and a reason for this is both personal so that we can become better developers and also for our organization because there will be organizational patterns for example if you think about financial organizations or health care organizations or organizations that deal with government there are problems that they see that other industries other organizations may not and then even a specific company a specific business will see things that maybe other uh their competitors maybe don't and so there's going to be sort of like levels of specificity of patterns and any patterns and so as we're doing our work and building you know with the idea of becoming a better developer and trying to think about what are some uh some of our own patterns and anti-patterns first thing we want to do is look for common uh functionality or steps when we're going from problem to problem uh application application page to page whatever it is where are there things that we're having to think through that are repeated you know where is it a repetition of either functionality or requirements problem definitions and even across solutions because there may be things that it doesn't really pop up in the problem but if you look at the solution you realize that oh we had all these different problems that we saw but what by the time we got to the end here are the things that we had sort of drop out on the back end you know that were part of the solution that are very similar and maybe this is now a pattern we need to front load so we don't try to solve it while we're you know doing our application a good example would be uh data audit record type information so if you're doing some sort of application that needs some an audit trail such as what was changed who changed it when was it changed then you'll find especially if you do this across a bunch of different applications you'll see that it really doesn't matter too much what the application is there's the same couple of steps that you're going to do over and over again and it there is a pattern for that and so it's something that you may say okay this is a pattern that we can we can use as we go through um all the other you know future applications and somebody answers a question that as a positive that says do we need some sort of audit history or audit trail and there's also gonna be any patterns there's gonna be things you're gonna look at through that and you're gonna say oh my gosh this is this was not the way to do it this did not scale or whatever it was and so you're going to see those anti-patterns as well you're going to see particularly when you look in the world of agile if you look at retrospectives that could be a great opportunity for any patterns because you may see things that are in the actually both patterns and anti-patterns because you may see things that recur in the what we did right or what we want to do categories would be more your patterns and then the things that let's not do that again or we need to do less of that would be you know maybe point to some anti-patterns you
Transcript Segments
[Music]
so this presentation
comes out of
the past few years we've numerous times
talked about patterns we've talked about
any patterns we've talked about software
patterns and project planning patterns
and
how they apply to
agile and and just so many places
and all of these have been
uh basically sourced from other people
yeah it's it's either in books or out on
the web or something like that
and what i wanted to do is is spend a
little time
in this presentation talking about how
do you maybe build out your own patterns
and annie patterns
and and how do you
how do you make something and say hey
yeah this is a pattern as opposed to
maybe just a habit or something like
that
so
i'm gonna in doing so i'm gonna talk
just sort of revisit what's a pattern
what are annie patterns
how do you lean on your experience to
build these out
touch on the rule of three
or a version of the rule of three
and then
how do you refine sort of your rough
draft of what a pattern or any pattern
is and then
you know the the point of it sort of is
how do you share your knowledge
so software patterns in particular now
there's numerous
patterns that are out there
uh in the it world but originally the
idea was
came from software patterns they're
highlighted and described in
basically the early 90s there's a book
called design pattern software design
patterns
it's often referred to as the gang of
four book because it's
uh
four authors that at the time it was and
they've all got you know nice long names
it's not like you know smith jones brown
bob or something like that it's longer
names
and
rather than have that big long list of
names they just a lot of people just
call it gang of four or even gof
um
it's just one of those things because
hey we're you know we're i.t people we
shorten stuff up
a pattern a software pattern is just it
really it comes out it's a common
solution to a problem it's where you see
this problem over and over again
it's a pattern that says here is a way
to solve this problem and it's usually
comes out of multiple attempts to solve
that problem
uh usually you know successful attempts
and what are the commonalities because
every time we solve a problem there may
be
some
slightly different facets to it
sums are some are
very very similar
if you think for example like a login
for an application
the idea of solving the problem of
how do i get a user into a system how do
i give them some ability to log in how
to have them uh what do i need to do to
allow them to
administer that you know like change
password forgot password
um
maybe enforcing some sort of password
strength or security
those things may vary a little bit
uh particularly like it maybe it's uh
maybe you're implementing in a different
language maybe the interface is a little
different maybe the back end is a little
different but overall
uh one patterns are not gonna they're
not
tied to a technology
they're sort of like a level above that
uh but then two it's it's one of those
if you can get 80 or 90 there with a
a pattern with a process or a series of
steps then that just that just
jumpstarts you forward to get you to the
stuff that are
the more unique problems you need to
solve
so that's the key is software patterns
help us quickly build new solutions
based on past work either of ourselves
or others and this is going to be higher
quality because we're reusing
the
the lessons learned in the past all of
the concepts
and the the stumbles and the gotchas
have been sort of baked into the pattern
so that we're much more likely to have
something that's going to be successful
at least the the pattern part of it i
mean we can always screw it up but
it is something that we
um we're gonna be less likely to because
the the thing you know it's one of those
things like knowledge gaps and not
knowing what you don't know becomes less
of an issue because other people have
gone through this or we're reviewing
what we saw in the past and using that
to inform us for solving this particular
problem
any patterns
followed after the idea of patterns is
as
people do
people started looking at it saying well
you know there's a lot of things that
a lot of problems that we solve and we
see how
we should address this problem
but then they sort of went to the flip
side and said well what about all of the
situations where we say here's a problem
and these are the ways you definitely do
not want to
do it or here are the things you
definitely do not want to get yourself
into
the probably the most classic
anti-pattern ever would be like painting
yourself into a corner
and so
those things exist all over the place as
do the patterns
and it made sense to say well let's
start
talking about any patterns much as we do
patterns
and sort of use them as cautionary tales
maybe or warning signs that you want to
avoid when you're building out a
solution or designing a solution
and really what it is is any pattern is
a a common typical stumbling block that
either
reduces quality
increases your chance of failure or
maybe guarantees failure uh in some
cases but it's not necessarily just in
failed projects it may be things that
occur in a successful project that in
that you really just don't want to go
through either it adds them the cost of
maintainability reduces performance
reduces scalability
uh it's really just
any patterns really come down to it
they're not focusing so much on failures
as much as
uh
you almost want to call like worst
practices if you hear about things that
are best practices if you do these
things you're more likely to have a you
know a better more valuable solution
adding patterns are the opposite these
are the things that if you do these it's
it's going to really challenge your
ability to
produce the best solution
so it's really looking at just let's
let's find a way to
sort of categorize document pass
mistakes
and
provide a way that people can avoid
making those mistakes
and in doing so hopefully improve the
velocity and quality of
development efforts
and the key to office is
this our next little step here is we're
going to lean on our experience
because
there are a few teachers that are better
than experience
it allows us to do things like
avoid potholes you know those those
bumps in the road
those challenges we run into that take
take up a lot of our time
or cause us a lot of frustration where
in retrospect we look back and say you
know i could have avoided that
like a a classic example would be
if you don't back a machine up and your
machine dies and you spend
who knows how much time trying to
recover what you lost
you know that's something going forward
you can say hey i need good backups i
need regular backups of my sheen so i
don't lose stuff
but we also can get our experience we
can find some algorithms we can find
as we solve a problem over and over
again we can take those
specific solutions and turn them into
general solutions
it's something that we can do to
speed ourselves forward because then we
can basically reuse that solution now
it's it's
if we've made a general case
for it
um along the same ways is while we can
find common solutions or general
solutions we also are going to find
among those general or common mistakes
a good example in coding is not
capturing um exceptions it's not
handling exceptions properly
and especially in certain languages and
frameworks and formats and
areas that we you know just environments
we can get into where we can use some
sort of
error handling and exception handling
it's not uncommon for us to just you
know sort of go through and code the
happy path and not really think about
those other things
well we can avoid doing so we can look
back and say yeah
i had this thing and it gave me just
ridiculous headaches and if i had just
properly
tracked logged you know whatever output
mistakes or exceptions errors or
exceptions then it would have been a lot
faster to handle
experience also can teach us shortcuts
we can look at stuff and say wow i went
through all of this extra work
but really i could have skipped three of
those steps because they ended up being
not very helpful
or
those things that i took steps
solving that problem that were really
kind of like research is i had to look
into some options you know like maybe i
was faced with three different options i
ended up having to explore all three
but now i know which one of those three
options makes sense so i can take a
shortcut i don't have to explore all
three of those in the future
in a similar sense
experience is going to teach us common
paths they're going to be
problems that we solve sometimes they're
going to be very different from past
problems and you feel like you've been
here before you maybe get sort of like
that sense of deja vu
and you're going to realize that oh this
is
something i've had to do before it may
have been a completely different problem
i was solving but the
this step or these series of steps
um i've seen them before and so i have a
better idea now of how to go forward
because they're it feels familiar
it would be like traveling from one city
to another
and there's maybe 10 different ways but
sometimes you're on
uh you know sections of road or sections
of the journey that you've been on
before so you're like oh okay
i know this so i know that you know
there's a gas station up ahead or a
restaurant or whatever
uh likewise is
experience that helps us along with
potholes is avoiding the
the treacherous past we'll call them you
know the cases where
yeah we can do that but it's it's
risky or time consuming or costly or
whatever it happens to be
so we can
uh we can also just keep our heads up
sometimes
you know if you've i'd be like climbing
a mountain
if you've scaled the side of a cliff
and you know done free climbing or one
of those kinds of things and i haven't
but i'm going to assume
that
there are
things that you learn going from one to
another about just how the handholds are
how far you can step how far you can
swing what can hold your weight and what
can't
all those kinds of things that
experience teach us it's basically that
hey if
if i do
this if i take this
path then here's some things i'm going
to need to do to be
you know to be safe or to increase my
chance of success
so we get a lot out of experience
and now
although this is through this one out
there with the rule of three
this is not the three laws of robotics
which is a very different rule of three
uh rule of three in general actually
there's
many ways that it shows up
um we're going to talk about a specific
one that we're going to call sort of a
rule of three
there are other ones related to sales
and marketing and things like that
but in this case
we're going to talk about
doing something three times
because
there's something sort of magical about
that uh and maybe not magical it just
it's
um
if you think of doing something like in
a sweeping motion you know like
if you
i don't know like take a broom and sweep
it across the floor the first time you
sweep it across you'll get you know
whatever it is 60 70 of the dust and if
you do it again you'll probably take
some more dust if you do it again you'll
take some more but now you're you're
down to probably very minimal amount of
dust
same kind of thing with doing almost any
task
and in solving problems typically what
we do
is the first time we
solve a problem is we're really solving
more or less for a specific case we may
see
opportunities where this can be used
generally
but we're
we're still solving for
that specific case
the second time we see it now we've got
two
things to compare the pro you know the
first attempt and the second attempt and
that's going to help us to generalize
the solution it's going to say hey now
we've seen it a second time
let's take this solution and make it
more general case
and then by the time we get to the third
time now
we should be able to see far more
for lack of better term patterns in the
problem
and how we're going to solve it
we've generalized it and now we've even
sort of tested that generalization
because we we did it for the you know we
did the specific for the first time we
created a general solution the second
time and now by the time we see it the
third time we're going to try to use
that general solution and try to apply
it to the third
and there may be some you know some some
refinements and and stuff that come in
when we do it that third time but now
by the time we've gone through three
times
we've essentially tested the solution
three different ways
um we've seen yeah we
we may not have seen outliers but we've
probably seen
a good portion of what this problem's
typically going to look like
so by the time we get through three we
we should be pretty
confident what we've got is a good
general case solution that doesn't mean
that there won't be you know there
aren't bugs that there aren't issues
but
do we get that third time
typically it's going to get us you know
really close to where we need to be
you're not going to see you're going to
see maybe a lot of we'll see a lot of
changes
the second time through
because now you're you know you're
really highlighting what's the same and
what's the difference you're going to
see a few changes probably the third
time you do it but then as you go to the
fourth and the fifth and the sixth you
know it'll be maybe changes here and
there but
it's definitely going to be less should
be unless you're doing it wrong
less each
iteration
and
eventually you're going to get into
cases where you're you're also going to
be able to determine that oh well this
you know this should change but it's a
it's really it's an outlier this is not
part of the
really that true general cases or
general solution
so thinking about that
with the idea of patterns in any
patterns
is really it comes down to
it's it's simpler than probably it
sounds
is it we're going to see problems and
we're going to see the same problem over
and over again
so when we want to sit down and say what
would be
a pattern or when we want to start
building out our
patterns and anti-patterns
and a reason for this is
both personal so that we can become
better developers and also for our
organization because there will be
organizational
patterns
for example if you think about financial
organizations or health care
organizations or
organizations that deal with government
there are problems that they see that
other industries other organizations may
not
and then even a specific company
a specific
business
will see things that maybe other uh
their competitors maybe don't
and so there's going to be sort of like
levels of specificity of patterns and
any patterns
and so as we're
doing our work and
building you know with the idea of
becoming a better developer and trying
to
think about what are some
uh some of our own patterns and
anti-patterns
first thing we want to do is look for
common
uh functionality or steps
when we're going from problem to problem
uh application application page to page
whatever it is
where are there
things that we're having to think
through that are repeated you know where
is it a repetition of
either functionality or
requirements
problem definitions
and even across solutions
because there may be things that it
doesn't really pop up in the problem but
if you look at the solution you realize
that oh
we had all these different problems that
we saw but what by the time we got to
the end
here are the things that we
had sort of drop out on the back end you
know that were part of the solution that
are very similar
and maybe this is now a pattern we need
to
front load so we don't try to solve it
while we're
you know doing our application a good
example would be
uh data audit
record type information
so if you're
doing some sort of application that
needs some
an audit trail such as what was changed
who changed it when was it changed then
you'll find especially if you do this
across a bunch of different applications
you'll see that it really doesn't
matter too much what the application is
there's the same couple of steps that
you're going to do over and over again
and it there is a pattern for that
and so it's something that you may say
okay
this is a pattern that we can we can use
as we go through
um all the other you know future
applications and somebody answers a
question that
as a positive that says do we need some
sort of audit history or audit trail
and there's also gonna be any patterns
there's gonna be things you're gonna
look at through that and you're gonna
say oh my gosh this is
this was not the way to do it this did
not scale or
whatever it was
and so you're going to see those
anti-patterns as well
you're going to see
particularly when you look in the world
of agile
if you look at retrospectives that could
be a great opportunity for any patterns
because you may see things that are in
the actually both patterns and
anti-patterns because you may see things
that recur in the
what we did right or what we
want to do
categories
would be more your patterns and then the
things that let's not do that again or
we need to do less of that would be you
know maybe point to some anti-patterns
you