The Entanglement of Concerns between People and Software Development

Volkswagen Digital Solutions | SDC Lisbon

Recently I was asked: “but Rita, aren’t you a Software Developer? Isn’t you job to write code? Why do you keep pondering about people?” My answer was simple - “because it is not up to a person to build quality software. It takes a village”.

Software Development and People can not be seen as two separate concerns by companies. There is a natural entanglement between the two of them that I would like to explore a bit in this session.

This talk has been presented at TechLead Conference 2024, check out the latest edition of this Tech Conference.

FAQ

The principle of separation of concerns in software development involves designing code in such a way that each module or component addresses a specific concern or functionality, minimizing dependencies and interactions between different parts of the system.

There is an entanglement of concerns between people and the software they develop because the success of software projects often depends on effective communication and collaboration among team members. The human element is crucial in understanding, maintaining, and evolving software systems.

Challenges with legacy code in older programming languages include difficulty in understanding and maintaining the code, lack of documentation, potential loss of knowledge as original developers retire, and resistance to modernizing systems due to their current functionality.

Management teams often resist modernizing legacy systems because these systems are currently functional, and there is a perception that updating them would require significant time and financial investment without immediate visible benefits.

The author's experience with Fortran code, which was difficult to understand and maintain, highlighted the importance of creating code that is readable and maintainable. This experience influenced their belief in the need for modernizing and refactoring code to ensure long-term usability.

In their first job at a tech company, the author was responsible for building software to process data collected by a satellite, working within a team and adapting to challenges through effective collaboration.

Different industries, such as finance, telecom, and health, often face the issue of relying on outdated software systems that are difficult to maintain and modernize due to their age and the potential loss of knowledge as original developers retire.

Continuous evolution and innovation in software are important to meet the changing needs of users, integrate new technologies, improve efficiency, and ensure that systems remain relevant and functional over time.

The author uses the analogy of Microsoft Windows, which did not stop at its first edition in 1985 but continued to evolve, leading to the latest version launched in 2021. This illustrates the importance of continuous improvement and adaptation in software development.

From Ferdinand Porsche's quote, "I could not find the car of my dreams, so I built it," the lesson is to pursue one's vision and innovate proactively. In the context of software, it means developing systems that are user-friendly, adaptable to change, and considerate of those who will maintain and use them.

Rita Castro

8 min

14 Jun, 2024

Comments

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.

Available in Español: La Entrelazamiento de Preocupaciones entre las Personas y el Desarrollo de Software

1. Introduction to Entanglement of Concerns

Short description:

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

Short description:

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

Short description:

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

Short description:

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.