I’ve been in my new job for a few months, so I thought it was a good time to reflect a little.
The thing that’s struck me most is that my job spans two worlds, and has a foot in each. One world is the construction industry and the other is IT. This is my first time my job has taken me near the construction industry, and so the contrast between the two worlds has struck me.
Construction, in one form or another, is something that people have been doing for thousands of years. IT is new enough that when I was at college I was lectured by someone who invented part of its foundations. Construction is, by definition, in the physical world where you can’t easily work from home, the risks of injury need to be taken seriously, and you can get sunburned, rained on or really cold at work.
My toolbox – my link to the physical world – is just: a laptop, a headset and fortnightly meetings in our office. The rest I can pretend exists in some magical realm beyond the rainbow, and yet this is an illusion made possible by the hard physical work of people working in data centres, building and running power and comms networks and so on. IT workers sit in their homes or comfy offices and don’t usually need steel-toe-capped boots at work. But at the end of a day, a builder can see the hole they’ve dug or the concrete they’ve poured, while progress in IT often needs more imagination to appreciate.
In fact, this job is where trends I’ve experienced before have continued even further. It serves such an old profession, but we use some of the newest IT tools such as AI. Our customers work in the most physical and (sometimes literally) concrete of fields, but we serve them with the most abstract and ethereal tools I’ve worked with, such as serverless computing in the cloud.
Another difference between the two worlds is to do with risk and change. IT changes occur too quickly for me to keep up with all of them, and it can feel like permanently being on a hamster wheel. We do think about risk (agile software development is a risk-management strategy, after all), but not on the same scale. I don’t have to worry about something I’ve built collapsing and killing people, or polluting rivers, or derailing a train full of passengers. As a result, the construction industry is much more conservative than IT. The stakes are high, and techniques have been shown to work well over a long time, so why change?
The reason is that I hope that we can bring the benefits of IT to construction. IT can automate the boring bits, which is something with a long pedigree. One of the pioneers of IT – Charles Babbage, who lived in the 1800s – was so frustrated by the tedium of some boring maths chores that he wished that they could be done by steam. This was the cutting-edge technology of his day; these days we can use the mobile phones that construction workers already have in their pocket.
IT is the technology of information (it’s easy to hear “IT” and think “computers” but the computers are just a means to an end). IT can help information flow more quickly and helpfully than in the physical world. Once it’s inside a computer, information can easily be summarised, copied, queried and so on. It’s easy to check that thing A equals thing B, to send a bit of information to many people etc.
Information is something where often its value is greater than the sum of its parts. If you have information about the deliveries arriving at a construction site, and you also have information about what you have been billed, when and by whom, you can link the two together and see what your suppliers are actually supplying you with versus what you thought they were going to supply.
One of the things that drew me to the job was the explicit goal of the founders to make the world a better place. Not just allowing construction workers to do the things that people do best by sparing them the tedious stuff where they’re being like a machine. Not only by saving construction companies time and money by giving them a more accurate and up-to-date view of the reality on construction sites. But by helping construction companies build with less waste, and helping them to manage and reduce the CO2 emissions embodied in the thing under construction.
It’s probably not something that springs to mind when you think of climate change, but construction needs to improve just like power generation, transport, manufacturing etc. all need to change. We have only one world and not much time left to keep it in a decent state. Tackling climate change is something where we’re only as strong as the weakest link, and the link I’m working on is construction.
3 thoughts on “IT for green construction – two worlds and one”
You said, “I don’t have to worry about something I’ve built collapsing and killing people, or polluting rivers, or derailing a train full of passengers.”
But don’t forget, the Boeing 777 was grounded after two crashes because of software errors which in part reflect short cuts in the testing regime for the fly-by-wire control system. Always bear in mind who the ultimate customers are, not just who actually uses your software. In the case of civils, there must be a degree of responsibility on everyone’s shoulders for the safety of those who will live or work in the buildings or cross or pass under the bridges that we build.
I gather from your blog that your product is used in the supply chain. Supply chain has been implicated in the Grenfell enquiry. Part of that is on the shoulders of those making the purchasing decisions, and someone will have to answer for that in due course; but where products are safety-critical, can we be certain that the supply chain is completely innocent in this? Are product descriptions truncating or omitting key safety indicators that might at some point have made someone stop and think “Hang on, that product doesn’t match the statutory requirement for that application…”? It ought to be the responsibility of everyone in the chain to have these thoughts in the back of their mind.
I used to test data collection software for one of the utility regulators. The information that companies provided us with went into calculations that ultimately affected customers’ bills. I was mindful that if I got my job wrong, everyone’s bills across the country could be wrong. And we did once fine a company £35 million for falsifying their annual data return (and they remained under investigation by the Serious Fraud Office for a good six months after we levied that fine). Even the most abstract-seeming software application can have real-world knock-on effects. We don’t need to obsess about that, but we do need to keep it in mind.
LikeLiked by 1 person
Thanks for your comment. I don’t think there’s no risk in software, just that there’s on average less risk than in construction. I have worked in previous jobs where there were specific and unusually high risks, and we took appropriate measures to address them. The risk was that we could publish data that contained too much personal information (or too strong a clue about personal info). We had a data processing pipeline to create this data, and the last step scrubbed data that couldn’t be published, and we automated the pipeline to reduce the risk of this step being forgotten. But, in my experience, this was unusual.
Yes, the product is involved in the supply chain (and in the waste disposal chain). Our product wasn’t used in Grenfell, but I think that it could have helped with some of the problem. (Materials that needed certification A were expected, but what was delivered had certification B – we could have checked that.) But this was only a small part of the problem, and there were other problems such as perverse incentives leading to unwanted behaviour and these are problems that need non-software solutions.
And I also worked on billing software for telecoms and billing for many years. As well as performance and scalability, we worried a lot about correctness. Our customers were allowed to operate on condition that they sent out timely and accurate bills. So our software could ultimately lead to our customers losing their licence to operate. Also, money came into our customers only because their customers paid their bills, and that happened only when the bills were calculated and sent out. So if there was a bug holding up the bill run, Very Important People got Very Interested Indeed.
Again, not that there’s no risk, but the distribution of risks in software is (I guess) lower down the scale than it is in software.
Oh yes, I’ve been in a situation in a previous role where problems with a new application – in this case, oversights in the technical specification document – led to cashflow issues because invoices were trapped in limbo between legacy applications. The person who had worked up the spec hadn’t considered that the new features they were advocating would require corresponding changes in the API that sat in the middle of the various cashflow apps. Not a good place to be.
I think the lesson here is that in the software business, risks are harder to spot, less obvious in their impact, and often further downstream than in “real world” enterprises such as construction, manufacturing and transport. Those industries have adopted a health and safety culture (sometimes willingly, sometimes less so); that sort of thinking doesn’t often pop up in the software planning horizon.