How do you get everyone on the same page in terms of coding preferences on a smallish team?

Question

Say you have 10-50 engineers working on a codebase. Everyone has different preferences for these types of things:

• Folder Structure
• Naming Conventions (CSS Class names, function names, variable names, etc.)
• Testing Conventions
• Expression location (where variables are defined within a file, etc.)
• Encapsulation (should this go into a utility, a class, etc.)
• How to write specific expression types
• etc.

If you let everyone do whatever they want, a lot conflicts and people get angry. If you enforce a specific style guide, then you might not foresee specific use cases and you have a lot of boilerplate. If "leadership" picks the direction, people feel left out.

How do you decide on a specific preference set, generally speaking (i.e. not concerned with whether it's a Folder Structure discussion or CSS naming conventions)?

Answer 1

Matt's answer gives good advice (as well as Robert Harvey's comments to the question), but both are IMHO incomplete in regards to the question on how to get up to 50 people on board. The organizational issues for trying to get 5 persons working on the same standard are quite different from the issues you face when you have 50 people to manage.

About 20 years ago, I had been in such a situation, where we had some teams of roughly that size in total for a new project, and we tried to set up standards up-front among them over a period of about 6 months(!). It was not a complete desaster, but definitely not cost-effective, and further improvements in those standards were actually hard to bring in afterwards. Looking back from today, I see some things we could have done better there:

• Start with a smaller team of maximum 5-6 experienced devs and give them time for some iterations for prototyping the ecosystem, the architecture and the coding standards of the system. Then scale up - people which come later to the team will have to adopt the already given standards. They may bring in further suggestions for improvements, but no complete change "from the ground" - at least, not without getting a buy-in from the management.

• A team of 50 is too huge to work all "on the same code base" in full, there are usually sub-teams for different parts / components of the product. Don't insist that every sub-team obeys precisely to the very same standard. Give them some room for improvements on their own. The communication overhead is usually not worth it, and if you have to move a dev from one subteam to another, the dev can usually and quickly adopt to the "variant of the standard" of the individual subteam. In such a situation, it is more important having rigid interfaces between the components than to have all components 100% structured in a similar way inside.

• Make sure you don't standardize for the sake of standardization. Keep the "global standards" which are valid for all to the necessary minimum. If it is really one coherent system which should be build, things you usually need to standardize are the "eco-system" of frameworks/programming languages/operating systems involved, the global folder structure, the server technologies involved (database, web, SCCS). But let nitty-gritty details like "where variables are defined within a file", or lower levels of the subfolder structure to the smaller subteams. Trying to standardize such things for a huge team is usually not worth the hassle.

Answer 2

Use one or more published coding standards documents as a starting point for discussion. Many large organizations have made their standards documents freely available on the web for just about every conceivable language and framework. Download some of those documents and distribute them for the team to review and consider, making it clear that the documents are just intended to facilitate discussion and your team's opinions are being sought. Then, have some face-to-face meetings as a team to go over those standards documents and give people a chance to state their case for or against particular rules and decide which standards are worth adopting. Along the way, developers will inevitably propose some rules that are not in any of the published standards documents that you started with and that's ok too.

Have discussions, aim towards forming consensus, hold votes if particular rules are contentious (votes about whether or not to adopt a rule at all vs. leaving that particular matter to individual discretion and, if a rule is to be adopted, what that rule should be), etc. If the discussion and decision-making process is conducted in a fair and equitable manner, then consensus and buy-in should be achieved even if not everyone is happy with every rule in the standard because they have good reason to respect the process that produced the standard.

Answer 3

Conflicts arise when people's abmitions clash. You can avoid this by using automated system which enforces conventions. Policy documents and coding guides are of little help because they are subject to interpretation. Commit hook checking formatting rules, naming conventions etc is much cleaner solution which ensures everybody gets similar treatment.

Answer 4

Don't

Let people code in their own style.

Make a rule which says, No refactoring for purely style reasons. Thats 'A dick move'

People learn to work with various styles pretty quickly and its fine.

Put it this way. say you have a team of 5, you probably have 6 different styles. If you enforce 1 then you just pissed off 4 people.

But its worse than that. 3 years later you'll have 5 pissed off devs because the guy who made the origional choice has moved. You'll be programming to a document that is patchy and dosent match any current style.