I’ve never liked this best-tool-for-the-job mental model with software engineering. A given project has multiple needs, and unlike more physical tools there is a very high marginal cost for each incremental tool you use. So there is a huge balance between many well suited tools or a few but more generalized, less fit tools. This isn’t to say there’s an obvious place where to strike the balance, but the “best tool for the job” metaphor undermines recognizing it, and I’ve found this balance to be at the core of good tool picking for a given project.
>> I’ve never liked this best-tool-for-the-job mental model with software engineering.
I don't either. As photographers say, the best camera is the one you have with you. Same thing, the best tool for the software job is the one you already have and everyone knows how to use. Why anyone would want to introduce these high-end fads to an organization without proper reasoning is beyond me.
That’s definitely part of it. Another part is just the various multipliers you get from having a small number of tools. Team mastery, more mobility of personnel (no/low ramp up times), unexpected opportunities for re-use, high quality onboarding due to narrow scope, etc.
Thank you for calling out BTftJ as a mental model. Recognizing the very idea of mental models is a huge step forward. Arguably, it could be used as a metric for how advanced an organization (or even society) has become.
I think the metaphor is more apt than you’re giving it credit for. You just don’t have enough experience with the trade offs involved with “the best tphysical ool for the job”. :)
I also dislike the BTftJ (best tool for the job) cliche.
Best according to who?
Based on what priorities?
Relative to what other options?
Based on what kind of experience and expertise with the various options?
My takeaway: BTftJ must only be a starting point for dialog and discussion. Shortly therafter, it is time to get real about each of our experience and biases. Otherwise, BTftJ is a only a thin veneer.
