From Stanford CS Professsor John Ousterhout:
Today’s thought for the weekend is: the most important component of evolution is death. So I want to address that first at a biological level and then let’s pop up and talk about it at a societal level, Silicon Valley, and computer software. So, first, from an underlying biological standpoint, it’s sort of fundamental that for some reason it’s really hard for an existing organism to change in fundamental ways. How many of you have been able to grow a third leg? Most people can’t even change their mind let alone change something fundamental about themselves.
John Ousterhout, Favorite Sayings
People try. You make your hair look a different color, but it’s really the same color underneath. In fact you have this whole thing called your autoimmune system whose goal is basically to prevent change. You’ve got these white blood cells running around looking for anything that looks different or the slightest bit unfamiliar and as soon as they find it they kill it. So it’s very hard for any organism to change itself, but when we make new organisms it’s actually fairly easy to make them different from the old ones. So for example gene mutations seem to happen pretty commonly. They can be good or bad, but they do change the system. Or, with sexual reproduction, it’s even easier because you take genes from two parents and you mix and match them and who knows you’re going to end up with as a result.
So the bottom line is it’s a lot easier to build a new organism than it is to change an existing one. And, in order for that to work, you have to get rid of all the existing ones. So death is really fundamental. If it wasn’t for death there’d be no way to bring in new organisms and create change.
I would argue this same concept applies at a societal level. In fact, if you look at social structures, any structure that’s been around a really long time, it’s almost certainly out of date. Because, they just can’t change. Human organizations, companies, political systems, religions, they all have tremendous difficulty changing.
So, let me talk about companies in particular. We’re hearing these days about various companies in trouble. Is Yahoo going to make it? And Kodak filing for Chapter 11. People seem to think: those guys must have been bozos. They blew it. How could you fumble the internet when you’re Yahoo?
My opinion is this is just the circle of life. That’s all. That fundamentally companies can’t change. You come in with a particular technology, something you do very well, but if the underlying technology changes, companies can’t adapt. So they actually need to die.
I view this as a good thing. This is the way we clear out the old and make room for the new. And in Silicon Valley everyone kind of accepts that. The death of a company is not a big deal. In fact, what’s interesting is that the death of the company isn’t necessarily bad for the people at all. They just go on to the next company.
And I was talking to a venture capitalist once and she told me she actually liked funding entrepreneurs who had been in failed startups because they were really hungry yet still had experience. People in successful startups weren’t as hungry and didn’t succeed as often when they got funded. So death is actually a good thing in Silicon Valley.
Now let’s talk about computer software. This is kind of ironic because software is a very malleable medium, very easy to change. Much easier to change than most things. And I actually consider that to be a problem because, in fact, people don’t have to throw it away and start again.
Software lives on and on and on. You know we’re still working on versions of Windows 20 years old right now. And as a result the software gets messier and kludgier and harder and harder to change. And yet people keep struggling. They won’t throw it away and start again.
And so what’s funny is that this incredibly malleable medium gets to a point where we can’t make fundamental changes in it because people aren’t willing to throw it away and start again. I sometimes think the world would be a better place if somehow there could be a time limit on software where it expired. You had to throw it away and start again.
So this is actually one of the things I like about California and Silicon Valley. It’s that we have a culture where people like change and aren’t afraid of that. And we’re not afraid of the death of an idea or a company because it means that something even new and better is coming along next.
So that’s my thought for the weekend…
From Wunderlist CTO, Chad Fowler:
One of the things about a tiny method or a tiny micro-service is that it allows you to consider replacing it. You can change it, you can understand it really quickly, but even if you can’t—if it’s small enough, and it’s named well enough, and it’s decoupled enough, you can just throw it away and restart it if you have to.
You have a system and you need to keep it in a consistent state, an understood state, and it runs for a long time. I remember having systems that were up for two years and being really proud of that. Now I realize, though, that’s terrifying. If a system is up for two years it’s very difficult to know how to recreate it and what the state might be.
What we figured out is that you should just throw away the systems. That’s the best way to do it. Don’t change the systems. Because then you get rid of all of the issues of these weird unchangeable scary things. Throw them away and start over.
So we established this immutable infrastructure system where if you wanted to upgrade anything on a given server, then you would throw away the entire thing and just rebuild a new one and replace it. The beautiful thing there is you know exactly what’s there, you know you can recreate it, you’re doing it all the time. The thing is changing, which proves its ability to change and you have a system that is able to change.
The more radical thing was, how do you change your software? Well, maybe you should just plan to throw it away. This is where I start talking about the code fetish thing. At Microsoft, we have code that’s twenty years old and it’s reusable, it’s shared all over the place. People both love it and feel tied to it. If you’ve worked at a big company you probably know this thing where you have these reusable libraries and you’re kinda stuck to what they can do and they follow you around.
We started saying let’s just plan to throw our software away. So when we write it, there’s a little less stress. We can also try out new things because there’s less stress about trying out new things. And not only can we throw away the pieces of code, but we should.
If you need to be able to change your software and you do it all the time and you plan to do it then it’s easy to throw stuff away.
If I need to be able to change an entire app system, if I declare that you cannot change anything inside a component, you can only replace it, then it makes the entire thing easier to understand and easier to actually change.
We rewrote all these pieces of code, we didn’t rewrite the system. Within a year we rewrote 80% of the code and there was no project where someone said I’m now going to work on rewriting a piece of code, there was nothing in a backlog, it was just maintenance work. While I do this feature change, I’m just going to replace the whole thing. Why do I do that? Because it’s healthy to be able to change code so I’m going to prove I can.
Chad Fowler, Impermanence: The Ironic Key To Systems That Survive.