The importance of standards in development teams

Very few people like to be told what to do. Even fewer people like having the freedom to choose what to do but zero freedom when it comes to how it gets done.

This is completely normal, human even, we (especially in the IT industry) like to think we know better and that our ways are the best ways. And that’ll work great for you as long as you work alone, which is the case in many projects.

If it’s small enough, you’ll probably be the only developer on the team, maybe dealing with designers and markup writers (if it’s a web project) and you can definitely tell them how you want stuff done.

But even then, you are the one setting the standards. So when it comes to working as a team, with other developers, you better do the same, or you’ll soon realize they come with their own standards and (just like you) they’ll also be waiting for everyone to follow them.

Standards, standards, standards

It’s all about standards when it comes to a happy, drama free, working development team. Don’t get me wrong, you’ll have drama eventually, it’s only normal when it comes to people interacting with people, but standards will help you reduce the chances of it considerably.

So what kind of standards should you even consider setting up for your team?

Communication standards

It might sound silly, I know, everyone knows how to talk to other people. But the idea is to make sure important information is not missed and irrelevant communication doesn’t clutter the main channels.

Here are a few ideas you might want to consider, but of course, you’ll have to adapt them to your reality:

Daily chatter

Even when it comes to co-located teams, persistent chat rooms are great. “Persistent” is the key word since you want most of this communication to be easily searchable in case you need to remember something someone said. Maybe the login credentials for the dev environment? That kind of information should be in some sort of wiki, of course, but you know how that goes. A lot of people tend to ignore it and ask their teammates (’cause that’s faster, right?).

On a similar note, you’ll want to sit for a second and think about what your team will be discussing. Because most likely, if you’re dealing with a team of more than two people, you might have several different topics to cover, for example, front-end related stuff, back-end development, deployment notifications, tech-issues questions, devops problems and the single most important topic you’ll want to compartmentalize: random.

Yep, you have to find an outlet for the silliness and the jokes, and the random YouTube and Twitter links that will appear on your group chat. If you don’t, then people will use the “official” channels for that. Trust me.

By separating topics (even silly topics), you can make sure streams aren’t crossing and you end up with a single chat room where people discuss an Angular bug, connection issues with the GIT server and share a silly cat video, at the same, freaking, time. Yeah.

This approach is great, and works great with tools like Slack, Hipchat or similar, pick your poison, just make sure it is able to handle them.

Finally, a note about remote teams: if your entire team is remote and geographically distributed (which is something that happens more and more every year), persistent chat rooms are a must, because the communication will have to be asynchronous. Yes, you can use email for that, but as you’re about to read, email can be used for other, less spontaneous types of communication.

Actually important and relevant communication

Email and chat have different connotations for people, while the latter usually implies a more direct, to-the-point communication (even if it’s done asynchronously), the first one tends to be ignored and has less internal priority (meaning, people might wait longer to read your emails, especially if there are a lot).

That being said, there is information you’ll want your team to be able to return to. Email is good for informational announcements, such as changes in internal team dynamics, release notes, roadmap changes and the like.

Meet only when it’s needed

Finally, if email and chats don’t cut it, you should also consider a face-to-face instance (or as face-to-face you can get, like a video call) where only the involved people can work out whatever issue there is (not talking about personal issues here, just whatever problem they’re trying to solve but can’t do it over text).

The key here is to avoid meeting just for the sake of meeting because this is the most consuming type of communication you can have. Whenever you meet, everyone involved will have to break their concentration and pay 100% attention to this meeting, which is something they don’t really have to do for email (they can just not read it while focused on their tasks) or chat messages.

Personally, I prefer to have ad-hoc meetings whenever needed, but avoid scheduling recurring ones, especially if they’re just to “sync-up”, that can probably be done over other channels. Just try to sit for a second, look at your calendar, and add up the amount of time you’re setting for your team to meet. You’ll know then if it’s actually worth it or not. Like everything else I’ve mentioned so far, it’s not a rule, but rather a set of guidelines you might want to take and make your own.

Coding standards

Now, communication is important and having standards for the entire team will definitely help you properly interact with them, but if we’re talking about standards that benefit development teams, we need to touch on coding standards.

Styles up the wazoo

You want to make sure all of your fancy developers are writing code following the same style guide. Why? Because you’ll all be working on that code at one point or another.

You might consider having different style guides between different sub-teams if you have front-end and back-end teams.

If one team is working on JavaScript and the other is using Java, then it might make little sense to share styles. Although, if both parties are using JavaScript (with Node.js in the back-end), sharing styles for their code might actually be a good idea.

Inconsistent styles between team members would be the equivalent of having a group of writers writing a story both in English and Early Modern English at the same time, can you imagine?

“Prepareth to square! I shall heave the gorge on thy livings, naughty mushrump! Said the hero, trying to hide his irrational fear of mushrooms unnoticed.”

You can definitely read it, and you can make sense of it, that’s true. But you’re making an extra cognitive effort to perform the translation (or normalization if you will), and that is what you’re trying to avoid when sharing styles amongst team members. You remove that extra effort required to understand someone else’s code, allowing you and others to go ahead and feel comfortable adding and changing code around whenever required.

This also helps find problems while doing code reviews (a practice any big enough dev team should follow).

There are plenty of already existing and well accepted coding style guides out there for most programming languages (for example and to name just a few, Airbnb has one for JavaScript, Google published their Java style guide and PEAR has one for PHP).

You can definitely grab one of those or create one for your team. Maybe it’s a mixture of several existing ones or maybe it’s just the way you’re used to coding and you want everyone to do it like that. Whatever works for you and your team, the point here is to use a single standard across the team.

Some points to focus on if you decide to create your own are:

• Comments — don’t forget about them, they need to be present and meaningful. This is key, there is no point in writing “constructor method” above the constructor. But it definitely helps if you’re explaining the complex parameters it receives. The important thing about comments is that they need to be helpful, commenting for the sake of commenting makes no sense, avoid it at all cost.
• Naming conventions — both for functions/methods and for variables. It’s useful to know if your teammates are using camelCase or snake_case when creating code that you might end up using. If you have ever used PHP 4 or 5 (yes, it was a long time ago), you’d know what I mean. The language itself had no internal consistency regarding the native functions’ names, so you were always forced to go back to the documentation to understand how they were named. It’s also useful to know the language your teammates are using to name entities, as in, are they using English? Spanish? Klingon? They’re all valid options, just make sure everyone is doing it the same way.
• Testing — is there going to be testing involved? You might want to make sure that as part of their code, they also add the corresponding unit tests. Maybe for every function, they might need to have unit tests covering at least 80% of it? That’s just a number, the point here is: you can use these standards to also ensure a certain level of quality to their output. That being said, you should also remember that unit tests aren’t magical and 100% coverage with all tests passing doesn’t necessarily mean bug-free code, it’s just a step closer to that fantastic (and most of the time) hard to find place called “bug-free land”.
• Code characteristics — other less important (in my opinion) code characteristics, such as maximum line length to avoid word wrapping on different IDEs, code block styles (when applicable), indentation (are you using tabs or spaces?) and so on. These are helpful to improve the developer experience, especially if your team is using different IDEs.

There can be other aspects that might be relevant to your project as well, depending on the language used, for instance, semicolon utilization for JavaScript-based projects, or whether to use the “<?php ?>” or the “<? ?>” tag on your PHP files.

The important thing to remember here is that there is no good or bad set of styles, but only what works and what doesn’t work for your team. Try to take into consideration their opinions and their experiences if you are the one creating the guide.

Finally, and as an extra piece of advice for creating coding style guides, is that you find a way to automate the checks and balances system. You can write and distribute your style guide, but you need a way to make sure everyone is following it. Otherwise, things might get out of hand (depending on your team, you might end up having devs thinking they know better, it’s totally normal), so you should look into implementing one of the many tools for the most common programming languages out there.

Development process

One last piece we can look at is the actual development process. What I mean by this is, once developers know how to write their code in a way that works for everyone, they should also all agree on how to move that code from their dev laptops into a production environment.

Any sensible and big enough project should have several stages before the code can actually get into production, simply to ensure it’s working as expected and that it’s actually what the product owner (be it the paying client or an internal group within your organization) was hoping to get.

Defining your environments

This is a standard that depends on your project’s needs, you might require a really hard quality assurance process or you might have a Product Owner who doesn’t really want to get involved.

You might not have a QA team available for you to work with, or you might just have access to test automation engineers. There are many variables to take into account, and with all of them, you need to define how the code is going to flow all the way up to production, and through which environments.

I like to use the following setup when starting a new project:

It covers the basics:

• A development environment where you can test your code integrated with that of the rest of the team. This is something you might not be able to do in your personal workstation if the system you’re developing is complex enough.
• A test environment for your QA team to review your work, a place where code is more stable and there aren’t obvious integration problems that can be spotted in the previous environment.
• A place for your product owner (whether it’s a paying client or an internal group within your company) to review the completed features, to double check you’re delivering what that person is expecting to receive.
• And finally, a production environment, where your code will be deployed once it’s approved by all stakeholders involved.

Whatever setup you decide to go with, just make sure to document the process and correctly inform your team about it. The point here is to delimit the access and control of each sub-team.

For example, your testers should not require access to the development environment, and your devs shouldn’t have access to production. Whatever deployment needs to take place, should be done automatically using some sort of CI tool (such as Jenkins or Bamboo).

Controlling your versions… or something like that

The final point I want to touch on here, which I think really benefits from a standard process, is the way you and your team will handle version control for your code. Whether you’re using GIT, SVN or (oh god please no) CVS, there is never a single way to use them to effectively version your source code, and having teammates following different strategies might cause severe problems.

Personally, I prefer to use GIT for my projects, since it’s a tool that provides a lot of control over how you go about versioning, it saves a lot of disk space through it’s branching strategy and has a great community behind it.

Particularly for this tool, there are many strategies to handle version control, mainly they involve the use of GIT’s branching model.

I tend to have main “core” branches for every environment, and several small branches for features that get used in order to avoid mixing up unstable code before it gets merged and tested.

So if you tie these core branches with your CI system, you can automate deployment whenever a merge is performed into them (giving you a way to control when those merges happen directly by promoting code between branches/environments).

The following diagram provides a general high-level overview of the way your code should flow from one environment to the other:

Just like with the environments, this is a critical process to document, ideally, before the project even starts in order to avoid any problems between different teammates overwriting their respective code. Whatever strategy you decide to go with, make sure you’re clear regarding the flow and the actual commands to use, this is crucial, since not everyone has the same knowledge and understanding of these version control systems. So don’t be afraid to even document the actual commands or present screenshots for your usual IDE’s and step by step explanations on how to perform code promotions.

So, to sum it up

Hopefully, by now all of these points have given you an idea of the benefits that come from having standards within your project, both when it comes to the actual source code of your development team and for the rest of the related processes involved in any software development project.

Learn to love standards but make sure they’re not written in stone. If they don’t work for your team, make sure you can adapt and rewrite whatever is needed. They’re not meant to enforce a way of working but to help facilitate interaction between teammates, remember that.

---