You grok SOLID. You practice TDD. You've read Sandi's book…twice. You rewatch Destroy All Software monthly. You can pronounce GOOS. You know your stuff!
But some of your coworkers say your code is too complex or confusing for them. You might rush to conclude that must be a them problem.
But doubt lingers: what if they're right?
After all, the more thought we put into a bit of code, the more information that code carries. Others must extract that embedded meaning, either by careful reading or shared experience. Sometimes boring code is better. Let's figure out when to be dull.
Most developers understand that "clever code" brings added risk and carrying costs to projects, but most of us only understand the term as it might be applied to interpreter/compiler optimizations, to arcane program structures, or to dense routines lacking good names. This talk intends to paint a picture of how many of our community's Axioms of Good Design™ themselves represent a sort of cleverness. The advice we dole out as promoting maintainable code may inadvertently be making many systems harder to maintain in the future.
To illustrate, consider design patterns. Every design pattern has a lifecycle, just like anything else. First, someone discovers a pattern in their own code, gives it a name, and starts telling others about it. In the early goings, early adopters will excitedly propagate the pattern into systems despite the fact that other developers won't know what they're looking at yet. This can cause a lot of friction on teams: confusing developers who are new to the pattern and exhausting newcomers as they repeatedly unwind the layers of indirection most patterns introduce. Adopting a design pattern before it's reached critical mass is making a bet that it will one day be ubiquitously understood, but it's not always a bet worth making. And yet, the process of popularizing new design memes—painful as it may be—is critical to how the industry's understanding of software evolves.
The illustration above is not to foster a discussion on whether design patterns are good or bad, but rather to introduce new concepts about when experimentation and the promotion of new ideas are appropriate and when they can do more harm than good.
The outcome of this talk will be to illustrate a continuum of cleverness. Along this continuum, I'll chart heuristics along the way, citing when various levels of thoughtful design are warranted and defending the moments when uninspired, paint-by-numbers code is preferable.
This talk is a defense of "boring code". It intends to criticize the popular stance that carefully, properly designed application code represents an inherent improvement. I think conferences are the perfect opportunity to question established common wisdom—not because it makes for great entertainment or has any direct impact, but because the hallway discussions such presentations tend to encourage can fundamentally change how people approach their work.
The motivation for this talk is based on recent experiences as a consultant. We often find existing projects with very niche designs that are only readily understood by a small group of (coincidentally, incredibly expensive) people. Meanwhile, it's obviously unfair to saddle an unsuspecting business owner with design choices—no matter their technical merit—that would make a system much more expensive to maintain. This line of argument is well-understood in the agile/craftsmanship communities as an argument against poorly designed code, but it's rarely used to make the case for avoiding over-designed code as well.
I'd be eager to have a chance to tell this story, and I'd put in the effort to make it as engaging and thought-provoking as I can. Thanks!
Justin Searls has two professional passions: writing great software and sharing what he’s learned to help others write even greater software.
He helped start a software agency called Test Double, whose crack team of double agents solve complex problems with clean and simple solutions.
I, also, am already convinced. I found the "in defence of boring code" part very compelling, along with the "continuum of cleverness" part. I'm less interested in the bit about design patterns, but that's probably because I usually don't see people applying design patterns in their day-to-day code. Usually what I see is people DRYing things up to the detriment of code, either by making it so DRY that it's impossible to understand (what Bryan Helmkamp once called "chafe"), or by mistakenly drying out two things that look the same but don't actually represent the same idea. Another thing that I see a lot is helper methods -> introducing abstractions that basically just make you jump around in a fragmented way, instead of introducing abstractions that turn 20 things into 7 things so that you can hold a bigger piece of the picture in your head.