One of the bloggers I make efforts to follow Steve Smith on the The 4 Stages of Learning Design Patterns. I’ve had the opportunity to meet Steve at previous DevConnections and he’s an all around good guy and from us speaking and all I’ve read through his blog posts I find our software development and architecture mentality to be very similar.
To sumarize Steve’s article he defines that are 4 stages to understanding software patterns.
- Stage 0: I don’t know this pattern
- Stage 1: I sort of know this pattern and can talk about it, maybe I can use it somewhere
- Stage 2: I know this pattern, I think it’s awesome, I’m going to use it EVERYWHERE.
- Stage 3: Understanding that too much of anything, even good things can be bad. That there are optimal usages of a given pattern and less fitting ways to use them.
This put my brain on the track of well what’s next? What’s past that last level of knowledge?
The next level comes from having obtained the experience to be a functioning Enterprise Architect. Having already obtained the knowledge and understanding of the application of said pattern(s) the next level comes from balancing the appropriate level of adoption of the pattern by your software team.
Successful usage of patterns at the exa-mastery level will result in:
- improved code schematic cohesion
there’s nothing harder to digest than every project doing everything differently
- design stays true to DRY YAGNI and KISS
if you’re continually violating these you’re failing as an architect because no matter how awesome you think your systems and frameworks if they aren’t built with these principles in mind you’re lieing to yourself and your team and your business. Writing software is hard, when you expect others to use your patterns they need to be simple in usage regardless of whether they are ungodly complex or trivially simple under the seams.
- pattern usage that is easy to understand
this is directly drives off my last point, the pattern doesn’t need to be easy the usage does. A perfect example of this is MVC and the conventions around the rather elaborate MVC software pattern, by following the conventions you can work even if you don’t understand why. This is an important requirement to have success that implementing your pattern can be done by your most junior dev to your most senior architect.
- reducing code churn
good patterns hinge on DRY, or Don’t Repeat Yourself. Making this statement would have the corollary, good usage of software patterns lowers code churn. When software is built on top of repeatable success the lines of code that change should reduce because the amount of iterations to reach success should also reduce. Your pattern should be replacing the need to repeatedly do more work than neccessary. If your pattern is substantially increasing the work done for developers you need to have serious considerations on the usage.
- patterns will have as few external moving parts as possible.
is another aspect of keeping it simple but discrete enough to merit it’s own line, the more pieces you have to manually connect the harder it is to stay successful with a pattern. A perfect example of this is shown by many ORMs. You create a class file that defines your object, you create an xml mapping file that relates your class to the database table, you have to remember to have the xml file set correctly in the project so when you goto deploy that it’s still there and can be accessed correctly. The more disjoint pieces you make your team responsible for to use your patterns you exponentially increase the amount of failure. I can’t tell you how many times I saw people ready to pull their hair out in NHibernate forums and other discussion forums on why their mapping isn’t working and it comes down a hbm file being set to the wrong resource type.
BloggingContext.ApplicationInstance.CompleteRequest();
@dotNetChris #Marisic.Net 