Given that coordination and communication swamp all other costs in modern software development it is a pressing area to invest in, especially as your team scales.
I use a framework of a Small Number of Well Known Tools to build shared understanding in our complex systems over time. When we want to do something other than use the Small Number of Well Known Tools (in the small number of well known patterns), that’s a Departure.
I have a long note I want to post on technical decision making and departures.
In the mean time I want to share a short list of questions I’ve been using in various forms for over a decade to engage with The Dreaded Question.
The Dreaded Question goes something like:
“We should use this new technology X, it’s faster, it’s better, it’s more elegant, it’s more actively developed, aren’t you committed to people learning and growing here at company Y, look I whipped up a prototype over the weekend and it’s in production, isn’t this technology amazing, huh, well fuck this fascist totalitarian state, I’m out of here.”
(maybe that wasn’t a question)
If you’ve led technology teams for any period of time, you’ve had this conversation. (or, in rare cases, missed important opportunities to have this conversation)
They aren’t particularly subtle in their bias. They aren’t supposed to be. They also aren’t mean to be a series of boxes to be checked or hoops to be jumped through.
What problem are we trying to solve? (Tech should never be introduced as an end to itself)
How could we solve the problem with our current tech stack? (If the answer is we can’t, then we probably haven’t thought about the problem deeply enough)
Are we clear on what new costs we are taking on with the new technology? (monitoring, training, cognitive load, etc)
What about our current stack makes solving this problem in a cost-effective manner (in terms of money, people or time) difficult?
If this new tech is a replacement for something we currently do, are we committed to moving everything to this new technology in the future? Or are we proliferating multiple solutions to the same problem? (aka “Will this solution kill and eat the solution that it replaces?”)
Who do we know and trust who uses this tech? Have we talked to them about it? What did they say about it? What don’t they like about it? (if they don’t hate it, they haven’t used it in depth yet)
What’s a low risk way to get started?
Have you gotten a mixed discipline group of senior folks together and thrashed out each of the above points? Where is that documented?