1

In my software development team, we have established some guidelines to help single developers take decisions on their own. Recently, some discussion arose around one of those guidelines. It deals with whether one should generally opt for uniform, consistent approaches or not. Or, put differently, whether the burden of proof should lie with the one wanting to do something differently or with the one trying to establish a standard. Put in a nutshell, these are the two opposing points of view:

  • View A: Use a uniform approach, unless there is a convincing argument that it's disadvantageous

  • View B: Don't care about a uniform approach, unless there is a convincing argument that it's advantageous

Clearly, this is just a very abstract guideline, and both the cost and benefits of uniformity as well as those of non-uniformity will vary a lot for different situations. Examples of where we see this guideline as applicable are coding standards, API and UI design, development processes and used development tools. I would also guess that this is a matter of scale: The larger a team/organization becomes, the more disadvantages for a single, uniform approach appear. And the longevity of thinking is probably also a factor. For that matter, in our specific case, we talk about roughly 20-25 people in a few closely interacting sub-teams and we are in a business where long time-frames are relevant.

From my software engineering background, my gut feelings say "standards are usually good", which leads me to prefer view A. But as I said, others on my team disagree, and some voices in the literature (e.g. Manuel Pais and Matthew Skelton in "Team Topologies") call view A "Monolithic Thinking" and note it as an anti-pattern.

Question: Is there evidence (empirical, as hard as possible) that either View A or View B is preferable as a general guideline? Does this apply only for certain contexts/situations (e.g. "view .. was shown to be better in teams up to .. people" or "standardization was shown to be beneficial in area .. but not in area ..")?

Improve this question
1
  • Tade-offs. You need just enough standardization and just enough freedom to stray from the standard when there are advantages to do so. In my experience you need standards for people that lack experience. It's an a priori thing. You set the standard and tell people to follow it to ensure the desired outcomes. When people are experienced they know the best way to do something. At that point you could gather those things and think they are a standard. It's an a posteriori thing. An a priori standard will negatively affect the experienced. Not having one will negatively affect the inexperienced.
    – Bogdan
    Commented Sep 17, 2021 at 16:17

1 Answer 1

Reset to default
2

Here is a study on the effects of standardization:

Process Standardization, Task Variability, and Internal Performance in IT and Business Services Outsourcing

They found that, in non-variable tasks, standardization improved performance quickly after the standard was implemented. In variable tasks, performance degradation was experienced after standardization; however, performance improved thereafter.

I suspect most find standard approaches to work create predictability, reduce variability in outcomes, reduce threats, and increase efficiency. And I bet, while we enjoy those benefits, we lose some degree of innovation, agility, experimentation, and risk-taking. In practice, I have seen standard approaches cause trouble because people do not know how to deviate from the approach when it is necessary. Some personality types are severe rule followers and, once the rule is established, there is no breaking it no matter the need or the case in doing so.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.