Key ingredients for good tools policy?

Question

A mere sub-standard screwdriver can turn a quick Do-It-Yourself job round the house into an exercise in frustration that makes you feel really exhausted, annoyed and helpless at the same time. This is a feeling that is just too familiar not only to anyone who ever attempted to use a bogus screwdriver but most software professionals who are trying to cope with their everyday tasks using inadequate tools. That is why best craftsmen always know, love and cherish their tools. They are always in pursuit of better equipment.

As a software development manager one has great influence over development tools policy:

• What key ingredients a good policy must include?

• Beyond and above the policy itself what measures need to be taken continuously to keep the tools as "sharp" as possible?

---

Within Wikipedia word "policy" is defined as: "a deliberate plan of action to guide decisions and achieve rational outcome(s)."

In any software development team there is a "tools policy": it can be anywhere on both scales formal-informal, explicit-tacit. It is often a matter of collaboration, budgeting, hiring, maintainability, legality, politics etc. The policy drives the notion of what tools are acceptable, accessible within the organisation, how much actual control developers have over their working enviroment.

Answer 1

I'd say these things are important:

• Tool selection should be under the control of developers, not mandated by management
• Individuals should be allowed to use whatever tools they like, as long as those tools have no effect upon other developers. (For example, developers should be able to use whatever text editors they prefer, and set preferences as they wish.)
• Teams or other groups should be able to select tools that suit their needs. (Tools should not be mandated on a company-wide level.)
• Tools should be re-evaluated as often as appropriate. (In other words, there should never be a decision to commit to using a certain tool "forever.")

Answer 2

I can't understand your premise: "As a software development manager, one has great influence over development tools policy"

Policy, however, has nothing to do with tool use. Tool use has little to do with programmer success or organizational success.

1. The policy says "Eclipse". Yet, the most productive member of the team uses Testpad and Ant. What do you do?

2. The policy says "Eclipse". Yet, the architect does technical spikes with NetBeans, and can't coach developers on how to use Eclipse. What do you do?

3. The policy says "Eclipse". Yet, QA folks have decided that operations cannot use Eclipse or even Ant to do their own builds from SVN checkouts. What do you do?

I think policy isn't really relevant. I think active management and coaching is important. I think that time spent writing, reviewing, approving, and promulgating policy might be a substitute for working one-on-one with developers to maximize their individual productivity.

What is the impact of variant toolsets? Is it negative? If so, precisely how and why?

What is the impact of denying access to tools? What is the impact of requiring the use of a toolset that's demonstrably ineffective for one team member? How can you justify forcing a tool change?

What's the benefit? What are the risks? What's the cost?

Answer 3

In terms of policy, a key factor is your method of selection, implementation and review.

You should clearly define:

• The driver for the introduction of any new tool
• How developers (and others) may contribute to the selection process (by suggesting alternatives and giving you the benefit of their experiences, good and bad)
• How you will trial new tools (and avoid them becoming de-facto standards)
• How you will implement new tools
• When you will review tools and again how developers and others can contribute to that review process

The final item - the tool review process should serve to keep your tools 'sharp'.

Answer 4

There likely needs to be a distinction between single-developer tools (e.g. a text editor) and more organization-wide tools (e.g. issue tracking).

The requirements for developer tools can be more along the lines of output requirements, such as the format or style of the resultant code or documents, etc. These types of policies should be set by developers, as they are the ones working with the output information.

Above that are needs that a whole team, department, or perhaps the organization might need to be standard (or perhaps, equivalent). These are items such as the compiler, build platform, review tools, issue tracking systems, etc. These types of policies should be discussed between a mix of developers and their managers.

I would edge more toward explicit policies, which can be referred to at any time, but that are not set in stone. These policies don't always need to be a minuscule level of detail, but what is sufficient for the task at hand. For example, we may define explicitly and in a reasonable level of detail, the issue tracking workflow and process, and the build plans. We may define very loosely or not at all some aspects of coding style.

Answer 5

A nugget that someone gave to me was this, and this is only relevant if you're at a large company.

You cannot be both the agile startup that uses ruby php java .net f# vb.net C C++ and every toolset under the sun, but also have global reachback and consistent practices across the company.

No one likes change, but if you can bring people into common toolsets (give them all the customisation they want) but choose good tools for the job that will support integration into the organisation and you'll have done your job well. If you have fewer tools and well trained people then what you will get is much better maintenance, greater leverage on your purchasing (giving you more money for better tools :) ) and the ability to induct new programmers significantly easier into the company.

@S.Lott. If developer X is good with a textpad, let him be, but thats for a debug cycle. Once he's happy, copy paste into the real editor and commit to your integrated source control / CI / engineering factory system. If one developer is productive in a language, learning a new tool is simply learning curve. Provided that your solution is mature enough then the transition should be an isolated developer becoming a rockstar developer in your system that everyone will be able to interact with :)

Answer 6

Using the DYI metaphor in the question, I always see people trying to use the best screwdriver in the market to hammer nails into the wall.

The single most important thing is, no matter what the written policy is, to create an environment where people are encouraged to use their mind and not blindly follow policy.

Answer 7

I think there are broadly two types of tool:

• "Personal" tools that have no impact at all on other people in the team (e.g. file differ, hex editor, text editor etc.)
• "Shared" tools where the choice of tool (or one person not using a particular tool) impacts other developers or other parts of the business.

With personal tools, I feel it is very much up to the individual developer. As a manager I don't really mind which diff tool everyone uses, though it is part of my job to recommend a tool for people who don't care.

Shared tools are quite different however. Where the individual choices of developers would interfere with the productivity of the team as a whole, the team (with the support of their manager) should mandate the tool that everyone uses. This category is broader than it might appear at first, for instance:

• Revision control (this is a fairly obvious one, if one person is using CVS and everyone else is using SVN, things are not going to work very well)
• Bug / feature tracking (again fairly obvious, everyone needs to be using the same database)
• IDE (this is less obvious, however if one person is using make files and everyone else is using Xcode, this is likely to make it difficult for developers to support each other)
• Documentation (if one person is using Word documents and everyone else is using the wiki, you lose the benefit of having one, central, consistent, searchable repository for documentation)

Finally I would say that the most important policy as a manager is to have an open mind to new tools, and to coach your team to do the same. Consistency is important, however if something better comes along then it should be evaluated and adopted if it brings a benefit. In the team I work in, we've gone through many tool changes over the years - each change elicited some grumbles and caused short-term pain, however each change did eventually make the lives of everyone in the team easier.

Answer 8

I believe that the only sane tools policy is a meta-policy. As development manager, you will tell your development team the following:

• They can suggest any tool they like for any job.
• Each suggestion must be backed by solid reasoning why this tool is better than the existing tool or method
• Ideally with each newly introduced tool you will measure the relevant parameters to see if they actually improve or not
• After some previously-agreed time the new tool is evaluated and either
  • Introduced more widely
  • Dropped
  • The usage of the tool is modified to a hopefully more effective one and the evaluation period is extended

Relevant reasons that a tool is better than previous methods are the obvious ones such as cost, productivity, effectiveness, interoperability. Some others to consider are:

• Prior in-house knowledge of the tool (saving on training or ineffective implementation)
• Simple preference - your developers may just like one tool over another with no direct reason. If all else is equal, the tool they like better is probably the better choice.
• Upgrade paths. Some tools may lead to greater things. Some may not.