Beyond Patternitis: Why Great Engineers Embrace "The Boring"
In my recent LinkedIn post, I touched on the Pattern-Process Paradox: the growing gap between solving business problems and the ritualistic application of design patterns. While patterns were intended to mitigate complexity, their dogmatic over-application often leads to the very unmaintainability they were meant to prevent.
Today, let’s go deeper into the research.
The Psychology of the “Golden Hammer”
To understand why we over-engineer, we must examine how we learn. According to the Dreyfus model of skill acquisition, novices and “advanced beginners” rely heavily on rigid, context-free rules. For them, a design pattern is a survival mechanism—a “black-box” solution used because they lack the experience to evaluate a problem from first principles.
The danger zone is the “Competent” stage. Here, a developer has learned the how of a pattern but not the when. This is the breeding ground for Cargo Cult Programming, in which program structures are treated as rituals rather than functional necessities.
The Resume-Driven Development (RDD) Trap
We must also acknowledge the market incentives. Research indicates that 82% of software professionals believe that using emerging technologies makes them more attractive to prospective employers.
This creates a self-sustaining cycle:
Hiring managers (60%) admit that tech trends influence their job offerings.
Developers respond by imposing “buzzword” architectures, such as 50 microservices for a simple CRUD application, into projects to gain “marketable” experience.
The result? A “resume-driven legacy” of over-engineered systems that are difficult to maintain once the hype for that specific framework fades.
The Architect’s Remedy: Strategic Programming
If the goal of software design is managing complexity, how do we shift back to utility? John Ousterhout’s A Philosophy of Software Design offers the best framework: Strategic vs. Tactical Programming.
Prioritise Deep Modules: A “deep” module hides significant complexity behind a simple interface. Contrast this with “shallow” modules, classes, or methods that increase cognitive load by requiring developers to track logic across dozens of fragmented files.
Focus on Cohesion: A deep module thrives on high functional cohesion. Don’t fragment your logic to satisfy a “Clean Code” rule about method length; keep related logic together to reduce obscurity.
The 20% Investment: Tactical programming, which gets the next feature working as quickly as possible, leads to “Tactical Tornadoes”. Strategic programming requires an upfront investment of 10-20% of your time in design improvements to ensure the system remains maintainable.
Final Thought
Success in software architecture isn’t about how many patterns you can fit into a pull request. It’s about competence over ritual. True experts use heuristics and intuition to recognise the “vibe” of a failing system and choose the simplest, most effective tool for the job.
Sometimes, the most “senior” thing you can do is choose the boring solution.