Critical Mass and Aspiration

Some weeks back, Kiril Savino (GameChanger’s CTO) wrote that it’s important for developers to understand and support the aspirations of a code base. Kiril argues that it’s alright for a particular work of code to be messy and imperfect if it’s not inconsistent with the codebase’s aspirations. A hacked together method isn’t great, but it might be acceptable. But it’s a bad idea to directly access the database by circumventing an API designed for that purpose.

I love the concept of code aspiration, but I consider an aspiration successful only if it eventually comes true. I’ve seen a lot of half-adopted aspirations that only add confusion. I’ve found that aspirations get adopted when they reach a critical mass, in our minds and in code. When an aspiration reaches critical mass, it’s easier and more natural to follow the aspiration than not to.

I’ve succeeded and failed before at getting critical mass for my aspirations. There’s no formula, but here are a few things I’ve seen work well:

• "Open source" your aspirations. At a previous job, I started to organize our codebase around the principles of Domain-Driven Design. A couple of weeks before I left that job, I explained my aspirations to others. They liked the idea, tinkered with it, and simplified it to the point where it was practical in our environment — all after I had left for graduate school.
• Make adoption easy. Good documentation, good code examples, and time-saving tools make it easy to follow the aspiration of a code base. I’m hoping that our interface to Graphite at GameChanger will be so easy that everyone will use it to create graphs of system behavior.
• Create examples in code "hot spots." I once rolled out a new template engine in parallel with a legacy engine. Migrating all of our code to the new engine would take years, and so I prioritized migrations of code that was modified frequently by a broad variety of people. Forcing most people to use the new engine at least sometimes caused them to become familiar with its aspirations.
• Code review. Yesterday, a code reviewer informed me that I was violating an aspiration I didn’t know about. These misunderstandings happen all the time, and code review is a good way to fix them.
• Appeal to higher authority. I’ve never been a huge fan of this technique, but I’ve seen people successfully enforce code aspirations by seeking an executive mandate. Amazon.com’s migration away from its legacy Obidos web stack was enforced by an order from above.

I’ve failed at this before too. I’ve aspired to things that, in retrospect, were dumb. I’ve failed to make my aspirations clear, and I’ve failed to get people to adopt aspirations. And, on one project, an ill-timed adoption of Adobe Flex, I committed all of these sins.

Aspiration is good. It’s even better when it comes true.