Great to have @lgibbs join a recent This Week in Testing convo. Louise brought up the Double Diamond Model and how to apply it to software development and testing – and wrote a blog post off the back of it.
Problems before Tools … supports the idea that tools are designed for a reason so before deciding the use a tool, you need a specific problem which the tool is meant to solve. Without a properly defined problem, there is a chance that the wrong tool may be chosen for the job.
I’m a fan of using divergent and convergent thinking to explore and solidify ideas. And using it twice appears to be an excellent strategy for picking a tool.
Tools are everywhere and are part of our daily life. We talk about them a lot on The Club and rightly so. Take this thread, for example.
We should keep the conversation going about how we select tools. So here’s my question, inspired by Louise’s post:
How do you pick the right tool for the right problem?
I can think back to some times when I’ve been influenced by a team member to try something out just cos the tool was trendy at the time and other people were using it. I cringe at my younger self for that.
I’d love to hear real examples of the decisions you’ve had to make and how you made them. Good, bad and ugly tool decisions. Let it all out on this thread.
I use the results of a combination of factors when doing tool research:
Is it open source?
Is there money being thrown at marketing it? Is it creating hype? This is a negative signal. I’m more suspicious of a tool the bigger the marketing budget is.
Is it chasing hype? E.g. is it touting AI. This is also a negative signal.
Is it popular? E.g. how many stars does it have on github.
Google for “X sucks” or similar to see what the haters have to say about it. Did they miss the point or do they have a point? Is the hate related to my use case? I will do twice as much of this if a tool is trendy. Trendy tools are where paying attention to the hate is most valuable.
Was it built in response to hatred of an existing tool, with a view to fixing its deficiencies. For me this is a strongly positive signal (e.g. docker->podman).
Does it try to limit its scope? I find the best tools do a small amount and do it very, very well, interlocking with other tools that are similarly limited in scope. I will often broaden my search as I scope out the problem and try to find a combination of tools that work well together rather than just one.
If it’s a winner on enough of these points, I will do a spike. If the spike succeeds I will probably expand its scope in my project until it takes over or until I get frustrated and tear it out.
I have similarly been burned by trendy new hot tools. It’s made me instinctively distrustful of anything with a marketing budget attached.
If my coworkers come to me with a “hot new tool everybody is using” I instinctively reach for my gun. If they come to me with “hey, remember [ CRUSHING, OVERWHELMING PAIN ] we had when using X? Y fixes all that” then I’m all ears.
Introducing a new tool and use case and keeping 1. in mind.
Exchanging tools can become a lot of effort. E.g. one in coding/automation.
Try to find vendors/tools which are unlikely to change their business model heavily.
* cough * Postman * cough *
Could you explain that more in detail?
I can imagine different reason for this: open issue tracker, fork-able for individual change, free of charge etc.
And also know arguments against it.
I can imagine different reason for this: open issue tracker, fork-able for individual change, free of charge etc.
One of my friends once went all in on becoming a consultant on an Adobe product which was later dumped - all that investment he made was wasted. I knew of some people who used to be VB6 consultants again, until Microsoft basically ended their career overnight. Support and security fixes all died overnight.
Free of charge is good and open to change is good. I’ve forked projects before and fixed bugs which affected me. It’s incredibly liberating. I’ve also seen really good open source projects resurrected after the original maintainer lost interest.
I’ve also sat at the end of a phone call with a vendor asking for a basic bug to be fixed only to be given the run around. That isn’t so liberating.
Where it really shines is when you achieve a goal by stringing together a series of small, best of breed tools to form a cohesive whole. It’s very common that a combination of open source tools that do one thing well built by passionate maintainers will join together to make something better than you could even pay for. For free.
