At the 2016 ArchConf in Clearwater, FL, I sat down with Tudor Girba to discuss his ideas around Software Environmentalism.
You’re listening to the “No Fluff Just Stuff” podcast, the JVM Conference series with dozens of dates around the country. There will be one near you. Check out our tour dates at nofluffjuststuff.com.
I have the privilege of being joined again with Tudor Girba. I want to talk to you about a topic that you’ve written on a little bit. You’ve talked about quite about this idea of this notion of software environmentalism.
It’s funny, isn’t it?
It is. It’s something that we don’t really think about. Would you mind to — for those listening — give a brief summary of what that really is, what you mean by that.
It starts from the observation that we’re creating software systems faster and faster, so the body of software grows. Some indication says exponentially. At the same time, we’re seemed to be unable to get rid of old systems.
From that perspective, I see our industry as behaving very much like the plastic industry from the previous century, completely focused on building things with no regards to what’s going to happen with those systems once out there in the open.
It was really interesting when you were talking about decommissioning of old systems. The thing that really amazes me, astonishes me even, is that we might have some old legacy system that’s been around for decades just growing and sprawling. It’s largely been replaced, but it’s still hanging on. We have this massive legacy system that’s still hanging on because of one tiny thing that it still does.
Yeah, that’s one reason, but there are other reasons. From my point of view, the main reason is that, with the way we’re working right now, we cannot afford to take those systems apart.
Sure, but sometimes it’s…
It’s not that we don’t want to. There’s sometimes tremendous necessity to do so, and yet we still are seem to be unable to do it. We have to look at this problem as a global phenomenon because everything we build right now is the foundation from how the world is going to be tomorrow.
We get to touch everything around us as the software industry, which means that the trajectory that we’re now setting is quite important for the future. Being around, just producing things with no regards of how do we evolve globally, not the system individually but globally, it’s not quite right.
What are the implications if we keep going in this direction?
I took the metaphor from the physical environmentalism movement. This year, we had Al Gore giving a very interesting TED Talk. He was showing how these all the emissions that we have are actually growing exponentially. The problem is actually as bad as predicted.
The interesting thing is where the solution comes from. Before that, one thing it is pointing out to is this idea of unburnable CO2 mass, which is then equated with money. Global economic forum has said that the climate crisis is the largest economic threat for the first time in history.
There is an estimation that we have somewhere around $22 trillion worth of unburnable CO2 mass. That is CO2 mass that we have produced on our feet or whatever, produced and that we cannot be get rid of forever. That’s a huge economic cost. Now, where’s the solution coming from?
For a long time, people have thought, “Well, let’s consume less energy.” As an individual, people were saying, “Look, in a household here, maybe in the US is consuming like…just a fridge is consuming more than a household somewhere in Africa.”
The idea there was, “OK, let’s consume less,” but then obviously that didn’t work out, especially given that we still have a couple of billion left that are not on the grid at all in which will come on the grid. The consumption would just grow and get higher.
Still, where is the solution coming from? The solution comes from the adoption of alternative energy sources. That adoption interestingly also follows an exponential curve, which is amazing. That’s the totally unexpected thing. Now, what makes that exponential curve and adoption of alternative energy sources possible is the steep decrease of the cost.
Now, one thing that he’s mentioning very interestingly there is that he’s mentioning his talk from 2006, which was his first talk about climate change at TED. That time, if you watch that talk, it’s a very interesting thing because at that time, the term climate crisis was not yet point.
With climate change, but not with climate crisis?
Right. There was no this marketing part of it, he was in point. He was actually brainstorming right there on the stage, should we do this, should we do that. The other thing he was talking about, he was talking about the necessity of mass persuasion, the idea of making everyone aware that this is an issue.
Looking back is amazing to see how that point in time is exactly the moment, we’re looking at the exponential curve of the adoption of alternative energy sources. It’s amazing to see how that point in time, 2006 correlates with the inflection point in the exponential curve.
The fascinating part there is that once we deem something worthy of a conversation as a community, then we can actually create solutions that are otherwise completely unpredictable.
Now, coming back to social environmentalism, if we continue to create software the way we do it now, at some point very soon, we will hit a wall. It might come much sooner than we think.
One reason why we have not seen this problem up to now so dramatically is because we were still able to double the amount of developer population somewhere around once every five years, basically, doubling the amount of developers. There’s some estimation in that sense.
Essentially, we were able to basically throw more eyeballs at the problem. That’s why we do necessarily see the effect of creating all this software mass and amassing all this software mass around us.
However, we are soon running out of places to go and recruit from. We would likely not be able to double size for too much longer. Right now, we’re estimating somewhere around 10 million developers with maybe a million developers somewhere here in the US.
Tell me now, what’s the solution there? I may not know what the complete solution is, but I know where the start is. You see, before you can take a system apart, you first have to understand the parts.
This is where it’s going to come to some kind of crisis point, if you will. That before we delve to this, I just want to get your thought on this, because I really do feel like one of the challenges based on that experience is that we’re very happy and very quick to write new software.
There’s a lot of resistance among software developers to actually take time and read code, if you will, instead of writing it. I know you’ve got some ideas on that too. It is easier to write code than to read code. I’ve worked with plenty of developers that really don’t possess that as a skill at all.
You have 10 million developers, and there’s a good percentage of them that just aren’t very good at going through and taking the time to understand existing codes. They’re more apt to go and build something new again rather than reusing any of these points.
Would you see that as contributing to this problem?
Certainly. Here’s the thing. As you know, I define my main job as teaching developers how not to read code. Since the last time I talked here, I actually asked about 2,000 developers if they agreed with the statement that developers read for about 50 percent at a time, they read code. There was a vast majority that does agree with that.
There’s also prior research that kind of indicated this thing but probably this inquiry of 2,000 people is the largest study in this sense that we have so far. I’m asking them the second question, “When was the last time you heard developers talk about how they read code?” That’s where basically people said, “We’ve never heard anybody talk about it.”
That’s just a fascinating thing as in coming back to your question, is it a problem that some people are maybe not so adept at reading and consuming existing systems?
It could be a design problem. It could be that we’re just not…
I don’t think it’s a design problem. The main problem is that this is not yet a subject of conversation. As I said, the reason I made the parallel with Al Gore’s presentations is that the infection point in the rise of the solution really correlates incredibly well with the focus on making the problem a subject of conversation — not the solution, the problem.
If we think about 50 percent of the time developers spend reading code, we’re talking about the single largest, most expensive activity we have and yet we never talk about it. To put it in perspective, I said a million developers here in the US? Let’s say, a developer maybe costs a company $100,000 per year?
We’re talking about the $50 billion expense per year on this one single activity and yet we still don’t necessarily talk about it. It doesn’t make much sense. Now, if we do talk about it, the problem there is that reading is the most manual possible way to extract information out of systems.
Of course, we do need to go and look at the system because this is the only truth that exists, but not reading it. It doesn’t have to mean reading and understanding doesn’t have to be accomplished through reading. The problem with reading is that it has a constant speed.
If you come back to this observation that software systems grow exponentially and we are trying to understand these systems with means that have a constant speed, then we have a fundamental problem.
I might disagree that it’s a not a constant speed. It has a maximum speed.
That’s what I said. It’s capped to be…
Sometimes as you’re reading code depending on who wrote it…if I were to write it, then it might take longer for somebody to read then.
Certainly, but it is capped in speed. That’s what I meant.
There’s only so…
…so much you can do?
There’s a limit to your productivity.
Exactly. A flat line cannot match an exponential curve. That’s the problem. This is the prerequisite for our ability to recycle the system because before you can take a system apart, you first have to understand the parts.
We can’t continue to gain understanding of these parts to keep pace with the rate they’re being created?
Exactly. The only way we can do this is we have to make the understanding of the parts not be a function of the size of the system. The way we can accomplish this is exactly how we’re dealing everything else data. We’re getting the computer to do it for us. That’s how we can solve this problem.
A concrete solution that we can talk about right now — we also talked about it last year — is an interesting starting point but it doesn’t necessarily have to be the end point. Again, my main goal is to make the problem the subject of conversation. Once we start talking and once we deem it important, the kinds of solutions that we will be able to create are totally unpredictable right now.
Just look at, for example, what happens in the data space or microservices space. The kinds of solutions that we have right now were completely impossible or unthinkable just a couple of years ago. Now, we have even whole business models that didn’t exist. Why did that happen? Because we have made it a subject of conversation as a community. The same thing should happen for this other large problem.
What are some things that we can do as a takeaway from the discussion today?
Just start talking about it. Ask your colleague, “How do you read code?” and if you’re at it, ask yourself, “Why do I actually have to read code? Are there no other alternatives?”
Find a way to perform searches against your system through some sort of automatic means. Have a search engine somewhere around that is able to search through your system, not as if it would be plain text, but like you would do with an escrow database.
Use something that allows you to say, “Give me all the classes annotated with this that are still being called from this part of the user interface and maybe they are using this part of the database.” If you are able to write a query like that, you are already far ahead of what you’re able to do right now.
It does remind me a little bit of when I was spending a lot of time as a database developer. I started storing more meta data around all the code that was in the database — all the stored procedures and things like that — and building some capabilities to query that as though it was data.
Where are you seeing some research done in this area or are you seeing anything because I know you’ve got Project Moose?
Yes, moosetechnology.org is probably an interesting place to look at. It’s probably one of the most extensive open source platform that fosters software analysis research. It’s also directly applicable to an industrial project. I’m using it since seven years exclusively in solving concrete problems.
The goal of these kinds of platforms is not so much to provide ready-made clicking analysis, but to give you the engines with which you should build your own analysis. It’s not just search. It can also be, for example, visualization.
In that space, of course, besides our work around the Moose platform, you find opportunities everywhere these days. Imagine taking your system and putting in Neo4j database, and then using the JSON interface, and then feeding that into a D3.js visualization engine.
It’s an option that you can utilize right now. You don’t have to do much. It’s something that you can do. It’s not so complicated in the end. The problem is more the opposite. Right now, because we don’t look at our systems and see data, because of that, we also do not see the opportunities.
We’re bombarded right now with data opportunities in terms of how we stored it, how we represent data, how we can manipulate data, query data, visualize data.
All these possibilities are exploding around us. We do not take advantage of that just because we don’t see our problem as being the data problem. If we flip that switch, or is it switch that flip? I don’t know. [laughs] I mean, there’s just one bit that basically tells us, “Oh, yeah. This is a data problem. We treat it this way. This is a code problem. We treat it in a different way.”
If you see those things as being the same kind of problem, and all of a sudden, everything that we’re using for data is applicable to our problem. This is not so complicated. It takes a bit of time to get used to, but it isn’t complicated.
The benefits, it has the potential to completely revolutionize our entire workflow.
I think so. I gave a couple of exercises today. One of them is giving people a problem to estimate how long it would take them to perform the same assessment. The estimations that I get back is varied. They are, on average, somewhere around four hours. The discussion it takes to discuss and pick the estimation is somewhere around 10 minutes.
I’m taking the 10 minutes afterwards. I’m showing it, “OK, let’s do it again now with appropriate tools.” I asked people to think about, “What steps do you take to actually perform the assessment?” People described clicks where, “I will click here, will do that. I will click here and do that, and [inaudible 20:48] scroll, it’d be here.” They end up and estimated somewhere around four hours as the time needed to perform the task.
I’m showing this, how it’s possible to do it through tools, and then also use some visualization there, query and combine those things. We’re talking about 10 minutes as a solution. The complete solution is right there within 10 minutes. We’re talking about at least in order of magnitude of improvement in that sense.
The more exciting part is another one. I’m actually asking people if what they have seen, if they could describe this thing as being cool.
They universally say, “Yes, that’s really cool.” This is where this thing is, I think, where we really have a chance of transforming this part. I also asked developers if they enjoy working with legacy systems. Not only that they don’t enjoy it, but most of them actively dislike it.
The interesting thing there is that it means that we are, for the largest part of our time, we’re miserable.
On the second time, we’re supposed to have the coolest job on the planet. Now, what if we can turn that miserable experience into something cool? What kind of a potential will that unlock? That’s where the hope, for me, comes from.
They described an assessment, the bugging situation or an assessment situation as being cool. Not as being reasonable or fine, but as being cool. That can really change the energy of people.
Sounds awesome. Enclosing, do you have any resources or anything you recommend that if anybody’s interested, at least they can check out?
Most of these thoughts there, they revolve around the method that I created, which is humane assessments, so humane-assessment.com, which basically is an explicit approach to the time people take to make decisions about software systems.
Humane assessment is made possible due to the Moose analysis platform. The Moose analysis platform was actually designed such that we can have the cost of an analysis tool is really low. Moose is implemented in a new programing language, which is called Pharo, pharo.org.
More recently, we’ve started a project of rethinking the IDE to incorporate these workflows of assessment right there from the start, at the very core. We now have a couple of releases already out. We’re working on some more features that, I think, are quite exciting.
Well, if that’s so, I’ll definitely encourage people to check that out. Tudor, thank you for joining me again. It’s great to see you.
In No Fluff Just Stuff, we bring the best technologists to you on a road show format. Early bird discounts are available for the season. Check out the entire show lineup and tour dates at nofluffjuststuff.com. I’m your host, Michael Carducci. Thanks for listening, and stay subscribed.