There’s nothing wrong with the need for speed in coding. However, if you lack coding standards, your products will become fragile and liable to break down in the future. Move fast and you’ll break things over and over. Let’s talk about why coding standards matter.
Life without coding standards
Facebook made the phrase “move fast and break things” famous. If you’re in startup mode, speed matters. After all, you’re painting a blank slate. If you never grow in your coding standards, how will that affect your product and team?
Think of your main product and how it evolved. Each month, you ship new features. Each quarter, you comb through bug reports. And then look for ideas to improve. Each developer on the team has their style. For instance, one developer may religiously use comments to describe what they’re doing. Another developer may use the “write drunk, edit sober” philosophy and focus on achieving quality through debugging. As a manager or team lead, it’s tough to stay organized and productive.
Widely differing code standards also hurt your team’s effectiveness and morale in subtle ways. Think about hiring new people to the team. How long will it take new hires to learn how your team codes? Without a clear commitment to a coding standard, the onboarding process will take longer. Furthermore, when people use different coding standards, debugging and testing become more difficult.
One way to solve the problem of slow product development and team tensions? Adopt a single coding standard for the team.
Introducing coding standards
What coding standards should you adopt for your company? Ask 10 developers, and you’ll get 11 answers. Rather than prescribe a solution for your company, we suggest reviewing the following options first. But a word of caution: It’s easy to go overboard with coding standards. A small number of rules or principles will go a long way.
The principles approach to coding standards
Rather than discussing specific technologies and providing samples, the principles approach goes a different way. For instance, think about the Manifesto for Agile Software Development. You can see that as a principles approach when it suggests: “Business people and developers must work together daily throughout the project.”
The main problem of this approach? Developing robust first principles takes some serious thinking! It’s not going to be an overnight process. The benefit is that your company will have broad ideas that can be applied to a variety of circumstances.
Issues to consider when creating coding standards:
- Emphasize decision making values. Principles help guide how a developer approaches code. For example, the agile emphasis on close collaboration with the business helps you plan your daily coding work.
- Prioritize the long term. A principles-based coding standard should be able to stand for two or three years without any changes.
The procedures approach: Coding standards with all the details
In other situations, it makes sense to push for detailed procedures. If your company has armies of developers and you are struggling to stay consistent, procedures may be a better approach.
- Balance theory and practice. For procedures to be beneficial, state a broad principle (for example, write comments in clear English with minimal slang) and provide examples of good code.
- Set a length limit. A 200-page coding standard document, even if valuable, won’t encourage developers to open the document.
Final coding standards tips
If you use the procedures approach to coding standards, appoint someone to own and maintain the standards. Otherwise, you may end up with an out of date document that provides little value.
Now based on those options, make some choices about what makes sense for your company. Balance your personal preferences with what your customers value. For instance, national defense customers will place a high value on security and internal control. If that’s what your customers want, then start building those points into your product.
Cultivating code standards from the get-go does not cost much (apart from some discipline), but can save the whole team a world of hassle and misunderstandings later on. The longer we nurture our own practices, the more we realize that!
So true! 🙂