Problem Solvers
Software developers aren't hired to write code
Software developers aren’t hired to write code. We’re hired to solve problems. We just happen to solve problems using code most of the time.
Most developers, with or without computer science degrees, have studied data structures and algorithms. We use them to store, retrieve and sort data efficiently. These are well-defined problems with narrow scope within the domain of computer science. Their solutions can be proven correct. Their solutions often are available directly in programming languages, utilities, or open-source libraries because of these problem well-defined attributes.
Most software engineering problems aren’t well-defined or narrowly scoped. Customers can’t articulate what they really want often because they don’t really know what they want. These are business domain problems. There are no off-the-shelf solutions. Software developers usually design these solutions individually.
While each business problem will usually be unique, we often don’t have to start from scratch. Most business problems contain similar problems elements that we encounter repeatedly in our careers, even if they’re in slightly different forms. There’s enough repetitiveness for us to recognize these sub-problems again and again, but they’re just different enough that we can’t plug in an as-is solution such as a data structure, algorithm, or open-source library. Data structures and similar components may be part of the solution, but they usually aren’t the complete solution.
Design patterns are a set of techniques to solve repeatedly occurring problems. They are a starting point, not the final destination. Each application of a design pattern will have to be tailored for the situation in which it’s being applied.
This is a double-edged sword. While there is usually no off-the-shelf design pattern to use as-is, we have the freedom to customize each design pattern application with each specific use. We are not constrained by the boundaries of a design pattern’s definition as could be the case with data structures or algorithms. We can follow a design pattern traditionally or we can modify it as needed. And we’re not restricted to just one design pattern per problem. Much like chess pieces in combination play, many design patterns work well together in combination. We just need to learn how to play the game well whether in chess or design patterns. I’ve rarely used just one pattern in isolation. I often include several in the same design.
Developers who know design patterns have options. When considering the design for a new feature, they don’t have to stare at a blank page for too long. Something in the feature will be familiar enough to start a design based upon their design pattern knowledge.
Designs based upon design patterns tend to be modular. The implementation tends to be easier to unit test. The implementation tends to be easier to maintain. And when customers see software that doesn’t align with their expectations, it tends to be easier to modify the implementation or design to satisfy the customers.