When My Team Vetoed A Tool They'd Never Used
The Meeting Where It Happened
I was in a routine refinement session with the team and we were discussing a story. We had a Power BI requirement to filter out some data.
Power Query was listed as one place we could filter along with in the SQL view or even in the DAX code.
The devastatingly simple question was asked: "If we have an unwritten rule that we don't use Power Query, shall we just remove that from the options?"
What This Question Illustrates
An unwritten rule is unhealthy. It's usually a symptom of tribal knowledge, fear or past trauma (e.g. someone had a bad experience with it once).
Tools change, technologies change. Problems are unique and just because it didn't work on a previous issue doesn't mean it's not the right tool for this job.
There is a big difference between a principled decision e.g. "We don't use tool X because in this context it is too expensive or too slow" and a self-limiting arbitrary decision e.g. "We don't use it because we never have in the past"
The unspoken message is "Our collective ignorance is more valuable than the potential of this tool". It's like developing with one hand tied behind your back.
The Real Reason Behind The Self Imposed Ban
The real reason is social and psychological. The team is opting to stay in their comfort zone: the worlds of SQL and DAX. Learning a new tool such as Power Query and understanding it's benefits is seen as a cost, not as an investment.
They also believe that by limiting options, they can make a faster choice. While this is correct, they're sabotaging that decision by removing a perfectly valid option. This could lead to poor quality implementation and future issues arising. They are sacrificing quality for speed.
There is risk aversion at play too. It's easier to say "no" to something unfamiliar than to objectively evaluate a tool's pros and cons. This risk aversion is dressed up as technical wisdom. And since the status quo has that emotional pull, nobody questioned the decision. It was groupthink in action.
The High Cost of Self-Imposed Limitations
The biggest danger is atrophy. The team never learns new approaches. Instead it becomes cookie cutter development: when your toolbox consists of a hammer and a screwdriver, everything looks like a nail or a screw.
It's reminiscent of the fussy toddler who refuses to try new foods. The new food could be the best thing they've ever tasted and yet they shut it down completely and don't even try it.
It risks brute-force solutions. The tool knowledge in the team is not broad enough to solve this new problem. But instead of recognising this and to prevent leaving the comfort zone a convoluted and fragile solution is found that "seems to work".
This can lead to a lack of real understanding of what has been done and how exactly it solves the problem which makes upkeep and maintenance difficult. And the brittle nature of the solution could potentially lead to problems down the line.
A solution with the tool that was dismissed out of hand (Power Query in this example) might be more elegant, more robust and easier to maintain.
Lastly, how would this approach look to open-minded developers who wish to grow their skillset? The signal it sends is that "your desire to learn and improve is not encouraged here". This is how you lose your best, most creative problem-solvers.
The Alternative Culture of Learning And Pragmatism
The best tool for the job is the one that best solves the problem.
In order to conclude which tool is best for a particular problem, we need to have a baseline understanding of the various options available.
A mature team would have considered the pros and cons of the Power Query option. If none of the team was proficient they would have perhaps spiked a small task to understand it better for this use case. This signals that the team doesn't see new tools as "evil" or threats but as opportunities to learn and to add to the team's collective toolbox.
Written Principles > Unwritten Rules
The worlds of tech and data are constantly evolving.
Unwritten rules are a growth limiter. They are irrational, unchallengeable and often have a large blast radius: they tend to reject tooling or technology outright and are not sensitive to the nuance of a given use case. Ears should always prick up whenever somebody rejects something due to "an unwritten rule".
The better approach is to replace unwritten rules with written principles. These principles can then be used to evaluate new tools and make a research-based decision on whether it provides value for a given use case or not. Rather than a reflexive "no" born of tribal lore.
Excellence doesn't come from staying in your comfort zone. It comes from learning to push against the boundary and asking "why not?" rather than "why?".