We talked about Syngenio and how the company started in an earlier interview.
Now tell us about you and your current work at Syngenio
When we started Syngenio, I became a member of the Board. But as the company grew, I found myself more and more removed from the actual IT challenges I always wanted to work on. Seeing innovative concepts become reality is what motivates me, as does spreading ideas and insights as a consultant and speaker.
So I moved from being a company manager into defining future offerings and products for our customers. Since we work with many financial institutions, for many years this meant creating fintech solutions. I am still involved in our fintech team and act as a stakeholder for our customer-onboarding software product. But since early 2021, my main focus has been on Green Software Design. My colleague Stephanie Kamp joined Syngenio at the time as Green Software Manager and together we were the seed from which the team grew.
I live in Stuttgart, Germany. It’s a fine city in a very nice area, close to the black forest.
Tell us about your education and career path before and since joining Syngenio.
I studied mathematics and computer science at Karlsruhe University, which at that time—back in the 90’s—was undisputedly the hotspot for computer science in Germany. During my first years in research at the Fraunhofer Institute for Computer Graphics, the web started to replace proprietary online services, which opened up vast new possibilities. I left the academic world and joined Brokat AG, a start-up focused on Online Banking.
Brokat rapidly became a major success, but drowned even more rapidly when the dotcom bubble blew up. Anyway, I had led successful projects for banks during my time at Brokat, and the trust I had earned with customers was fundamental for starting Syngenio. One of those contacts trusted us with a large project, enabling us to get the company going without any venture capital at all.
How did you get interested in green software?
I’ve been concerned about global warming for many years. For example, I’ve been using car sharing instead of owning a car for ages. So, when our board member Jürgen Funke—his GSF interview is here—came up with the idea that we could apply our expertise in software development to make the software itself more eco-friendly, I loved the idea. We got some colleagues together and worked it out. I’d like to mention Wilhelm Kuhn and Marina Emsing here, and of course Stephanie Kamp. Jürgen gave it a go, and I am very happy he did so.
Our Green Software Design team became a reality right at the time when the idea took root outside academic circles. When I first heard about GSF, I was immediately excited. It is very similar to what we are working on in a more local version. We call it the Green Software Design Community. It was almost funny to see the two websites, greensoftware.foundation and greensoftwaredesign.com, grow in parallel. They even ended up having similar designs, probably because both focused on being remarkably green websites.
What do you expect to achieve by working with the GSF and in green software in general?
Once you begin to think about it, you find it unbelievable that green software has been neglected for such a long time. Of course, hardware costs went down while salaries of software engineers went up. So it seemed reasonable to make programming easier by not caring all that much about hardware requirements. But the moment you take climate effects into account, you immediately recognize that this is exactly the wrong way to go.
We know very well how much IT affects the environment and we know things are getting worse despite all the improvements on the hardware and data center side. In Germany, power usage of data centers grew by 60 percent during the last decade and the trend continues. So, if hardware improvements alone won’t cut it, we have to look at software as well. It is simply the only other angle there is. As soon as I understood this, I was all in. Green Software is a must, and I very much want to be a part of it.
What GSF working groups and projects are you involved in?
We currently participate in three working groups: Standards, Policy and Community. I joined the Standards group because it deals with questions I’ve already been working on. At greensoftwaredesign.com we provide a tool that gives you a rating for your software project for mobile or web-based applications. To do so, we needed to come up with something similar to the Software Carbon Intensity (SCI) from GSF. We are right now working on including the SCI in the rating. I had, therefore, given the issue quite some thinking before joining the working group. It is great to discuss my thoughts with the group and learn from the conclusions the group has already reached. Also, the results coming in from the projects are very interesting. These projects put the SCI into practice. And moving from pure concepts to practical results is always eye opening in some ways.
Tell us more about the work of your Green Software Design team and what you’ve achieved so far.
When we formed the Green Software Design team, the first task was to identify levers you can pull to reduce the carbon footprint induced by software. Well, that still is a task to work on. More measurements from practical applications are needed. Very soon we noticed that even basic measurements were missing. Like, in which cases is it better to use node.js instead of spring? So, we collected information and started our own measurements. These became the foundation for the technology rating we currently use.
What obstacles do you see to using green software on a wider scale within your organisation and in general?
Software engineers often act reserved when they hear about green software, simply because at first, they don’t understand the implications: “Does this mean I have to code differently?” Software engineers relax when they understand that they already know many of the things that need to be done. For example, performance testing plays a major role in green software. And this is not a new technique as such, it is just applied in a more thorough way.
Product Owners partially have a hard time understanding the consequences of their requirements: “Does this feature influence the software’s carbon footprint significantly?” They need guidance from the technical team.
Think of session failover for example. When it comes to online brokerage, seamless failover is a must. If I want to sell, I want that transaction to go through right now, no matter what. For Online Banking, you could relax requirements. If failover isn’t perfect, at worst, customers have to re-enter a transaction. That is a nuisance for sure, but it happens very rarely. And it allows for a significantly simplified system architecture. We can’t expect Product Owners to know these things, so we need to guide them.
How can we overcome the challenges?
Coaching works best. Add someone to the team who knows about green software. This will help the team with practical issues, like, should we include this in the Definition of Done (DoD), or should it be a separate use case? The coach can also consult the Product Owner on the impact of requirements.
I’m aware that as of today, way too few persons are ready to be valuable coaches. This is why we created the Expertyzer, which you can use for free on greensoftwaredesign.com. It is supposed to kickstart mobile and web-application development projects. You answer a series of questions about your project and the software architecture, and Expertyzer gives you feedback and suggests possible improvements. This, of course, cannot fully replace a detailed review. But it provides a valid starting point, if you don’t have access to a coach.
How can companies get more young software engineers onboard the green software movement?
My experience is that there are quite a lot of young talent who are interested in green software. A climate-friendly lifestyle is important for many people today, so it is only natural for them to include it in their professional work as well. We need to educate these people, so they can act as coaches for projects and thus spread the idea.
Also, making resource efficiency a serious part of the development process implies weaving it into build processes and DoD and so on. It becomes kind of hard-wired into the way the development team works. This way, it becomes normal even for those who frowned at green software initially.
What can the Green Software Foundation do to get more young software engineers onboard?
The Foundation brings together many large, global companies. Their combined weight will make green software more visible and more relevant. And right now, that is still what is needed most urgently: a heightened awareness of the need to make software green.
GSF can set standards for green software, and I’m happy to be part of that process. These standards will be a guideline for both software teams and corporations. They give you direction and make it easier to communicate results between teams.
The communication itself will then continue within other circles as well. We plan to make the Green Software Design Community such a circle, by building on the results of GSF standards and projects. The community can then provide coaches to transfer know-how into more teams. This in turn increases awareness of the GSF standards. It will all come together. I am sure about that.
Any other thoughts on green software and sustainability?
There are always three groups: those who make things happen, those who watch things happen and those who wonder what happened.
If you have anything to do with software development, I strongly recommend joining the first group because green software will happen fast. It is a matter of a few years for it to become the new normal.
This article is licenced under Creative Commons (CC BY 4.0)
