Intro: You are listening to the Digital Engineer. In this podcast, we bridge the gap between our work as engineers and the digital world. In this three-part series, we update you on housing challenges and how digital technology can help.

Pieter-Bas: Nice of you to listen to this podcast. My name is Pieter-Bas de Visser and in this series of three I talk to three specialists who each work on projects related to housing. Today I talk to Rony Nedkov. He works at Witteveen+Bos as a GIS specialist and has combined it with software engineering. Rony, nice to have you here.

Rony: Thank you very much.

Pieter-Bas: Can you tell us a bit about your background?

Rony: I am Rony. I was trained as a GIS specialist and in my career I have actually combined GIS specialism with software engineering.

Pieter-Bas: Okay, and since when have you been working at Witteveen+Bos?

Rony: Now two years and six months. August 2020 I believe.

Pieter-Bas: Okay so started in corona time?

Rony: Started in corona time indeed.

Pieter-Bas: Handy if you're a bit digitally savvy then.

Rony: Exactly.

Pieter-Bas: And your role within Witteveen+Bos?

Rony: I'm in a team, projects and IT, so I'm involved in digitising calculation processes and turning them into tools that can be used by external or internal clients. So actually unlocking the complicated calculation methods in a simple way or unlocking the complexity of calculation easily for an end user.

Pieter-Bas: Okay, and so what are projects you are working on, for example?

Rony: A good example is the nitrogen dashboard we are going to talk about. There are quite a few work processes behind it to arrive at certain results that are not directly useful to the client and also the results of the calculations are not ready to be interpreted. We then translate them into a goal that makes it clear to the client: what should we do with these results?

Pieter-Bas: Visualising as well?

Rony: Yes, visualising, enriching with other data.

Pieter-Bas: Okay you have developed a nitrogen dashboard with colleagues. Can you tell a bit more about that?

Rony: Yes, we developed the nitrogen dashboard together with the air quality group. It was a request from the municipality of The Hague and they actually wanted to create nitrogen space for housing development. That actually means you have to reduce nitrogen in your own area, because The Hague is sandwiched between two Natura2000 areas, so basically everything they do that directly affects the Natura2000 areas. That is no longer possible now, otherwise it emits a lot, and they had a number of ideas of: these are measures we can apply to reduce nitrogen, but they were not so sure which ones were most effective in the context of political support, concrete savings. The nitrogen dashboard maps out all those measures and also offers the possibility of creating scenarios by applying certain measures partially: 100%, 20%, to get some insight into which combination of measures has the most effect.

Pieter-Bas: Talking about the measures that go into that nitrogen dashboard, can you give examples of them?

Rony: Yes definitely, it's very region-specific, but you have to think about... a classic example is the supply of shops. That is now done with diesel trucks. From the government, from policymakers, you can then make a demand: we want the supply chain to be one hundred percent electric, because then there will be no more emissions from large trucks, among other things. You might ask, is that realistic? Because then entrepreneurs will have to invest a lot in new cars all at once. In that dashboard, you could at some point say: supply, our goal is to electrify 10% of that. Maybe you can do something with the traffic intensity or the reason why we have to drive 100 on the motorway now, is to reduce those emissions. You can apply those kinds of measures in the city as well.

Pieter-Bas: Because you actually visualise the effects of the measures? How should I picture that visualisation?

Rony: It is a 2D map and the Natura2000 areas in the Netherlands are divided into hexagons of I think 1 hectare and within such a hexagon...

Pieter-Bas: Those are the pixels so to speak?

Rony: Yes, kind of like planes and within such a plane it is determined which types of habitat types occur there. For example, which plant species, and for each plant species we then know: hey, this plant can handle so much nitrogen if you deposit more nitrogen, yes it will die or it will be overgrown by the other plants. The nitrogen dashboard therefore shows for each hexagon in the Natura2000 area, how much deposition there is or how much we can save. And so if you get over that KWD, the critical deposition value as it's called, if you're above it then the ecologists start looking at it like: okay is it really that bad, and we know it's over it, but maybe the composition of such a habitat types with others can make sure that maybe it's solved as well. And we get above that KDW, that critical deposition value, but in this case it's not necessarily bad for the plant. The ecological assessment then is.

Pieter-Bas: Do you then also get a kind of spot map? Of these are the high risk areas and here you don't have so many problems.

Rony: Yes high-risk areas, yes in fact that's what you see. You just see spots. We also visualise per Natura2000 area what the maximum or minimum deposition is and that's all decision information for civil servants, for ecologists who can make choices based on that what they will or will not do.

Pieter-Bas: How should I picture it? I can turn knobs on the dashboard. You mentioned the example of freight traffic should become electric or 10% of it. Do I then immediately have my visualisation or does that have to go through a whole calculation first and then a week later I can see what the effect is?

Rony: That's an interesting question. The idea is that you start with an empty map and then you can so add the measure you defined beforehand and per measure you have all sliders. So for example, if you talk about electrification, you can slide the slider to 10% and then you can see right away on the map, directly without calculating, what the result is. Now I should add that the nitrogen calculations are done with the RIVM calculation model and, depending on how many users and how complex your project is, it always takes a certain amount of time to calculate. Sometimes this is 2 to 3 minutes, sometimes 30 seconds, but for very large projects it can easily take a couple of hours. And there are even extreme cases of a few days but then the whole of the Netherlands is probably doing nitrogen calculations.

Pieter-Bas: Because you are live in connection with a RIVM server? Or how should I picture that?

Rony: With the nitrogen dashboard, not yet, but it can be done. They have an API you can link to and then you can send your model what you've created for your nitrogen emissions to them. Then they calculate it and you get the results back. So the nitrogen dashboard doesn't do live calculations, so all those measures and scenarios are calculated in advance. That's a piece of scalability you're talking about. Ideally, you would want to calculate immediately and draw everything in immediately and get to the best result. With the current way of working, that's not realistic.

And what I very much see with these kinds of tools, especially with engineering firms in general, is that we are very good with the technology, very good with the substantive knowledge, but taking the customer with us and thinking along with the customer of "yes, but what does that mean for the customer?", is something we are less good at. So in this case, if you would like to make this live, you have to think: well, the calculation will soon take three hours. That customer is not going to sit behind his laptop for three hours waiting for it to be ready, so you have to come up with something for that and that has nothing to do with content at all. In a manner of speaking, this could just be an e-mail that he can close his application and then in a while he gets an e-mail saying: hey your calculations are done, the results are ready in an application. You can get on with your project again.

Pieter-Bas: So also a piece of user experience? Piece of user experience, as we also call it with a buzzword, to guide those users in using the tool as well as possible.

Rony: Yes exactly and to make that tool in such a way that that user understands it, that it fits his work process. That is also a very interesting area. So because you have that question of your computational analysis, it becomes technically very challenging again. As a developer, I don't want to wait until the analysis is ready to manually cram that data into the database. You then have to set up all kinds of things to be able to process the data analysis that comes back from RIVM into a format that you use in your dashboard and to present it. And those are the technical challenges. That's what I like about this discipline within Witteveen+Bos. Both at the front end you have to think carefully about who the client is and what you want to do, and then comes the technical challenge arising from those indirect client wishes.

Pieter-Bas: So you really design a product for a target group and for that you have to recognise all the requirements, but also how such a tool should eventually be used.

Rony: And there is also a lot of variation within that target group. Some larger municipalities have larger budgets and often employ all kinds of specialists, both IT and nitrogen people, but smaller municipalities such as, for example, the municipality of Rheden may have fewer specialists, but the tool must also be usable for them.

Pieter-Bas: We noticed in the beginning of developing these kinds of tools and let's say, 6/7 years ago, particularly on the client side, Internet Explorer and the like was still used as a browser. There, you can still have made just as nice a tool and completely thought it out. But yes, if the end user later uses a different type of browser that you haven't really taken into account, your whole tool is worthless.

Rony: No, that's right, and that's why I think that when we go to the customer, traditionally the specialists always go to the customer, because they understand the content business. But we are now in a period where you have to have someone along who understands that piece of IT. That if the customer says: hey, I'd like a web application, that someone sits next to them and knows what questions to ask. Like "what are you guys using?" "What do you guys already have in place?" Before offering anything. Because very often municipalities also have technology already in place, don't they? They already have software packages and then it might be much easier for us, but also for them and from a sustainability perspective to link to things that already exist. Instead of starting from scratch every time and building everything again.

Pieter-Bas: Well there is a lot to do about nitrogen, especially recently. Do you also notice that there is an interpretation of figures and such and what kind of models are you using? That there is a lot of focus on that to make it all as reliable and traceable as possible?

Rony: In itself, yes. The calculation model used throughout the Netherlands is the RIVM calculation model. That has been in the news a lot.

Pieter-Bas: Do you use it?

Rony: Yes, we are obliged to handle that. We can't change that much. We have no influence on that, but what we do have influence on is, what do we put in? Because such a nitrogen calculation is actually a modelling of, well, if you're talking about housing construction there will be a crane, there will be an excavator, there will be a truck to remove the sand, and they all emit nitrogen. And what happens in those calculations is: you put that equipment you need into the model and that model calculates that and then returns results. And that interpretation of those results, that's the challenge we're trying to develop something for, so that municipalities, provinces or other clients have a basis for taking decisions on decision-making. And to automate that process as much as possible and that at least at the push of a button, so to speak, that you have results right away and you can move on.

Pieter-Bas: Yes and could this dashboard also help with agriculture, for example? That is now a huge thing with farms to make calculations insightful with that?

Rony: Yes in essence, because what we do is the outcome that comes out of the calculation model, whether you put something in it for housing or for farmers, the outcome is always the same and I mean, so to speak, the values that come out. That differs per project, of course, so in principle we can use that.

Pieter-Bas: Okay and what are the future plans for the nitrogen dashboard? What are the recent developments? What do you guys want to move forward with?

Rony: Well, when we had published the nitrogen dashboard and put it online, the municipality was very happy with it, because they could finally compare the measures in a somewhat interactive way and judge them, whereas before it was always about reports. This is still done via reports, by the way, but all that information is just a bit easier to interpret and faster than reading a report.  Only then the question arose very quickly of: hey, it's great that we have these measures, but we would actually like to have something to be able to do the calculations ourselves, like: we want to build houses here and calculate them ourselves without the intervention of a specialist. Only, you have to remember that performing a nitrogen calculation, that is a specialism. Modelling nitrogen emissions requires experience. Not just anyone can do that. So actually the underlying question is of taking away the complexity of the input and giving the municipality a tool to quickly...

Pieter-Bas: That it really becomes stand alone, so to speak.

Rony: Yes

Pieter-Bas: And do you see that ever happening, because you indicate a specialist is needed right now.

Rony: Ultimately, these nitrogen calculations are made because, first of all, you have to demonstrate that no additional nitrogen deposition occurs in Natura 2000 areas. And the moment it does, you have to take a completely different route, because you have to demonstrate in your permit: I am or am not doing something with nature and these are measures. And now, because building houses until recently, you didn't really have to do nitrogen calculations for that. But now you have to. You see that's actually the question: you can't build anything now without nitrogen calculations to show that you... That's a lot of work for the specialists as well. Actually, there are not enough people for that, so if you can automate that, the easy calculations....

Pieter-Bas: That is also your wish?

Rony: Yes, for nitrogen calculators, the air quality people, of course, that's also nice if you can automate some of their work.

Pieter-Bas: And is this nitrogen dashboard going to help us solve the housing challenge or is it part of that?

Rony: No I don't think so. If you include all topics, nitrogen is perhaps a very small part of the whole. Ideally, of course, we would like to have a dashboard in which all aspects involved in building housing are visualised at once: climate, biodiversity, those are also changing all the time. I think we need to start thinking more towards integral tools and solution and that is a very complex issue. Which I don't think anyone has the answer yet to how exactly that should go, and will develop.

Pieter-Bas: Enough challenge for the future. So this is what you do within Witteveen+Bos. And how did you actually end up here?

Rony: Well precisely because of these kinds of issues like nitrogen, which have quite a social impact. I found those quite interesting. If you can actually contribute something to society with your programming skills, with your technical skills. And I also really liked that during the development of the nitrogen dashboard. Then there were all kinds of debates, both at the municipality and the national government. At a certain point, choices are made or statements are made that have a direct impact on what you are building, so it can just happen that you are working on something and then a debate is announced and you kind of wait and see: okay, how we proceed now depends on what is discussed in a debate. And then you suddenly have a different idea or a different vision, or you have to take a different path. And they are also often quite complex problems. It's not like: look, programming a webshop for a Gamma, it's cool what you can do with it, but I don't find it very interesting. It is quite predictable and there are a lot of techniques for it, and with every assignment you have to search a bit: yes, there is a problem, but the solution is not actually there yet. You have to work with the customer to find out what we actually want. And that really appealed to me. I once started working at another engineering firm as a software engineer. They just had a large software package they were developing and that was cool, but I actually wanted to develop more separate small things, be more in that innovation area of software engineering.

Pieter-Bas: And, well, a bit of a cliché question, but what do you like most about your work within Witteveen+Bos?

Rony: Working with the different disciplines, with ecologists with people who understand dykes. We actually all speak a different language. If I start explaining IT in technical terms to an ecologist, he can't understand it at all, so to speak. Bridging that communication gap is something I find very interesting and at a certain point, when you work together for a long time, you see that you understand each other better and better and you also learn a lot from others. I sometimes walk down the street and I see things, or in the woods and I think: I had a conversation with the ecologist the other day and what to me used to be just a tree, I now see completely different things. You just learn a lot from each other. I also have friends who are software engineers or do something with programming who don't work at an engineering firm, but at... how shall I put it, a hardcore IT company? Yes, and what you see is that those people who, I have the idea, there are very much more concerned with the technology: what librarys are there and what are the latest developments of the librarys? Those are a little less concerned with customer demand. The people who work with us from software engineering are also quite interested in the subject itself...

Pieter-Bas: What do you put into it?

Rony: Why are we all doing it anyway? They don't sit there to build for the sake of building. They sit there to build something that contributes to society, which shows you that engineering is not always at the forefront then.

Pieter-Bas: Do you think that is also Witteveen+Bos's strength? That it is a combination of both? And that a hardcore IT company could not develop these kinds of tools without consulting those specialists?

Rony: Yes anyway. Look, I can come up with lots of things to build, but what I always notice is that I need a specialist who has the context. Domain knowledge. And who then also sees value in such a tool and which parts are still really important there. And if you work together a bit longer, you get a feeling for it and you complement each other very well. Because a specialist is less aware of the possibilities of IT and may have a certain idea about it, but that idea may be very distorted. So, as a very simple example, something that a specialist doesn't even ask for, because he or she has the idea that it will take a lot of development time, I can say: I have a basis in three hours' time and then you make that and in one go you are many steps further together, whereas if you were to work separately...I doubt whether you would arrive at the same result as quickly.

Pieter-Bas: And on the client side, do you notice any developments in digital knowledge there? Do steps still need to be taken there or do you feel like the people I work with know what they are talking about?

Rony: The customers I often deal with are municipalities and other authorities, provinces, for instance. And what I very much notice there is, they very much want to digitise and they have seen all kinds of examples of what the power of digitisation is. But they themselves are not so sure how to formulate those questions and what exactly they want. Well, to come back to that nitrogen problem is: We just want to be able to do an initial assessment easier and faster of can we build, yes or no? We don't need a very precise calculation, just an initial estimate. But whether that has to be done in a tool or in an existing software or whether a different working process is needed for that. They don't know that very well. And that question is put to you very openly and I think that precisely because they involve us, because we know the context, we have specialists who know something about nitrogen, engineers who can program, software developers, that in this way you can actually educate your customer a bit by showing them all the possibilities. What I have also noticed is that coming up with a solution, building it right away and then presenting it in one go. That doesn't work, it has to be done in much smaller steps. You just have to make something small, show it and then the client gets an idea of: oh, this is possible, but if we add this, it will really be useful.

Pieter-Bas: Starting with a functional product, which is far from complete. I think it's called MVP?

Rony: Yes. Or a Poc indeed.

Pieter-Bas: And then develop it into a final tool incorporating the client's wishes.

Rony: Yes and that nitrogen dashboard. I got involved in the project a bit later. Only when the development had to start, but the customer never asked for that, so we just offered it. And then what you see is that they get very excited and then you build it and only when they have it in their hands and can play with it and sit at the buttons themselves. Yes, then all at once these concrete questions come up, now we are now three phases further in which that project we once started with, that now takes on very different forms. It may not be the most efficient way of developing from a software perspective and perhaps not the cheapest either, but it is a very interesting playing field and that makes the work really super fun. Because, well, what I then find less fun about just developing software is that, well, you get a story or an issue that you have to work on and you tap it off. You don't know who your customer is, you don't know why you're doing it, you just have to finish your work at the end of the sprint and there has to be testing and then on to the next one. I don't get satisfaction from that. I want to know, who am I doing it for and why? What is the underlying context?

Pieter-Bas: And your role now within Witteveen+Bos. Can you make an outlook of, I see my career going in this direction? In combination with the digital development we are going through. Do you have an idea of where this is going? Over the next, let's say 5 years.

Rony: I think it's going to be very important, and actually already is, to bring that customer along in what digitalisation now means. You can educate them a bit and explain very clearly: what are the consequences of the choices we make. Actually sort of. We need mediators who stand between the specialists and the customer. Specialists who are very good at saying things about ecology, about building dykes. And if you then want to put a tool between them, you need someone who understands the specialists. Well, by working in an engineering firm, you get to know that language a bit from different disciplines. Someone who understands the IT people and who can translate that specialism into something concrete that a developer can really use. And take that customer along: yes, OK, you work in Excel, for example, but this tool makes your work easier, we can automate it all a bit and then you can get on with your work.
 

Pieter-Bas: And I think it's good what you indicated earlier, of we start with a small scalable product that works at all times and from there you build out those functionalities.

Pieter-Bas: I'd like to thank you for your clarification today and for the listener, thanks for listening.

Outro: Nice that you listened to the digital engineer. Keep an eye on our channel for more episodes. This was a podcast by Witteveen+Bos.