We produce software systems at an ever increasing rate. On the one hand, this is great. On the other hand, our ability to get rid of older systems does not keep up with that pace. Let’s take an example: a not-so-long-ago study showed that there are some 10’000 mainframe systems still in use containing some 200 billion lines of code. These systems are probably older than most developers. This shows that software is not that soft, and that once in use, systems produce long lasting consequences. We cannot continue to disregard how we will deal with software systems at a later time.
Engineers spend as much as half of the effort on understanding software systems and the percentage grows with the size and age of the system. In essence, software engineering is more about dealing with existing systems than it is about building them. Two decades ago, Richard Gabriel coined the idea of software habitability. Indeed, given that engineers spend a significant part of their active life inside software systems, it is desirable for that system to be suitable for humans to live there. We go further and introduce the concept of software environmentalism as a systematic discipline to pursue and achieve habitability.
We must build our systems with recycling in mind. We have to be able to understand these systems in the future and be able to reuse and evolve them as needed.
Engineers have the right to build upon assessable systems and have the responsibility of producing assessable systems. For example, even if code has often a textual shape, it is not text. Hence, reading is not the most appropriate approach to deal with code. The same applies to logs, configurations and anything else related to a software system. It’s all data, and data is best dealt with through tools. Not any tools would do either. We need custom tools that can deal with specific details. No system should get away without dedicated tools that help us take it apart and recycle it effectively.
Who should build those tools? Engineers. This implies that they have to be empowered to do it. We need to go back to the drawing board to (1) construct moldable development environments that help us drill into the context of systems effectively, (2) reinvent our underlying languages and technologies so that we can build assessable systems all the way down, and (3) reeducate our perception of what software engineering is.
Because of the spread and impact of the software industry, we need to look at software development as a problem of environmental proportions. As builders of the future world, we have to take this responsibility seriously.