Video Summary and Transcription
The Talk explores the entanglement of concerns between people and the software they develop, emphasizing the importance of considering people and teams instead of just coding. It highlights the time constraints faced by developers and the potential for code optimization to improve understandability and usefulness. The Talk also discusses the significance of revamping outdated software and embracing continuous improvement in software development. It concludes by emphasizing the interconnectedness of software builders, thinkers, users, maintainers, and payers, and encourages the development of user-friendly software systems that adapt to change and consider the needs of all stakeholders.
1. Introduction to Entanglement of Concerns
A friend asked me, as a software developer, why I often talk about people and teams instead of just coding. This got me thinking about the entanglement of concerns between people and the software they develop. In one of my research projects, I was given a Fortran program that was hard to understand. I suggested rewriting it in a more modern language.
A while ago, not that long ago but some time ago, I was chatting with a friend of mine and she asked, but 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? 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 fun, 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.
2. Time Constraints and Code Optimization
There is never enough time to revamp and rebrand the code, even though we have the code, tests, and the ability to improve it. Many students and colleagues from different departments face the same time constraint. The code we usually see is highly optimized, but a simple refactor can make it more understandable and useful.
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 for sure. OK, 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, functions, 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 can look it up later. What does it do? Fair enough.
3. Revamping Software and Continuous Improvement
I built software to process satellite data, facing challenges and adapting to change. In different industries, including Volkswagen, outdated software runs because the people who built it are no longer available. Revamping is essential, even if it works. Microsoft Windows is a prime example of continuous improvement.
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, 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 launch, in the project was the launch. So when the satellite was launched, early on we realized 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. It worked because of these amazing people that worked together, connected, building and running the product that we were taking care of.
Fast forward 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 runs, 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.
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 going to do anything about it. Right? Wrong. 1985. The first edition for Microsoft Windows. Did they stop there? No. They continued.
4. The Entanglement of Software Development
In 2021, the last version of their operating system was launched, driven by user feedback and a commitment to innovation. The puzzle lies in the interconnectedness of software builders, thinkers, users, maintainers, and payers. We must recognize the entanglement of concerns between these actors. Like Ferdinand Porsche, who built the car of his dreams, we can develop user-friendly software systems that adapt to change and consider the needs of maintainers and users. Embrace this entanglement in your work.
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 had enjoyed.
Comments