Interview with Chad Fowler at GOTO Chicago 2015

Hi, it’s Mike with UGtastic. I’m here at GOTO Conf 2015 and I’m standing here with Chad F owler, who’s giving the closing keynote for the event. Thank you very much for taking the time to speak with me, Chad. So what is the story, what is the message you want people to take away from your keynote? Well, I’m going to tell a story of the recreation of Wunder list, which is the app that I work on, app and service. So it’s going to be a story, literally in that sense, one of those kind of here’s what happened from, I hope so, yeah, I’m not sure, I’m not sure if there’s a hero yet. The humble task list rises up to become the Wunderlist. And it rises up from the flames, literally. But yeah, my overarching message is that I am sort of on a mission in my career to learn how to build software that can outlive me and outlive us. Ideally without us dying. I’m going to talk about some of the things that I’ve learned in my career and that I’ve applied on this most recent project in hopes that they inspire ideas in other people, that they can create software that can survive longer. That is one of the, sometimes I think, things that people, we try not to think about the mortality of our work, that it’s, I don’t know if my work’s going to survive the next framework upgrade, much less. But yeah. I think that’s one of the things that I’ve learned. I think that’s one of the things that I’m going to be able to go into the future and support. You know, something that might actually be useful for my kids. Well, most of our work actually doesn’t survive even the project that’s never born, so that’s the sad thing. Most of the work that we do in the software industry is stillborn, or not even that, it’s just canceled. You know, if you look at the Standish Chaos Report, which is of course kind of a maligned thing, but everyone references it and it feels direction ally correct, most software projects either fail or are significantly changed. And by the Standish language, I would say significantly challenged means failed. So most projects basically fail that we work on. And then as you and I know, we build software and we tend to have to throw it away, someone has to throw it away at some point in the not so distant future. So if most projects fail, and then things that get launched , they live maybe five years, it’s kind of like you spend all this time, this passion, this energy of your life working on stuff. That is ultimately kind of meaningless. So that’s sad. And I’ve spent a large portion of my career euthanizing software systems. Going into a situation, finding a dying or sick system, and trying to humanely put it to sleep. And I’m tired of doing that. So are you going to be looking at some of our tools that we use, or is it mostly about techniques? It’s mostly about architecture. The thing that has inspired me the most is looking at how biological systems work, specifically like human bodies, how someone like I can still be alive after 41 years, given the poor maintenance that I’ve done on the system, and take some of those metaphors of like cellular regeneration and homeostasis and apply them to software architectures. But I think that’s the main kind of overriding theme. Yeah. I mean, like I’m going to talk about micro services, but I don’t really care about that term. And I think it’s silly for people to be excited about the term. It’s more about creating an architecture where the system can evolve and change frameworks like you mentioned, or even change languages, technologies, whatever, and the system can still live through all these things, even if the components are being regenerated on a regular basis. Yeah. Well, I mean, thinking about a lifetime of software and whether it evolves, I mean, one thing is… From what I understand, the human body basically, after a certain number of decades, has completely replaced all the cells except for some really core stuff in our marrow. Software, when you’re saying alive, if it’s just being ref actored, not entirely just replaced outright, is that still staying alive, or is a rewrite just another way of perpetuating the ideas that were inside of the original software? Yeah, it depends on how you think of it, of course. Although I would say that the parallels of a rewrite to cellular generation, they don’t really map. When a rewrite occurs, though the ideas still exist, the software is completely replaced. It usually looks and behaves differently. It doesn’t have to, but it almost always does, because that’s how it works. That’s how rewrites go. So, to me, the ability to have the system continue to stand in place and continue to work is an important part of considering it to have lived or survived. So, you’re right, the idea that here we are, you’re Mike and I’m Chad, and we’re the same people that we were when we were born, but not really the same physical substance. That’s what I’m getting at. Notably, we didn’t notice. We didn’t feel when the cells were regenerated, and no one around us noticed. There wasn’t an impact on our continuing function, actually , and improved our function. That’s the way systems should evolve and the systems should survive. Well, I can also look at that as kids, as a parent. I’m watching, I am watching that evolution of the cells changing in over years. And you do, I mean, you might not feel it on a day-to-day basis because it happens so slowly. I mean, I don’t know if that has any kind of correlation. I don’t know if that has any kind of correlation to the idea of the evolution of software. And even though it’s changing, it’s still the same entity, but it slowly changes, it develops, it gets a little bit stronger, and eventually, after a while, well, I mean, everything dies and it gets weaker. It gets weaker, it gets sicker. So, sure, you know, and there’s also, there’s something to be said. Like, I used to think about, what if we could just build software so quickly that it didn’t work? It didn’t matter, we could just throw it away. Right. So then we don’t worry about longevity of software. And now I’m sort of meeting the middle where you can build components so quickly, you can throw them away, and you should. But, you know, so over time, the system might be irrelevant , and that’s when it should die. Not when the implementation is irrelevant, right? Okay. I can imagine in software systems, depending on who’s working on them and how focused they are and all sorts of other factors, they might get weaker over time if they were to evolve in this way. Or maybe subsystems would get weaker over time. But you would then notice that they’re weaker and it would work on them in the same way that a doctor would work on a patient or, you know, whatever. Yeah, you get bad knees. Okay, we’re going to just replace those. We don’t have to replace, we don’t have to take you out back and put an old yeller on you and then say, “Oh, well, we built a new one that has new knees.” Well, anyway, thank you very much for taking the time to speak to me. I appreciate it. Sounds like a fascinating keynote. Looking forward to it. I hope so.