So you think a new tool will help? Here are some things to remember…

Key Takeaways
- Tools are not always the answer to our challenges.
- Don’t get a tool till you know why you want it.
- Don’t build a tool till you know who it is for.
- Make sure you understand the context for the tool.
- A set of useful questions to ask yourself (in a GitHub repository)

Could better tools help us do a better job? Or is that sometimes an illusion? I’ve been researching the experiences of teams and individuals working on software projects, their challenges, their achievements, and how tools have helped - and hindered - their work. Industry practitioners and experts contributed their stories about successes and challenges to successful tool adoption. I’ll share some of their stories and discuss why tools can hinder as well as help us.

“Built a tool for myself – now everyone is using it and I have a support and maintenance tsunami…” - People building tools forget to ask "Who for?"

“We introduced a new tool to improve communication – but it didn’t help…” People acquiring tools forget to ask "Why is the tool needed?"

“Bought a tool to standardize how we work – and now the teams won’t all use it…” We forget to ask "What are the contexts where the tool will be used?"

I’ll share some lessons on tool design and acquisition, based on the research data and developed into a set of heuristic questions to ask when designing or choosing a new tool.
For example one of the “What context?” questions is “Where?” By asking “Where will the tool be used?” we can start to examine: Where in the technology stack? Where in the organization? Where in the built or natural environment? Where in the world? Or beyond it?