Buildings vs Bugs

I’m in a fairly unique position in writing this article in that I work for a software company that also happen to produce energy optimisation technology for buildings. Maybe it’s from this perspective that I’ve connected the dots (in my own mind at least!) and identified some common parallels that exist between the Software Development and Building Performance industry sectors. As a general overview that’s the main theme of this article – a short exploration into what Software Development and Building Performance management have in common, and to some extent where they differ.

As a starting point we could take the following description of Software Development as our baseline definition:

“Software Development refers to a set of computer science activities dedicated to the process of creating, designing, deploying ang supporting software. Software itself is the set of instructions or programs that tell the computer what to do”.

Now with a little creative license let’s replay the above definition with a Building Services hat on:

“Building Optimisation refers to a set of building science activities dedicated to the process of creating, designing, developing and managing buildings. Building Controls are the set of instructions or programs that tell the Building Systems what to do”.

And there we have our first parallel. Using a bit of simple word play it seems on the face of it that Software Development and Building Optimisation may not be that different after all. So let’s explore a bit further and see what other parallels can be drawn.

Well-integrated Smart Building and Control/Automation systems can lead to reduced energy consumption and improved operational efficiency, just like well-designed and fully integrated software components contribute to a streamlined software application. So significant parallels can be made between the integration of various HVAC systems and sub-systems within a building vs the integration of components and sub-modules within a software development environment.

There is also need for adaptability in both realms. A building's automation system should adapt to changing environmental conditions and seasons. In a similar capacity agile software development methodologies emphasise the need for adaptability, the capacity to adjust to new conditions and new demands as they arise. Flexibility in both contexts contributes to better overall performance and responsiveness, be it an HVAC system ramping up or down to user conditions or a software development cycle changing direction based on user feedback.

The concept of ‘agile methods’ is a whole topic in it’s own right with multiple themes and sub-themes that could easily be written about at length in a dedicated article. Headline themes like SCRUM, KANBAN and Extreme Programming (XP) all come to mind and we could easily go off on tangents in starting to explore any one of these areas individually. So for purposes of this article I thought I’d simply raise the theme of ‘Dual-Track’ agile to support the purpose of the analysis piece.

Dual-Track Agile (a common style of modern software development) can be described as follows:

“Dual-track agile is an agile methodology that contains two separate tracks. There’s the “Discovery” track and the “Delivery” track. The Discovery track focuses on producing, testing and validating software product ideas. The “Delivery” track works on turning those ideas into an actual software product.”

Casting our minds back once again to the Building Optimisation industry it got me thinking. Could a ‘Dual-Track’ approach to Building and Facility Management exist and if it did what would it look like? What would the Discovery track of an active Energy/FM process look like and how would it differ from the Delivery track?

The following diagram provides a nice visualisation of how a ‘Dual-Track’ Energy/FM approach might work:

In keeping with the Dual-Track definition the Discovery stage would involve some degree of innovation. It would mean pushing the standard accepted boundaries and conventional norms in pursuit of efficiency and energy excellence. It would involve creative thinking, introducing new ideas through an inquisitive lens, considering new and emerging technologies and being open to the opportunities that these evolving technologies may represent.

The Delivery track however would be more business critical. It would involve keeping the Building and Facility running day-to-day, whilst also being open to the outcomes and findings from the Discovery track. A successful Dual-Track Energy/FM process would allow for the best-in-class initiatives to breakthrough from the Discovery track and take their place as fully incorporated solutions within the Delivery track. Running in tandem this would become a continuous cycle of Testing, Implementing, Commissioning followed by Measurement & Verification (M&V).

From my own experience at least this is often far from the case in the Energy/FM world. It’s more often a Single-Track and short-sighted reactive approach that ‘just happens’ in comparison to the more strategically planned ‘Dual-Track’ methodologies that exist within the Software Development world. On this basis I believe that the Energy/FM industry could learn a lot from further exploration of Agile Software Methods as a whole. Again, possibly even the subject of a future blog.

To return focus somewhat there are some remaining common themes worthy of mention in this article at least.

The role of data in both Energy/FM and Software Development environments is king. Data-driven decision making is crucial for optimising energy consumption in buildings and similar parallels exist with the use of data analytics in software development for informed decision-making (counting user clicks for example).

The concept of User Experience exists in both building environments and software applications. In actual fact they are closely aligned. Sick building syndrome is not dissimilar to a bad product experience in the software realm, both can create bad headaches for the user! A focus on end-user needs is essential in both contexts and contributes to perceived satisfaction and overall success.

The importance of Continuous Improvement and iteration cycles (e.g. annual) in both Facility Management and Software Development is another key theme. Feedback loops and iterative processes further contribute to enhanced performance and user satisfaction.

This brief comparison so far on some of the key themes between Building Optimisation and Software Development may also raise the question of is enough being done to develop cross-industry collaboration and knowledge sharing between Energy & Facility Management professionals and Software Developers?

The potential benefits of professionals from both fields learning from each other's experiences and best practices is clear and yet there is an obvious lack of consistent terminology across both sectors.

As an example:

• In Software Development we have Bugs and De-Bugging.
• In the Building Sector we have Snagging and Commissioning.

De-Bugging and Commissioning are not at all dissimilar concepts and yet they seem worlds apart.

The issue of different terminology used in the two industries is clear to see when we stop to consider with a little creative thinking. So could a common set of terms be proposed that somehow help to ‘bridge-the-gap’ and facilitate better all-round communication?

As a final thought on the overall article theme it leaves we wondering how many Software Developers are sitting day-to-day world-wide in an office space within a building somewhere in a city?

Chances are that the very office space they are sitting in is controlled by an HVAC system that is itself controlled by a Control System, that is subsequently controlled by a program. Too hot? Too cold? Too stuffy? Chances are that it’s effectively a software ‘bug’ and the system simply needs some ‘de-bugging’ (or re-programmed and re-commissioned in MEP terminology!).

It reminds me somewhat of the movie Tron in which the Programmers are actually within the Program itself! The modern Smart Buildings of today are rapidly evolving into systems of ever increasing complexity. Their programming can have such complexity and sophistication that we can often have trouble understanding their makeup, with mysterious entities often emerging seasonally within the system.

But either way these are the systems that surround us everyday in our modern world. We work in them. We breath in them. We eat in them. We sleep in them. We live in them!

So for a Tron programmer looking to access the CPU or for an Energy Manager looking to further access their Smart Building, there is consistency in the final message:

“In there is a new world! In there is our future! In there is our destiny!”