…or “How to end dogma-driven design”
Building design professionals are often driven by theories and ideology rather than facts. But whether we’re talking about heat networks or air-tightness, photovoltaics or passive ventilation, design decisions should be based on data, not dogma. It’s time to stop arguing, start measuring and learn from the results.
You hear examples of dogma-driven design almost every time engineers or architects get together to discuss our preferred design strategies. Does low energy retrofit improve occupant health or cause mould and respiratory illness? Which saves more carbon when correctly applied: heat pumps or CHP? Will abundant south facing glazing in new build capture useful heat gains or just cook the occupants?
Here’s an illustration that’s close to home – it might be a little esoteric but bear with me. When designing communal heating systems, engineers debate about what diversity factor to apply in order to calculate peak loads. In other words, engineers must predict what proportion of people on the network are likely to need heat at the same time. Ask any two engineers and their answers might differ by as much as 10 times! It’s a simple number with huge consequences: get it wrong and the system will be oversized, shamefully expensive and wasteful. Yet how do engineers make this hugely important decision? Mainly with their gut. And, as a result, they frequently get it badly wrong.
The solution to dogma-driven design is data. Only by measuring building performance can we be sure that our design strategies have worked. And so the means of measuring and verifying performance must be built into the design itself.
When I was a junior engineer I designed an earth pipe for cooling a visitors’ centre. The CFD analysis was rock solid. The drawings I did were gorgeous! But did it work? I have no idea. Because I didn’t build in any means of checking airflow and temperature through the pipe.
We building designers should behave more like software engineers. When sitting down to write software, it’s best practice to write your tests first. This forces you to ask: what is this thing that I’m building meant to achieve and how will I know if it succeeds? Then, when your code is written, you immediately check it using the test. In other words, first build in the means of quantifying performance, then produce a design that you believe will meet requirements, and finally verify the outcome.
So going back to my example of diversity factors on heat networks, the first thing the engineer should do, even before settling on a diversity factor, is design in heat meters at key points (and make sure there will be a way of getting the data out). This relatively cheap measure will tell the engineer exactly what the real diversity on the site is and whether or not his original guess was wrong. Armed with this knowledge, the design team can improve performance on the current project. And the next project gains the benefit of lessons learned.
Without this knowledge, there’s no way to know if your design worked as well as you hoped. Without a way to measure performance, you’ll stumble onto the next project and ignorantly apply dogma-driven design, repeating the same mistakes. And the building occupants will pay the price.
But even where a project includes the means of measuring performance, it’s no use if there’s no one to collect and analyse the data. Unfortunately on most UK construction projects, the design team are only paid to stick around until detailed design is complete. The heat meters or dataloggers or whatever has been built in to check performance are likely to languish, ignored in a cupboard with no one to read them. It’s essential for the design team’s remit to be extended, at least far enough and long enough to check the design outcomes and learn from them.
Reading these paragraphs, you might think I’m simply repeating the messages of soft landings. And there’s certainly overlap, but here I’m arguing for something much simpler and more fundamental to our jobs as designers. I can sum it up like this:
- Before we make any design decision that may significantly affect building performance, we should first decide how we’re going to measure the outcome and build this into the design.
- After the build is complete, use measured data to evaluate the outcomes. If the client won’t pay you to do this, do it for free.
- Take the lessons from the project and apply them to your next relevant design.
- Return to step 1.
carbon limited 
Spot on apart Casey from the line about engineers making decisions using their gut: they’re not engineers; we disowned them as professionals a few posts back. 😉
Here’s a slight spin:
0) Start a group for those with an interest in engineering heating solutions: the professional engineers who are doing the math and checking their answers. (not the same
3) Share the data with other members of this professional institution as a condition of your membership. You don’t need to share operating data that says how efficient or otherwise your heat network/gas boiler/heat pump is, just the raw end use numbers: the hot water demand was X and the space heat demand was Y on a per-home, per-minute basis.
It’s actually a building performance evaluation / occupant behaviour challenge rather than a heat network challenge per se. It’s just as relevant to pull hot water demand and space heat load from a gas boiler or heat pump fired property as it is to log it for a heat network and I see no harm in working with competing technologies to collect the fundamental datasets that drive all the designs.
Once you’ve got the datasets you can write them up into standardised design codes that any Tom, Dick and Harry can follow to create a reasonable solution. We’re not there yet though; and what we do have is based on legacy building fabric, equipment, and occupancy.
I agree, Marko. There should be a rapidly growing database of real operating data available to engineers. Or, even better, data sets that are publicly available to everyone.
Public is great and arguably ought to be mandatory where it’s the public paying for collection. (we’ll release datasets where HMG pays for the work, even where not mandatory)
I wouldn’t want to see freeloaders taking advantage of datasets collected at private expense without reciprocating though. (same as the open source software community)
Expect resistance from architects and developers though: not everybody will want to see how their buildings *really* perform made public because it’ll rarely be as good as is claimed on paper and is highly sensitive to occupant behaviour. Nobody wants their reputation tarnished because BREDEM results are nonsense or the occupants are profligate. Hot water: fairly safe, because that’s clearly the occupant’s behaviour not the building. Space heat less so.