Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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


migration rejected from Jun 22 '15 at 1:40

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by enderland, durron597, GlenH7, Snowman, MichaelT Jun 22 '15 at 1:40

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

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.


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.

I believe the IDE should be the developers choice, but that if they choose to buck an existing standard(in your case choosing not to upgrade to 2010) that any change overhead be incurred by them. I ran into something similiar(though with less headache because of the nature of java vs .net) where I preferred intellij over eclipse. So I took it upon myself to make sure my use of intellij didn't impact my eclipse teammates(used eclipse formatters, etc.). However some developers still took an ill shine to to fact that I wasn't using the company mandated IDE. – nsfyn55 Apr 18 '11 at 18:14
Unfortunately, standards become ossified. For example, "VS2008 is the standard, and nobody can upgrade to VS2010 until we have the budget and time to upgrade everything and retrain everyone." This is why the company I work for is still transitioning from Windows XP to Windows 7 (scheduled to be complete this year). – Alan Shutko Jun 20 '15 at 21:33
@AlanShutko: If that isn't a case of a blessing in disguise: They won't ever try windows 8, though they might hopefully get on windows 10. – Deduplicator Jun 20 '15 at 22:26

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.

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.


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