There are probably clear factors involved in identifying when a particular tool or service will fail miserably, and I’d guess one of the big ones is a disjunct between the buyer and the user. Technology — even internally when the developers are in the same room — is still so often seen as that magic bullet that Makes Things Happenable. Developers seem to throw tools and libraries together and Stuff Comes Out. This is true at a very, very small scale. And everyone makes the mistake of assuming that it therefore works at a large scale. Or medium scale. Even the techies.
But tools are complex — especially when they’ve been developed using an approach that has brought together lots of little tools, with not enough holistic thought to join them into one. The complexity kicks in as soon as two clear functions have been produced. At that point, you’re basically trying to do two things at once.
My own general rule is that you can’t get rid of complexity, just move it about. So for instance, Jira moves its complexity into an underlying, massively configurable system that the “simpler” tools and plug-ins sit on top of. Some of that is still complex, because business processes are complex. So you’re then trying to juggle how to use the defaults you’ve acquired, how to apply your own processes to these, which plug-ins you need, *and* how to fiddle with the underlying model (looking at _you_ issue workflows). I guess there are Jira training courses you can pay for…
At home, my approach is upside-down. If I’m getting a new tech for personal reasons, it’s often because I’m interested in what I can do with it — it’s nice having the freedom to tinker without having to keep others informed ;-) But for certain tools and tech, I buy it with the intent of learning something from buying it. I don’t buy a Raspberry Pi because it’s cheap, or small. I buy it because I want to learn how to do things I don’t know how to do.
Maybe it should be the same at work — wise purchasers should see new tools not as a way of save money and _doing away with_ skills, but as a stepping stone to the team learning new approaches — whether it’s technical (like a specific language) or something more generic (like what makes a good metric). A learn-first approach.
