4

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)?

Lance
  • 2,537
  • 15
  • 34
  • 3
    Start by relying as much as possible on commonly-accepted conventions and well-established automated tools like linters and IDEs that will make some of these decisions for you. – Robert Harvey Oct 23 '19 at 18:43
  • The last four bullets can be solved with a little research into "best practices," some architectural guidelines, and an admission that "it's not always going to be perfect." – Robert Harvey Oct 23 '19 at 18:47
  • 1
    My experience (now its 2019 not 1992) is out of 50 developers 45 will say "I like x, y and z, but just tell me what it is and give me a tool to enforces it so we can focus on the real work", 2 or 3 will be really keen to do get together and write up the consensus and one or two will be belligerent because they can. Give the two or three a couple of weeks to publish it and sort a tool, sack those that refuse to conform to it - why sack them - because if they are unprofessional and not team players. If they cannot be belligerent over this, they will be belligerent over something else. – mattnz Oct 25 '19 at 03:30
  • On thing not mentioned so far in the answers is Code reviews. – mattnz Oct 25 '19 at 03:31

4 Answers4

6

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.

Matt
  • 2,232
  • 1
  • 13
  • 13
  • ... also consider whether a rule can be enforced mechanically, be it by auto-fixing the sources or at least warning about non-conformance. – Deduplicator Oct 23 '19 at 19:20
  • re: "Many large organizations have made their standards documents freely available on the web" Do you have any examples of this? I'd like to look at a few, but my Googlefu is weak. – Wally Hartshorn Oct 24 '19 at 18:15
  • @WallyHartshorn Here's one for C#: https://tics.tiobe.com/viewerCS/index.php?CSTD=Rule – Matt Oct 24 '19 at 18:35
6

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 1
    I really like the "start with a smaller team" point here. It works well with the reality that the coding standards and style guide are slaves to the existing code base. The whole point is that code base is what really sets these. The rest are just stale out of date reports of what you found in the code base. The style and standards that exist in the codebase are your single source of truth. That is what you're really trying to be consistent with. – candied_orange Oct 24 '19 at 23:34
2

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.

god
  • 232
  • 2
  • 7
-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.

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • "If you let everyone do whatever they want, a lot conflicts and people get angry." I agree the sentence is incomplete, but the meaning clear : it doesn't seem fine. – Pierre-Antoine Guillaume Oct 23 '19 at 23:17
  • 6
    I've worked hard mastering a multitude of styles precisely because letting everyone on a team code in their own style creates a miserable code base and isolates the team members. No. Sorry. You choose a style and stick with it so long as it works. Can't choose? Flip a coin. Obey the coin. – candied_orange Oct 23 '19 at 23:34
  • The problem with that is A. you assume you can get everyone to agree and B. styles change and now you are locked in – Ewan Oct 24 '19 at 09:12
  • 4
    To my experience, letting each team member code in their own style is as bad as trying to enforce a 100% consistent style over a huge team or multiple teams. I had my best experiences with systems developed of different components and small sub-teams, where each sub-team has something like a standard (written or unwritten) among themselves. – Doc Brown Oct 24 '19 at 10:55
  • 4
    I think this answer is terrible advice. I always prefer working on codebases that enforce a consistent style (even when it is the "wrong" style) to working on codebases that are a mixture of different styles. – Stephen C. Steel Oct 24 '19 at 14:16
  • 31 years of experience tell me this is terrible advice. Look at the other answers. – MetalMikester Oct 24 '19 at 14:17
  • 1
    Pronouns aside, the terminology you used to describe "refactoring for purely style reasons" is offensive to pretty much _everybody_. – Kyralessa Oct 24 '19 at 14:46
  • 1
    Alternative point of view: If, as a developer, you're going to get 'pissed off' by having to conform to a team coding standard, perhaps you shouldn't be coding as part of a team. – Eric King Oct 24 '19 at 18:01
  • @ericking how about if your a developer that is going to get pissed off unless a single style is enforced you shouldnt be working as part of a team? – Ewan Oct 24 '19 at 18:25