Publishing our development standards

By: Tim


  • standards
  • principles
  • security
  • code-review

Following on from Simon’s recent post on how we do code reviews at globaldev, we looked at the other development standards documentation we have and decided that it was worthwhile publishing that too.

So, as of right now, our internal development standards are now public on GitHub at globaldev/standards.

What have we published?

  • General principles: a small set of general software design principles that should be followed regardless of project or language.

  • Application security guide: it’s vital that architects, developers and testers all have a solid understanding of the types of vulnerabilities that are common in modern web applications: how to identify them, and how to avoid them.

  • Code review guide: peer code reviews are a vital part of our development process. They not only allow for early capture of potential issues, but also as a method of spreading knowledge through the team. This document contains the what, why and how of requesting and performing code reviews.

  • Language-specific coding standards: coding standards for ColdFusion, JavaScript, Ruby and CSS.

How does publishing these benefit us?

  • By opening up our standards to everyone, it means there are even more people to hold us to those standards. If we release other open-source code and it doesn’t meet our own standards, then people can pull us up on it.

  • It’s a guide for anyone who wants to contribute to any of our existing and future open-source projects. Rather than having individual contribution guides for every project, we can just point people at this one repository.

  • Everyone else gets to see how we approach our work, and this might encourage some people to think about joining us, if they like what they see.

  • Anyone who comes to work with us can get a jump-start on the high standards we hold ourselves to. In addition, if that new starter comes in and sees code that doesn’t meet those standards, then they’re within their rights to ask “why not?”

And how does it benefit everyone else?

  • We’ve found that having defined standards has been incredibly useful, but it’s taken us quite a long time to pull together a set that’s both reasonably complete (there’ll always be things to add) and that everyone’s happy with. Hopefully what we’ve got here will act as a jumping-off point for other teams and individuals to set their own standards.

  • There are plenty of other people out there who have published their own sets of standards, so why add to the pile? Because every company and team is different, and while a reader may find someone else’s standards and guides don’t quite match up with how they want to work, ours might be a better fit.

  • The work within our standards repository is licensed under the Creative Commons Attribution-ShareAlike 3.0 license. This means that you are free to copy and redistribute the material in any medium or format; remix, transform, and build upon the material, for any purpose, even commercially, as long as you give appropriate credit and redistribute your contributions under the same license.

A living document

The published documents will be updated as our processes, technology choices and preferences change over time. It’s amazing how many discussions you can have about whether to put spaces after an opening curly bracket or not.

Have a read at globaldev/standards and let us know what you think.

About the Author