Design Standards vs Code Standards

I really like this post by Richard Rodger, addressing the validity of coding standards. I’ve always had this viewpoint, that code standards don’t really get you any benefit. If anything they actually detract from the creativity and motivation of your team, turning developers into “code monkeys”.

On Reddit, Michael Feathers had a good comment in relation to this article: that there should be more of a focus on Design Standards in code compared to Code Standards. I agree with this to a degree, that there’s more value in pointing out the design of your architecture and making sure that everyone on the team is aware of it. But there is still a bit of a “code by template” threat here.

The Comfort Zone

The thing I don’t really like about “standards” is that people get comfortable with them and effectively stop thinking. Some of the best feedback I’ve got on code I’ve written professionally is when we bring in a new person who’s unfamiliar with the codebase. Because they’re not used to the way we’ve architected things it prompts them to ask questions and engage in discussion. Which is great for both parties – it forces the old employee to think critically and be able to reason the architecture choices they’ve made, and it allows the new employee to offer suggestions and/or get more familiar with our system.

But if you don’t have a lot of turnover or inquisitive minds on your team, it’s very easy for people to fall into a comfort zone with the codebase. Especially with an older system where it would be pretty difficult to institute any changes even if you wanted to. If a new programmer comes into a larger legacy team that’s stuck in this comfort zone and is told that “everyone does database access using X”, they’re probably not going to question it.

On the flipside, having design standards make it a lot easier to ramp up new people into existing teams. In addition, actually writing down the design standard the team uses forces the team (or at least the documenter) to fully understand and critically think about the design choices that have been made on a project.

A Compromise Between Creativity and Standards

I think a good compromise is to have design standards, but also force yourselves as a team to review them on a regular basis. Like our team at iQmetrix does with our bi-weekly team retrospectives, we do a proper “what can we change for next iteration” discussion and pick at least two things to work on. “Every two weeks” is probably way too short of a timeframe to do a design retrospective for an application, but maybe focusing on one aspect (i.e. data access) every month would be appropriate.

A retrospective like this could take into consideration a review of the existing methodologies, maybe a team discussion on any issues or compromises with the current technology, as well as maybe one or two research spikes into new technologies that might apply to the situation. An example retrospective conversation would look like: “Sure, we’ve used MSSQL for the last 10 years, but some of our paging queries are getting awkward to write. What would happen if we did the same thing with MongoDB? Or Entity Framework? Or a hybrid approach?”

The key point is the same negative effects from “code standards” could slowly creep into your “design standards” if you’re not careful. Having a template from which you write code will slowly kill creativity and motivation. As with anything, it’s important to take a critical look at what you’re doing on a regular basis to ensure you and your team stay fresh and relevent.