During a dinner with friends at RailsConf 2015, a conversation about old code—and how embarrassed someone would be looking back—came up. It’s not uncommon to watch developers hesitate or pre-explain the condition of their code when sharing it for the first time.
I understand where these instincts come from and recognize them in myself as well. Having played in enterprise, startup, small business, consulting, craftsmanship, and coaching playgrounds over the last 10+ years and listening to different perspectives, I’ve changed my tune. I hope I can convince you and your team to look at “old” code in a clearer light with the help of a few perspectives that highlight my feelings.
Stages of Learning
Steve Smith once gave a very appropriate description of the adoption lifecycle of software patterns. His words stuck with me, and I’ve found they apply in so many more ways than I suspect he anticipated. The idea is that we’re exposed to some technique or pattern, and then we use and eventually overuse it. Through these experiences, we find the cases in which the technique applies well and, more importantly, the situations in which the technique doesn’t fit. I’ve found that being aware of this lifecycle gives me peace of mind while exploring solutions. It also gives me a bit more empathy when looking back at older code. Empathy that I certainly didn’t have early in my career.
Monoliths and Microservices
During the opening keynote of Railsconf 2015, David HH staked his claim on the power of the monolith system over microservice architectures and distributed systems. His argument was that the monolith is easy to understand and easy to build. It’s hard to disagree if you’ve tried to orchestrate the alternative—flexibility doesn’t come for free. In other cases, stitching together many unique services across a broad organization makes sense and is well worth the overhead in terms of cohesiveness, productivity, and operational costs. Architecture is a reflection of the constraints, capabilities, and knowledge of the business and technical teams at any particular time.
Shirt, Shoes, and Context Required
As if on cue, Justin Searls gave a great, if misleadingly labeled, talk called “Sometimes a Controller is Just a Controller” on the final day of Railsconf. One of Justin’s points was that “good code” at best demands context and at worst doesn’t exist. Some of the longest-lasting and most impactful products are built on bailing wire and duct tape. Each year, data is poked and prodded, and systems are reconfigured for the coming season. Does this make the code bad?
It Is What It Is
All these sentiments are different sides of the same coin: our code and our systems are a reflection of ourselves, our team, and the situation we were in when we wrote them—no more, no less. Never be embarrassed of your creations, and don’t let anyone degrade your creations. Be wary of mocking systems you inherit. After all, 20 years from now, only the greatest collections of bailing wire and duct tape will be left standing.
