The Entanglement of Concerns between People and Software Development

A while ago, not that long ago, but some time ago, I was chatting with a friend of mine and she asked, Rita, you're a software developer, but in our conversations you often talk about people, teams, how they connect, what's wrong, aren't you supposed to build code? And that kind of stuck with me and it led me into a bit of a thinking state and that's where all of this came from.

So as software engineers, we are taught about the principle of separation of concerns and we do it very well in our code. We code, we design our code with the principle that this module does this, that module does that, almost no connection between them and we're good, we're fine. However, things are a bit not facing one another and I actually think that for this case and for software development, there is actually an entanglement of concerns between people and the software that they develop.

I studied at university physics, so not a computer science engineering degree and I did astrophysics and early on in one of my research projects, I was given a task to process some data and along with that task came a computer program that was in Fortran and it was really, really hard to understand and to follow and the language, the data itself, so it was weird and it sparked the conversation between me and my professor and it was interesting because he was very fond, he was very happy. It implements stuff from the paper, it's very trivial. It's not very trivial, but I have an idea, why don't we take the code, we have the paper, we have the data, let's benchmark this, let's write it again in a new, more modern language that new people can understand and follow through.

No, no, no, no, no, we're not going to do that. There is no time. This has been battle tested and battle proved by many, many students before you and many, many students after you. But listen, we have the code, we have the tests, we have things that we can revamp and get it new, get it rebranded. No, we don't have the time. Okay, when will we have the time? You know, soon? And guess what, folks? Soon never came. And when I told this story to a couple of friends of mine from different departments at university, they said the same thing about theirs. Yeah, yeah, yeah, it's the same for us at math, it's the same for us at physics, whatever.

And the code that we usually see, it is really, really optimized. At the time, it had to be because of constraints in computers, constraints in memory, et cetera. So if you look at this, yeah, function F, it does a random thing, then you call the main function, you call the number. But with a very simple refactor, if I change it to calculate factorial, now you know out of the blue, it computes the factorial for a number, and you look it up later, what does it do? Fair enough.

Onwards. I started working at a tech company. It was for aerospace engineering. And my first job was to build not the satellite, thank God, but build the software that would process the data that the satellite collected. The team was amazing. And as you can imagine, building a satellite means that you have a lot of phases that you have to go through. So naturally, the project followed the waterfall ways, and each step had to be done after the other. One of the most important steps in the launch, in the project was the launch. So when the satellite was launched, early on we realized that there was something that wasn't working in one of the receivers, and we had to readjust, readapt, react to change, make new algorithms, implement them, validate them, and get them up and running again. And it worked. And it worked because of these amazing people that worked together, connected, building and running the product that we were taking care of.

Just a couple of years ago, I joined Volkswagen Digital Solutions in Portugal, and to my surprise, I discovered that some of the software that runs in the factories, it's also a little bit old. A tad, let's say. But it is mostly software that runs on-prem, that is written in COBOL, that the databases are really, really old. And it's a little bit not optimal. Let's put it this way. And again, when talking to my friends, they say, yeah, but it's the same thing with us in finance. It's the same thing with us in telecom.

It's the same thing with us in health. Okay, fine. But it's not that things don't work. Things work. But why do they work? And for us, in our case, it's a little bit, and I'm sure that for the other tech industries and for the other places, it's the same thing. The people who have built these systems, they're no longer there, or they're on the verge of retiring, which means that the knowledge is going to get lost, and it's going to be really, really hard to revamp and keep things running.

And I'm pretty sure that over the years, a group of skilled professionals have come to management and said, hey, listen, why don't we take this, and it doesn't have to be the newest and shiniest technology ever, but why don't we take the opportunity and let's revamp, let's modernize, let's change this a little bit? And typically, the answer that people get from management is, oh, but it works. It's working. Why would we replace time and money to replace something that is working?

So fast forward to the early parts of the story. So with all of this in mind, oh, because we have a product that works, and if we have a product that works, let's not do anything about it. Right? Wrong. 1985. The first edition for Microsoft Windows. Did they stop there? No, they continued. And in 2021, they launched the last version of their operating system. They evolved. They listened to the users. They kept pushing forward, driving the change, and pushing for innovation.

Circling back. And as she said, it's a short period of time. I think there is a puzzle. There is a huge puzzle that is lying around. The people that build software, the people that think software, the people that use software, the ones that will maintain them. And the people that pay for software. And I think that we cannot shift and we cannot separate the pieces, one from the other. I think they're all connected. And there is an entanglement of concerns between all of these actors at play.

And so, that is my idea. And when I visited the Autostadt in Wolfsburg, there are several pavilions. One of them is the Porsche pavilion. And Ferdinand Porsche had a very famous quote in which he said that he could not find the car of his dreams, so he built it. So, follow your dreams. I really think that it's possible for us to develop software systems that are user friendly and can adapt to change. Keeping in mind the people who will maintain them and use them throughout the years. So, be those people. Keep that entanglement in mind when you're working.

So, thank you very much. I hope you have enjoyed. Thank you.