The hidden cost of software development tools or "if we have so many tools, why aren't we more productive?"
The obvious: tools have a license cost.
Not so obvious: The average/below average guys love evaluating new tools and adding them to the process (they seem to feel like they are accomplishing something.)
The smartest developers don't usually like new tools.
(they tend to build their own using scripting/GREP/LEX/YACC/SED/AWK/PowerShell/Bash/Pipes/Notepad/SQL/Black Magic)
Managers often love tools because they live in la la land where software is just a manufacturing process (not a creative thinking / invention process).
Thus, if you are digging a big hole, you need a big shovel. Digging a foundation for a skyscaper, you need a steam shovel (a bigger shovel).
Tools have a learning curve, a risk, a burden and slow you down before they speed you up.
Too many tools can KILL a project.
Microsoft Project is not a tool - it is a wormhole into an alternative universe 
Analogy: if you were a carpenter and worked building houses, how many tools would you have in your tool box? In your pickup truck?
You'd limit it to the tools that you could carry.
You limit it to the tools that worked well and didn't break.
You throw out old/broken/unneeded/obsolete tools occasionally.
You balance the time needed to learn to use a laser guided robonailer and the productivity you'd get back AND the risk of burning a hole thru your foot with the laser.
You wouldn't spend days in the store looking at tools.
You ask other carpenters what they used.
You'd watch other carpenters and the tools they used.
(note: inference by analogy is dangerous but useful in this case.)
You need to think that way with the tools you introduce to your SDLC.
Answer these questions:
- Costs - initial, long term, getting OFF the tool
- Learning curve?
- What tools do I get rid of?
- Real benefits of the tool (not what the vendor says?)
- Risks of using this tool?
- Cost of evaluating the tool?
- What if I just use nothing?
- Vendor longevity - are they going to be out of business or absorbed by somebody - see: Java and Oracle
- Will the team actually use the tool?
Good rule of thumb: Let the developer decided what tools they want to use. Don't force tools on them.
I once did a eval on a agile backlog/features management tool.
We had Rally, Mingle, Jira/Greenhopper and a few others.
Rally seemed the most mature.
Mingle the slickest looking.
Jira the most ugly.
Developers tried each and chose Jira.
It worked the best for their workflow (and looked the worst).
They adopted it and used it.
Bonus: its licensing was also the cheapest.
We liked Greenhopper, the developers didn't - thought it was useless cutesiness.
It didn't get used.
Important to note: it also supported customization and the reporting needed by management.
We coupled it with old fashion whiteboards (low learning curve, robust, scalable, low TCO) and daily scrums.
Had the managers just made the decision we'd likely have chosen Mingle (coolest looking and most expensive, yet powerful.)
They selected and they used it, faithfully.
Comments