Do you work for a group or organization where everything is standardized? Do you always work with fixed set of tools and utilities? Do you always have a template for every kind of documentation you write? Or are you part of a team with "Get the work done I don't care how" mentality? What should be the approach of a group? Should the developers be allowed to pick and choose the tools they use?

Many IT organizations (or at least groups within the organization) face this question. It applies to a bunch of tools: archiving tools, text editors, FTP clients, UML tools, Java IDEs, Unix emulators, xml editors and validators, html editors and more. It also applies to documentation templates: meeting minutes template, architecture document or other deliverables template, JSP pages templates, status report templates and more. Between the projects, standardization also applies to frameworks (especially in large organizations where teams work in isolation): struts or JSF, Hibernate or Entity beans or JDO, EJBs or POJOs or Spring/Hibernate, log4j or commons logging or Java logging APIs and more. Here are the advantages of standardizing:

• When something is a standard, it is easy to document, package and distribute
• Hopefully, the standard entities have been evaluated for organizational needs and are likely to create fewer hardware and other compatibility issues preventing later surprises during the project
• Standard tools can be legally licensed, which prevents developers from downloading unlicensed copies making the organization safer against lawsuits etc.
• Standard tools also make deliverables more distributable and compatible across the project. A classic example is a UML plugin for eclipse. If developers use different plugins, the only way to share UML diagrams is to convert them to images
• When standard tools, utilities and frameworks are used, it is easy to troubleshoot them, find in house talents or share the knowledge
• Standard templates and procedures make the deliverables consistent and easy to read and understand
• Templates for JSP and Java code etc. make the code consistent and up to some extent can reduce the repeat work between multiple classes

While standardization is a good practice, it sometimes also makes sense to have some freedom. Freedom has the following advantages:

• Developers don't have to learn a new tool or utility, they can download the one they are familiar with and be effective right away
• Developers tend to be emotional about their choice of tools and utilities, it's more fun and hence more productive to be able to use tools and utilities they are most comfortable with
• Usually, the free tools are lightweight and typically open source and cost nothing or very little
• Standards don't always take into account every possible situation on a project. Consequently teams end up designing new standards or force fitting the solution to an existing standard. A classic example is software development methodology. Some organizations standardize on Rational Unified Process (RUP), which is geared towards custom software development, when these organizations undertake an integration project, they either force fit RUP without appropriately customizing it or end up inventing new methodology (means more time and risk of failure)
• If the organizational IT needs are complex (e.g. IT at banks and telecoms), there are many situations when deviating from standards makes business sense. This exception list keeps getting bigger and standards don't mean much down the road

So how do you select? How do you know go about standardizing anything? How do you make sure that the standards are actually helpful and not yet another initiative that requires capital, men power and maintenance without actually delivering the results? I will discuss this some other time.