Seventeen seconds remain. Seventeen seconds—no timeouts—4th and goal—trailing by 4 points. Scoring a touchdown is the only way to win this game. Everett Golson settles into the shotgun with the play clock winding
down. He takes the snap, rolls out to the right, and lofts a perfect pass to Cory Robinson. Touchdown, Notre Dame! But wait—there’s a penalty flag on the field. The play—a well-designed and highly controversial play known as the
“pick” play—is negated, and #5 Notre Dame loses to #2 Florida State.
Six seconds remain. Six seconds—one timeout—1st and goal—trailing by 3 points. A field goal sends the game to overtime, but a touchdown will win the game right now. Deshaun Watson looks left, then sends a back in motion, glances
to his right, and calls for the snap. He rolls right, and with one second remaining on the clock, sends a perfect ball to Hunter Renfrow for the touchdown that propelled Clemson to win the 2016-2017 college football national championship. The play?
You guessed it. It was a well-designed and highly controversial play known as the “pick” play.
There was only one real difference in the two scenarios above. In the first play from 2014, the receiver who didn’t catch the ball clearly went straight into “blocking” mode and initiated the “pick” on the defender, which
is illegal. In this year’s national championship game, the receiver was actually shucked to the ground by the defender, which is completely legal since the receiver didn’t initiate the contact. In this scenario, the offensive player on
the ground becomes a classic “unintentional” pick on the defender.
What does a football play have in common with software development? Quite a bit, actually. In software development, we don’t get a touchdown called back for intentionally doing something that doesn’t follow any pattern. However, we do encounter
situations where poorly written code won’t scale with the needs of our clients, doesn’t handle errors well, fails to respond well under peak demands, or is not as secure as it could be.
When the game is on the line for the football team, or the software goes to production for the software team, it’s critical that each player executes exactly to plan. Failure can result in any number of unfortunate events taking place. To mitigate
the chances of failure in football, the players spend hours running drills and studying X’s and O’s on the whiteboard. In software, we turn to design patterns to guide us to more elegant solutions.
What is a software design pattern?
Simply stated, a design pattern is a proven strategy for attacking well-known problems in software development. Design patterns don’t provide any code (so they can be used across languages), but do provide a blueprint for how the system should be
modeled as the software developers write the code. When patterns are implemented correctly, software is generally much more efficient to maintain and enhance. Like the football play that is executed correctly, software that uses design patterns delivers
the expected results to clients and the clients’ customers, even as needs and demands on the software change.
Design patterns are not new. Design patterns were first introduced in the 1994 book “Design Patterns: Elements of Reusable Object-Oriented Software,” by
four guys known in the software development world as “the Gang of Four” (GoF). Most of the original patterns the GoF introduced in that book remain relevant to this day. With the pace of technology growth and need to adapt to change
quickly in today’s software development environment, patterns are perhaps even more important than ever before.
At Far Reach, we look for situations where applying a design pattern is relevant and beneficial. We believe using patterns allows us to produce better software that is:
- Scalable – can accommodate significant increases in usage without requiring the rewriting of a significant amount of code
- Maintainable – experiences fewer production issues and ongoing support is straightforward and efficient
- Secure – keeps user data safe from unwanted hacks
- Accurate – does what it's supposed to do
- Useable – is user-friendly and performs well
- Portable – can be easily moved to different hosting environments and can be used on many different types of devices
In the two football plays above, both teams had the same desire—to win—and both teams ran a well-designed play. Unfortunately, one of the teams did not execute the play as designed, drew a penalty, and lost the game. In software, it is also
entirely possible to write code in many different ways to accomplish the task at hand. Even though there are many ways to write software, there are some proven ways to write software that ultimately provides more value. We believe following design
patterns while developing software products is a great way to deliver results when the game is on the line.
See the plays above in action:
Read the original Gang of Four book.
Read my favorite book on Design Patterns.