Standardization across an organization: Good or Bad?

Question

Currently I work for an java shop that places a high value on standardization. This includes common things(styles, javadocs, formatting, etc.) on to what I consider slightly more draconian measures(IDE, development OS, toolsets, etc. ).

It is common to hear phrases from more old hands like "it helps when we are all working with the same tools/looking at familiar code". Sometimes I agree and sometimes I feel like there may be a better way.

Also sometimes I encounter older organizational standardization practices that are in direct conflict with more state of the art community practices(most notably accursed bad exception handling practices). I also encounter cases where folks would prefer that code be written in a manner that looks and feels like what has been written there for years (sometimes decades)rather than code that takes advantage of the industry lessons that have been learned in the interim.

I understand there are cost and schedule benefits to be realized through standardization. So the question is how can technology managers realize them without stifling innovation and/or turning off developers onboarding from college or other jobs with affinities for toolsets and techniques that are not the "standard"?

Answer 1

I believe it is good to have standards as long as those standards are allowed to evolve. Usually one works in a team and will not only need to write code but also maintain code written by someone else. If everybody would start using their own way of doing things, with no common approach, then this would become very cumbersome. But, as said, these standards need to be able to evolve. If a certain standard becomes outdated and could be replaced by a new standard (example: replace Struts by Spring MVC) then this must be possible (as long as the short/long term benefits outweighs the costs).

Everything you can do in advance to make a possible future transition easier should be done. Like:

• don't use log4j directly but use slf4j so that moving from log4j to logback (or whatever) is painless.
• don't use hibernate API (annotations/criteria/...) directly but use javax.persistence (annotation/EntityManager, ...) so that moving from Hibernate to Toplink isn't the end of the world

Answer 2

This is the conservative/liberal, status quo/innovation dynamic that permeates all of life. It's bigger than just software.

Standards are great (e.g. Edison and direct current versus Westinghouse and alternating current for electric power generation) - until they stifle all innovation.

Java's changed in the past decade, so making the case that new idioms should be introduced should be an easy argument to win.

Answer 3

I view standards as a set of guidelines to ensure code quality, readability and review ability in order to ensure things get done. When standards become too static they can have the opposite effect:

how can technology managers realize them without stifling innovation [...] affinities for toolsets that are not the "standard"?

Code tends to decay over time. Be it, new hardware, OS's, functionality, new research, best practice changes, tools...something is always creeping in to destroy what has been made. Standards need to remain general and sometimes need updates to combat the effects.

The fact that the company has and enforces standards says something to the quality of the team. I commend them for it. The only thing you need to do is make sure the standards "stay alive". Talk to the other developers about your thoughts to improve the standards. Come in with well thought out plans and ideas. Concentrate on a few topics and cover them thoroughly.

As I've said before, don't take your ideas personally. They may not be implemented for one reason or another which may be out of your control. You can ask and discover. The important thing is to be an active part of the process and show the team you care about the quality of the code.

Answer 4

Standards should make development easier in the long run, not harder.

If a code commenting format slows everyone down, and the comments are rarely read by anyone anyway, that may be a place where you can cut down on rigorous rules. Of course, a broader standard might be in place, such as "for major classes and methods, the comments should contain a brief description". This is reasonable and helpful, whereas saying, "Every custom class and method needs to have a summary, paramter descriptions, and a description of how it works". Helper classes/methods often do not need this sort of detail.

I happened to have an experience where a standard would have been helpful. Some programmers where I work were still using VS 2008 while most of us upgraded to VS 2010. I know a lot of people say the IDE should be the developer's choice, but we were getting all sorts of errors related to the older IDEs trying to edit projects created in 2010. Not to mention, when I send these developers some dll, I am using .net 4.0, where they are still on 3.5. Sure, I was not using any 4.0 features so I could change the framework profile, but that would be a huge pain if I had been.

Answer 5

I don't think there's a right answer here - and I think the ideal answer varies from company to company. I think that a company does have to evolve or die - if it can't keep pace to make use of new best practices, then it's at risk for passing the sweet spot were consistency trumps better ways of doing things - that's bad for the products and bad for the company.

I think the trick is finding and agreeing on a place to start introducing innovation. Everyone would agree that re-architecting the entire code base immediately before a major release is bad news. So where's a good point? And how can change be introduced in the flow of the work so that changes can be tried, vetted and then fed through the company's products. I'm assuming your company is big enough that this consistency is a major win because you have enough projects and developers that change is hard due to size.

In that case, I think the best way to intiate change is:

• get corporate level buy in - make it known across the organization that each product/release has a stake in advancing the state of technology and best practices within the company, as well as a stake in being consistent. Get some sort of agreement on how much innovation is acceptable in a new release. "none" should never be the right answer.
• introduce change in low risk ways - research projects, HLD phases, isolated components - places were a significant technical change can be vetted in a small scale before percolating to the large scale.
• Find a review community/agent for change - if the changes work in the small scale, find a way to make the change the new state of affairs. In the process, your company is going to need heuristics for when to update for the change, vs. when to use the "ain't broke don't fix it" approach.

Answer 6

The cultural view of the standardization is something that is missing from within the question. The big benefit from standardizing is that some things can be simplified and streamlined though it is worth noting that moderation is also important here. For example should all code written by done in the same IDE regardless of language? Should all changes go through a dozen approvals even if it is an emergency change to get a production machine back up that may be costing the company lots of money for each minute that it is down? There can be some exceptions for where doing things outside the rules makes sense and there can be times where sticking to the rules may be a good course of action.

In so much as there is almost always likely to be a better way to do something, what are those trade-offs to do that and how sure is this to be acceptable are the follow-up questions along with how big is the company, how mature are the processes and what kind of people are there creating the culture that may stimulate people to think outside the box or may try to get people to be drones.