Best way to explain to someone that software developers need to install tools (mainly build integration), and that end-users don't

Question

I work at a software company where most of the people are afraid to install new tools to increase productivity. They give me excuses like:

• I don't need to install something else.
• I can do this myself.
• etc...many other baseless arguments.

In an ecommerece business, the end-users should not have to install anything, everything should be managed by them from the web, and the developers should be the ones installing things to increase productivity and teamwork i.e.:

• Version Control Systems
• Build Tools (ANT, NANT, Maven, continuous integration, CSS Frameworks)
• Integrated Development Environments
• Frameworks (Unit testing, etc)
• Etc...

How else can I get my point across without sound crass?

Answer 1

I would position every tool in terms of how much time/money/... does the tool save. What does it mean to use it and what does it mean not to use it.

Emphasise the negative impact on their work if not using the tools.

Answer 2

Your point of persuasion depends on your position in the company. If you're the newly installed manager of the programming team, get your budget approved and start implementing.

If you're a team lead, then start by picking whatever's most painful and asking for the resources to resolve for at least your team. 2 or 3 months in, show your boss tangible improvements, let them buy in from that perspective and push down to the other teams. Rinse, repeat with next pain point. It may take you a year or more, but just like with iterative development, so must changes to environment (esp. when you're not in direct charge) must be iterative and just practicing what you preach is most powerful influential force when you excel while the others flounder.

If you're not on version control, that's the most critical to get implemented the soonest.

The order I typically implement is:

1. version control (git, subversion)
2. bug tracking (trac)
3. morning scrum meetings
4. new feature tracking, documenting, and estimating tools (pivotal tracking, mingle)
5. testing frameworks
6. continuous builds

Answer 3

My two pence of advice - if you need to persuade anyone in management or business for use of something new or different, you need to tell them that it result in increased income (due to the benefits like productivity gains or hours of business manual effort saved etc).

But certainly, in today's environment its really sad to hear that the working population or devs in your organisation are not enthusiastic to try and use new tools/tech. You should also try putting your case with your head of technology - I am sure they will take it seriously.

Answer 4

When you're trying to convince management of something, give advantages AND disadvantages. Try to stay objective, and give figures where possible. This will help you convince management (and indeed yourself). It gives management (and your team) confidence if they know you've actually thought something through.

For instance, I worked at a place, and we were looking at improving the speed of the ANT build. It was 8 minutes. I changed it a bit, and it was 3 minutes afterwards. Was it worth it?

We had 8 developers. Lets say they do 3 builds a day.

That is 8 developers * 3 builds per day * 200 days a year = 24000 minutes = about 50 man days.

That is, for a team of 8, if you save them 15 minutes a day, you'll get an extra two man months work from the team each year.

This not only helps you convince people/managers of the worth of what you're doing, but also helps you convince yourself.

P.S. About 6 months previously, we didn't have ANT, and the build was a series of 12 .bat files which had to be run in order. It tooks about 2 hours to correctly build. THAT change was easier to sell to the management.

Answer 5

I'll play the devil's advocate for a minute, and say that sometimes, installing the latest shiniest tool probably isn't the best solution.

Eg:

• when you're just about to release a product, and can't afford to spend time fixing your configuration if something breaks, or just learning to make it work the way it used to.

• when you know your IDE really well, you've configured it perfectly, and it's still doing everything you need. (I'm thinking of die-hard vi and emacs users here)

• when you see your collegues spending more time managing/upgrading/fixing their tools then actually producing results

• when the tools are immature/unstable/unsupported

• ...

That said, there's no excuse for not using version control.

Answer 6

A key point is how well can you rationalize away someone's excuse? If someone says they don't need it, that is correct. However, there may be benefits gained from using the tool but there also has to be guidance, understanding and someone prepared to endure the pain of learning to use the tool. This is where I'd suggest understanding that someone may be afraid of wanting to try something new or not see the benefits from it. Is it so hard to see that someone else may have feelings that are driving what they are saying?

While you may see the argument as baseless, try to see things from their perspective. If they have never done unit tests before, how are they supposed to know why they are good? Same can apply to build tools and other areas of things that others may view as basic if they have had them for years and years.

Answer 7

Seems to me as if you had a lot of Morts in your company. A very sad situation.