After building several automation tools for building performance analysis, I’ve noticed a consistent pattern: the tools that automate the most are often the least adopted.
The Problem
Engineers are attracted to automation promises. Who wouldn’t want to reduce repetitive work from days to hours? But when I look at actual usage data, the correlation between “degree of automation” and “frequency of use” is surprisingly weak—sometimes even negative.
What’s Really Happening
The issue is that full automation removes the engineer from the loop entirely. This creates several problems:
1. Trust deficit: Engineers can’t validate what they can’t see. Black-box tools require complete faith in the implementation.
2. Learning friction: Automated tools that “just work” provide no opportunity to build intuition about the underlying phenomena.
3. Inflexibility: Real projects have edge cases. Fully automated tools either fail on edge cases or become bloated with configuration options.
A Better Approach
The tools that actually get used tend to automate the tedious parts while keeping humans in control of the critical decisions:
– Automate data extraction and formatting
– Automate running repetitive calculations
– Automate visualisation and reporting
– Leave decision-making, validation, and interpretation to the user
Example
In my thermal bridge analysis tool, I initially automated the entire workflow from geometry to results. Usage was minimal. After rebuilding it to provide automated geometry extraction but requiring user validation at each step, adoption increased dramatically. The “friction” I removed turned out to be valuable checkpoints where engineers built confidence in the results.
Takeaway
Good automation should make experts more efficient, not replace their judgment. The goal is to remove tedious work while preserving the critical thinking that makes someone an expert in the first place.