The Modern .NET Show

Episode 18 - The History of .NET with Richard Campbell

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

Episode 18 - The History of .NET with Richard Campbell
The .NET Core Podcast

Episode 18 - The History of .NET with Richard Campbell

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

Please enjoy this interview with Richard Campbell, known for his work with the Humanitarian Toolbox and both the ..NET Rocks! and Run As Radio podcasts. Campbell discussed his upcoming book on the history of .NET, which he has been researching for about a year. He has conducted 65-70 hours of interviews with people both inside and outside of Microsoft who have worked with .NET in various capacities, including web development, client-side development, and mobile development.

Campbell’s goal with the book is to tell the story of .NET’s evolution from a product built to support enterprise developers consuming Windows to a cross-platform, open-source product. He wants to reveal the decision-making processes behind .NET’s development and explain why certain decisions were made.

The interview also touched on the challenges of building a new audience for separate shows and the difficulty of getting new listeners, even for established podcasters. Campbell acknowledged the importance of passion and the finite lifespan of any project, as well as the potential for future books on the history of .NET Rocks or other podcasts.

Additionally, the conversation examined the split between the .NET community’s standard framework and .NET Core. Campbell believes that efforts to bring the two communities closer together are necessary to create a unified version of .NET that works for everyone, including those who are resistant to open source technology. He notes that the development of .NET over the years has been a significant endeavour, and it is crucial to appreciate and value different languages’ strengths to create a better product.

Campbell considers software development to be an engineering discipline, but acknowledges that there is also an art to engineering. He believes that software should be functional first and beautiful second, just as a bridge should be safe first and beautiful second. The interview concludes with Campbell stressing the importance of empirical data as the best possible teacher and encourages developers to try new things and make mistakes, without letting scar tissue stop them.

Overall, the interview provides insight into the history and current state of .NET and the challenges faced by the community. Campbell’s upcoming book promises to shed more light on the decision-making processes behind .NET’s development. The interview serves as a reminder of the importance of unity and appreciation of different languages’ strengths in creating sustainable software.

This episode is sponsored by elmah.io - Error logging and uptime monitoring for ASP.NET Core.

Episode Transcription

Hello everyone and welcome to THE .NET Core podcast - the only podcast which is devoted to:

and not forgetting The .NET Core community, itself.

I am your host, Jamie “GaProgMan” Taylor, and this is episode 18: The History of .NET with Richard Campbell. In this episode I interviewed Richard Campbell about his upcomming book on the history of .NET, and the Humanitarian Toolbox. Some of you may know Richard Campbell from the ..NET Rocks! and Run As Radio podcasts and his work with the Humanitarian Toolbox.

So let’s sit back, open up a terminal, type in dotnet new podcast and let the show begin.

Jamie

Thank you very much for being on the show, Richard. It is a great pleasure.

Richard

My pleasure too, Jamie. Thanks so much for asking me.

Jamie

I talk about different members of the podcasting community, and I feel like yourself and maybe Scott Hanselman, and Carl are right up at the top as the zenith.

Richard

I appreciate that. I think the only thing we’ve done right is we got started early. We’ve been around for a long time. I really enjoy what we do. We have a great time making those shows, and I don’t see us stopping anytime soon.

Jamie

Everybody that I talked to before I started this show said, “record four or five episodes first and just find your voice, find what you want to say and just ditch those five because they’re going to be terrible. And now that you’ve got those five out of the way, you can start sounding a little more professional.” I don’t think I’ve managed to do those five in the 13 or 14 episodes I’ve put out so far. So hopefully I’ll find my my voice soon.

Richard

Yeah, I would agree.

A) don’t throw anything away. Your legacy is important too, and I think listeners appreciate that you’re evolving. Honestly, we’ve dialed the professionalism down a little on ..NET Rocks. We really, in the early days, looked at ourselves as like radio and wanted everything to be perfect and we fixed every little thing. But I think more people are comfortable with the fact that there are mistakes in audio. And so we’ve left in things that we thought were funny but were mistakes. And I think it makes it a little more personable. I think we’re in an era now in podcast where that familiarity is almost more important than perfection. And so I would definitely encourage you to leave. Don’t waste anyone’s time. Like, if I’m looking for a note or I have to double check a fact or something, I’m going to edit that out. But if you fumble on something and it’s a humorous outcome like that’s real life. And I think people appreciate just hearing that we’re not as perfect as the audio engineers make us seem and that we’re human, that there are real, normal human things in there. I think warmth and reality, truth is more important than perfection.

Jamie

I see. That makes a lot of sense. I do know that I spend way too much time going through and removing all of the “ums” and “ers”, thinking that it’ll sound brilliant. And then when I listen to it again, I can hear where the volume drops off.

Richard

Yeah, well, you’re your own worst critic, and you always will be. I have a tough time listening to podcasts because I only hear the mistakes. I have the good fortune that I primarily learn through reading, so I don’t have to listen to a lot of podcasts. I do listen to some, but it is painful for me because I’m very critical of the product. I’ve made a lot of it, and so I think it’s interesting to decide how far to edit. We have done the anti-um thing, but I’m only going to make edits where I know it’s not going to be intrusive, that we’re actually making it easier to listen to the show.

Jamie

That makes perfect sense, because, like you say, you want that sort of personal experience, that this is a group of people discussing something.

Richard

Yes.

Jamie

And it’s kind of off the cuff. It’s not pre-planned, it’s not scripted. There aren’t certain beats to hit. It makes sense.

Richard

And so at the same time, you don’t want to waste anyone’s time by not knowing what to talk about. You don’t want to stilt… what everybody really wants is, “I want that sense of a conversation.”

Carl’s original inspiration for ..NET Rocks, which predates the word podcast by a few years, was actually in the speaker’s lounge at conferences, seeing a Billy Hollis and a Rocky Latka arguing over a way a particular piece of code should be written. What was the right way? And just sort of acknowledging that that conversation was so valuable that everybody should hear it. So let’s capture it.

And if you actually put on a pair of headphones and listen to .NET Rocks, you’ll notice that we kind of position ourselves around a table using panning. So I’m a little on the right, Carl’s a little on the left. The guest is more in the center. But I really want to simulate that effect that you are sitting at a table with us while we have a conversation.

Jamie

I may have to maybe emulate that for this episode.

Richard

Well, feel free. Everybody needs to learn more anyway, right? Anything we can do to make it easier to learn. And so making people comfortable so they could just focus on the story on that conversation, that’s absolutely the goal. If I can have you forget that this is even a recording, that you’re just there, then we’ve done our job.

Jamie

Okay. Yeah, I’ve been making notes the entire time.

Richard

Well, after a couple of thousand podcast, you sort of get a feel for some things. Although, admittedly the industry has changed several times since Carl started out in 2002. So being old in this is not automatically an asset. I also struggle with, “are we dinosaurs?” That we have a lot of behaviors that aren’t relevant anymore because technology has evolved and the audience has evolved and the perception of podcasting has evolved too.

Jamie

I suppose it is a difficult line to sort of balance.

Richard

Yeah. I’m grateful for what we’ve done so far, but I don’t presume infinite longevity in this either. I am very aware that we all have a lifespan and that you can only make so many things, and if you’re not still passionate about it, there’s just no point.

Jamie

That’s very true. Hey, you never know. In 20 years time, somebody might be writing a book about the history of .NET Rocks.

Richard

Yeah, that’s an interesting question and part of working on that book has been, “how much do I interject about making the shows?” Many of the conversations and connections come from making the shows in the first place. I’ve done a few live presentations about the history of .NET and I do interject moments from making the shows where, “here’s how this story ties into we actually made a show with that guy at that time.”

One of the classic ones is, “why did we make the tablet show?” There was this period from 2011 to 2014 where we made 130 episodes of a different show. And the reason is I’m happy to talk about today. I didn’t want to talk about it at the time because I thought we were overreacting, but we came out of the Build conference - the first one in 2011 - where they were talking about Windows 8 and Win JS and some very JavaScript focused and they really didn’t talk about .NET. And I looked at Carl and said, “what if .NET doesn’t rock anymore? What are we going to do if Microsoft is going to actually make this shift?” Not that they were saying they were going to, but all the hints were there. We were a bit freaked out about it. Plus, we were also struggling with at that time, .NET developers didn’t build stuff for iOS and Android and so forth, so it did it make sense to do those shows at .NET Rocks anyway. So lighting up the tablet show was our contingency plan. Here’s a place to put this content that I think is important, but doesn’t necessarily fit with a .NET Rocks theme. And if .NET is really going away, which we know now it didn’t do, but it seemed threatened at the time, we have another show to sort of fall back on, like that’s where we’ll end up putting all our energy into.

And then by three years, by 2014, it became apparent that iOS and Android development was just part of the .NET repertoire as well. It became hard for me to figure out what show should I do on .NET Rocks versus do on the tablet show? They were two the same and so we rolled them back together.

Jamie

Yeah. If you’re standing at the forefront and this this fork in the road is appearing yeah, you don’t want to place all of your eggs in the same I keep using loads of mixed metaphors today.

Richard

Well, and then that’s the whole thing is it was a contingency and it solved certain problems I was having in content planning anyway. And it was enjoyable. Like, it was fun to make another show and to pick up new advertisers and to build a new audience.

One of the side effects of being first is you have this huge audience because you were first. Could we actually build another show? We didn’t know the answer to that. Even with all the support we had, the numbers for the tablet show never got as big as .NET Rocks. It’s just not that easy to get new listeners. It’s a challenging thing, even for old guys. And so rolling it back in was just, why are we separating this? It doesn’t make any sense anymore. .NET is clearly thriving and tablet developers are .NET developers. So let’s just put this together. And then we consolidated the two shows together. So it’s just a sort of stamp of time. It’s 140 episodes still running over on thetabletshow.com

Jamie

And like you say, it’s part of the legacy of the .NET Rocks, I guess, family of shows.

Richard

Yeah.

And also, I think, a part of the story of .NET itself. The reason it’s interesting to write a book at this particular point is this light is shining very brightly on .NET where you’re in a good place, but if you don’t really know you’re in a good place unless you’ve been to a bad place. And so part of writing down the story is not only to capture that early history where I think we’re going to lose it soon, it’s 20 years ago, but also to talk about how dark it got because you don’t appreciate the light unless you appreciate the darkness.

So I don’t want to shy away from both aspects of what actually happened with .NET. And I am a little convicted as the storyteller because I was also there. I had my own emotional reactions to it, my own plans for business to it, but I’m trying to sort of take the middle road of what were we thinking? Why was it going this way? Was it unreasonable that focus on JavaScript at the time? And did .NET still make sense? I appreciate the idea that you need to question those things from time to time, because if you don’t, if you just presume that you’re right all the time, that it’s always been this way and it should continue to be this way, well, you’re going to get surprised one day when you’re really, really wrong.

Jamie

Again, it makes a lot of sense. And I think maybe the break from .NET to look at JavaScript and maybe focus on tablety things and stuff like that, I don’t know. There’s a lot of innovation happens in one specific technology, and if you spend all of your time there and you don’t look around, you don’t learn the other things that are happening in the industry.

Richard

Yeah, and 2011 was a very, very good year for JavaScript, because that was also when Chrome guys and the IE guys were going back and forth with the Chakra and V8 engines. Like JavaScript grew up as a language, I think, in 2011, and Node really took a hold, although it’d been around for a while. But that transition to maturing JavaScript that happened in the 2011 2012 timeframe, it was compelling. And it’s even today, looking at the end of 2018 at what you can do with JavaScript today, not just in the browser, on the back end with Node, on the front end with Electron. JavaScript has never been in a stronger place in terms of its ability to serve developers.

At the same time. Of course, with WebAssembly, we’re now looking at C# in the browser, and C# becoming cross platform and open source has just allowed us, if you love working in a statically typed, strong API type language, well, hey, here’s C# to help you. And you code a different way than you would in JavaScript.

You can make sustainable JavaScript. I look to the Angular guys, the folks that working at Google who use TypeScript to help enforce reliability in their JavaScript code. It’s just a tactic of how you write your code. You can be successful, John, any of these channels. You just have to follow the procedures that make sense for your toolset. I just don’t like the idea that we would ever be stuck with only one tool set. It makes no sense to me. If there was one right way, we’d all be doing it.

Jamie

Precisely. I always say that you can’t build a house with just a hammer. You need all sorts of other tools, and all sorts of other raw materials, and maybe even some prefabricated materials, but you need more than one tool.

Richard

I think it’s also people have a desire for certainty and confidence. You get really good with a hammer, and you want to kind of use it for everything. I think that’s part of the DevOps movement too, is that developers tend to solve problems with code. IT guys tend to solve problems with ACLs, DBAs tend to solve problems with constraints, and every one of those approaches can solve problems. The question is, is it the best way to solve that particular problem?

And when you have those three groups of people working closely together, and they share the problems they’re dealing with, often one of the three will nominate themselves like I think I can solve that problem best, I would do it this way, and maybe you’ll agree that it’s actually the right way to solve a problem. And the same comes with coding. These different languages are better at different things. And so if you actually appreciate the differences, value those differences, you actually make a better product.

Jamie

Precisely. There are certain things you can do pretty much anything, say in F# or in Objective-C, but like you say, there will be instances where it’s better to use, let’s say, Perl, because you’re actually at the server side and you’re doing something in the terminal.

Richard

Well, let’s not get crazy now, Jamie. There are very few cases where Perl seems like a good idea. Unless I really want to write code that nobody will ever dare change, then Perl. Right.

But I do appreciate your sentiment around F#. F# for the right problem is remarkably terse. The question is, is terseness an asset? Is it clear enough that somebody can look at that, grasp it and be able to work with it? What I was able to do in twelve lines of F# maybe takes me 50 lines of C#. But if more people can read that C# and understand it, then it’s more maintainable. That’s why I poke at Pearl, because Perl is remarkably a write only language, very, very resistant to reading.

Jamie

A lot of people that especially people who are new to development, I find, and the people who haven’t had a chance to read some of the great books of our industry, the Pragmatic Programmer, the Mythical Man Month, Code Complete, they kind of forget that we don’t write code for the computer to understand. That’s what the compiler does. We write code for the developers to understand, or other It professionals to understand, because it’s their job to maintain it and to make it better and to add new features. It’s not the compiler’s job to do that, it’s other humans. So I think Steve McConnell actually calls it our primary directive as developers is to write code that other people can read and understand.

Richard

And I lean heavily on this concept called ontological humility, which is don’t presume that the way you’re thinking is the only way or the right way to thinking that new people that are going to look at your code in the future are going to think differently. And if you can help them to understand what you’ve done, and if they have the humility to acknowledge that you did the best you could with the skills and knowledge you had at the time, knowing that later on there will always be new knowledge and you’ll perceive things differently. We respect the code that we wrote before and we sustain it, we find ways to maintain it. You just don’t automatically look at any piece of code and say this needs to be rewritten. If it works, even with its rough edges, it’s still worthwhile precisely.

Jamie

Just because some code already exists, it doesn’t need to be refactored or rewritten.

Richard

Well, code that always exists is automatically more valuable than code in your head because the code that already exists does something. The code in your head is really just noise.

Jamie

That’s true. Yeah. I really like this conversation. It’s getting incredibly philosophical all of a sudden. I like it.

Richard

I’m afraid I’m getting old, Jamie. All I have left is philosophy. Can’t do any real work anymore. Nobody lets me type like that.

Jamie

Maybe that’s what we need. Maybe we need a renaissance of the bearded developer, the wizened, travelled, experienced developer who can sit there and say, yes, here is how you should do it. And I have years of experience that prove it. I know you’ve just come out of your code camp or you’ve just come out of school and you think you’re the best, but I was like you once and deal with my experience.

Richard

Yeah, I do think there’s an art form as you have more experience to allow people room to actually learn empirically. There’s a power to actually stubbing your toe rather than warning you that you’ll stub your toe. As long as it’s not crippling, it doesn’t hurt the business and it definitely doesn’t hurt the person. Empirical data is the best possible teacher, and so I often will give room for that.

Also am very aware that much of my wisdom is scar tissue of an earlier age. And so I have someone who will approach a technology that maybe burned me ten years ago and I got to push back on my visceral reaction to that because it was ten years ago. Maybe it’s different. Just because it hurts you once doesn’t mean it’s still going to hurt you. Maybe lay a few cautions in there, but certainly don’t say no because, you know, you’re not the sole possessor of all knowledge. All you really have is a bunch of scar tissue. And if it informs you to make better decisions, that’s great. But if it stops you from trying new things, that’s not great.

Jamie

That is true too. Now you’ve got me thinking, I don’t know anymore.

Richard

Yeah. And that’s sort of the joke. It’s like the more experience I have in this, the more I’m aware I know nothing.

Jamie

Maybe that’s it. Maybe we all know nothing.

Richard

Yeah.

Well, once you sort of embrace that, a, there’s lots of room for us to get better and a willingness to allow mistakes and room for improvement and some kindness for the blunders that happen, for the toes that get stubbed. It’s like, yeah, been there, sucks. Let’s go do better next time.

Jamie

So in that is, I realize we’ve drifted entirely away from .NET, but I do have a question on that then.

Richard

Of course.

Jamie

So in that case, if you had a new developer, junior developer, someone who hasn’t as much experience as you, and they are using something and you know it’s going to end in failure. Do you stand back and let them fail? Or do you kind of step in and go, I don’t think that’s going to work here’s? Why? How do you approach that?

Richard

And like I said, I do appreciate that there’s value in empirical data, but if somebody’s going to run over a cliff, you don’t actually want them to die, right? Or if it’s going to impair the business. Like, we are on a deadline here and you’re not going to make it if you go down that path. I’m probably going to push a little harder, but I would rather you saw the edge of the cliff rather than me tell you it was there. So I’m going to have some conversations with you about keep a close eye out. There’s danger afoot and have them own that thing.

But no different than raising children or training a dog or any other thing where the more they understand, the better off they are. To actually allow them to see the edges and the dangers and the risk. And to stub toes rather than go off cliffs is to learn more. And you never know. Sometimes you believe that there’s a toe stubber over there and there actually isn’t. You’ve got old experience, not current experience. Time goes by, tools change, methodologies improve. And suddenly that thing that was a really risky way to build code may not be actually that risky anymore. That was last year’s problem, this year it’s fine.

Jamie

First of all, that was an amazing conversation and thank you for that.

So the, the reason I’ve, I’ve asked you to be on the podcast is because I would love to talk to you about a little bit of the history of .NET.

Richard

Sure.

Jamie

Because I know that you’ve been quite vocal about the fact that as you said earlier on, you’re writing a book on the history of .NET. And I believe there was an episode of .NET Rocks where you said it may end up being several books or they may be some companion books just because there’s that much information.

Richard

Well, and I also have come to appreciate that .NET is different things for different people.

So I’ve had conversations where with someone who’s worked in .NET for many, many years, but they’ve always been a web developer and so their relationship with .NET is ASP .NET. And maybe they did some time in webforms and they did some MVC and they tied in with Entity Framework, but that’s their view of .NET. But then you spend time with someone who’s a client developer for how they came from. Visual Basic, working in the early versions of WinForms, moved over to net, but they’re still a WinForms developer. And they may or may not have gotten involved in WPF, but they’re a client side developer. That’s their experience. That’s their relationship to .NET.

And the same for Mobile, Windows Phone, the modern one certainly had a bumpy life. But we talked to folks back in the [Windows] CE era too that were building stuff in Mobile. The Windows Phone Seven was actually a variant of Silverlight, so a lot of Silverlight folks jumped over there, but Eight was substantially different and ten different again. So there’s a story there as well in Compact framework, some of the early IoT stuff. Like there’s a lot of different aspects to .NET. It is too broad a product and I want to make something readable. It can’t be War and Peace. I don’t want this Titanic book, it doesn’t serve anyone.

But I also want to be to honor these different aspects. So I’ve come to appreciate the idea that perhaps what I need to do is not dive deeply into any of the aspects of technology in .NET. And more talk about the story of .NET, which is this product originally built to support enterprise developers consuming Windows and then evolved away from that into this. You think about February of 2002 when .NET is announced and literally the tagline is, “22 languages, one platform,” which was the counterpoint to what Java’s marketing was, which was, “every platform, one language.” That’s where .NET began. And now look today at this cross platform, open source product. It’s not anywhere near the same product. What happened? How did that happen? That’s kind of nuts.

And that’s the story that I’m revealing bit by bit in all of the research. And it’s been about we’re recording this at the end of November, it’s been about a year of doing interviews and I have about 65 to 70 hours now of interviews done with various people both inside and outside of Microsoft about their experiences building .NET. And I’d not done. There’s still much more research to happen. So it’s going to be a little while longer.

But the meat of that is large enough to recognize I can just tell that political story and it should be an interesting book. And then the companions could be, how about a book about web development in the Microsoft stack that goes all the way to active server pages and InterDev as well as up through .NET itself. And the same for client side development. So it’s a way for me to manage myself, to not put too much into the book, but to say there’s a place for each of those things if we can do them all.

Jamie

Wow. Okay, so is this going to be The Art of Programming by Knuth? Is it going to be a multiple volume, decade long project?

Richard

I would never, ever compare myself to Donald Knuth for no other reason than the man helped us figure out how we are programmers. I am a storyteller and I am collecting stories to help people understand how we got here. And I think it’s a very different thing.

I think it’s valuable. I would love to read this book. So I guess I have to write it. I think I’m well positioned to do the writing part, but I am telling stories of others, not myself. Donald Knuth led the industry that is development and his stories are a proper inspiration for how we should be as developers. And, yeah, I’m not going to do that. I don’t think they’re the same thing at all.

Jamie

So it’s more like sort of like the old Norse mythologies where people are sitting around a campfire or sitting around a podcast recording.

Richard

Yes.

Well, I think if there’s anything I’m going to do is to let people know. Again, going back to that concept of ontological humility that consistently in all of my research, in everything I’ve seen, all of these people went to work each day trying to make a better product, trying to make a better world, and fought what they believed was a good fight. And their decisions were rational, even if it wasn’t apparent that they were rational to the rest of the world.

And so to be able to pull back that curtain a bit and say, here’s how that decision actually came to pass, why things worked the way they did. There’s some painful moments in .NET history for the average .NET developer who never was an MVP or ever worked closely with Microsoft, never really saw behind the curtain in their own opportunity. And if there’s anything I can do is to let that person know. You remember when you were frustrated with what happened to Silverlight? It was a frustration because it just sort of stopped. There was never an explanation, there was never an announcement other than what happened in the news where there were articles saying, Serverlight is dead. Microsoft never said a thing. Why? What happened? I haven’t got the whole story, but I’ve been able to talk to folks that were there and sort of pull back some of the pieces of what was going on at the time.

Jamie

It definitely sounds like it’s going to be a book that I would want to read at the very least. I’ve been doing a lot of looking back to the history of computer science and computer programming and development and how we went from what is ostensibly a science to a sciencey arty sort of engineeringy.

Richard

I consider software development engineering, and there’s plenty of art in engineering, but building a bridge is an engineering exercise. Goal number one is to safely transport humans and machines across the river. But it doesn’t mean that the bridge can’t be beautiful, it just can’t be beautiful at the expense of its ability to safely transport people across the river. Software can be beautiful, but first it must be functional. We’re an engineering discipline. We just haven’t been able to become proper engineers.

Jamie

I like that. I think I’m going to use that from now on. I hope you don’t mind.

Richard

Not at all. I’m here to persuade.

Jamie

That’s it. Isn’t that what we all are here for. I don’t know.

Richard

to some degree, I think. But there are all these ideas I’m struggling mightily with a title for this book because the one thing I know for sure is Historyof .NET is not a great title. Even if that’s actually what it’s about.

Jamie

I’m afraid I can’t help you there. I’m not very good with titles for things.

Richard

It’s the hardest thing and I think it’s one of the things that comes very, very last. You’ll know it when you see it, when the right title appears, but it just hasn’t appeared to me. Every time someone suggests something, I write it down. I just add it to the stack and see if I can one of them will someday reach out to me and go, yes, this is the thing I want.

Jamie

You never know, it might be the final sentence that you write as part of the book and go, that’s it.

Richard

Yeah, maybe that’s it.

One of my favourite stories around titles is how we actually named Run as Radio, which was the IT podcast that I do. It’s such a good name, everybody gets it, it’s totally apparent. But how do you get to that name? And I’d been working on making an IT podcast for a while and Carl and I had been going back and forth and we were brainstorming names. The same thing. No idea is too dumb. Just write it down. And then we’d go through all the names. We sort of have a session over the phone for an hour arguing about the merits of each name.

And one day after the end of one of those arguments, I’m like, Dude, we’re still nowhere. We’ll go through this brainstorming cycle again and we’ll see if we get better. And he was like, all right, I’ll talk to you later. We hang up the phone and within 30 seconds he calls back and I pick up the phone. I’m like, did you forget something?

And he goes it’s run as Radio. I’m like, There it is. That’s the title. It’s just so apparent when that moment hits.

Jamie

So what you’re saying is I need someone to bounce ideas off like my Lenin or my McCartney.

Richard

Anytime you’re trying to come up with something like that, the core brainstorming technique of just write down every idea, no matter how wacky it might be, and then let it sit for a while and go back and read through them and argue them and see what next generation ideas like that brainstorming strategy. It’s the only thing I’ve ever found that finds this kind of thing.

Jamie

I’ll have to do that for maybe not all of my variable names, but maybe some of them.

Richard

Naming is hard and we name stuff a lot in software far more than the average person ever names things. Software developers name stuff constantly and it’s really difficult.

Jamie

That’s very true.

I know that we recently had I say we I recently had a conversation with Steve Gordon. Yes, and I was talking to him a little bit about the humanitarian toolbox. Perhaps we could discuss the humanitarian toolbox a little bit, if that’s all right.

Richard

For sure.

Directly related to .NET Rocks. The origins of humanitarian toolbox come from the .NET Rocks Visual Studio 2012 road Trip.

So going back as far as 2005, carl and I were able to rent an RV and drive across the United States making stops and talking about the new version of Visual Studio. And so the biggest of these turned out to be the 2012 one in hindsight. So we knew it was going to ship in the fall of 2012. And so during the summertime, I think it was in July, and I actually still have my original one note notes from this meeting. I’m talking to some Microsoft folks who are going to provide sponsorship money so that we can rent the RV and pay for things. And we put logos on the side of the RV so we kind of look like a NASCAR driving from city to city. And in the end, the 2012 road trip was 34 stops in 13 weeks. It was a beast.

But it was the Microsoft folks that said there should be a charitable element to the tour. Can you come up with a way to include some sort of charitable element to the tour? And I think if I’d had any brains, I would have taken the easy way out and simply said, how about matches, dollar for dollar for kids who code, something like that. It would have been the easiest solution. But instead I went on a bit of a rant of how frustrated I was with how hard it was for software developers to donate their time as coders to a charity. Because code is never free. If you write Core for someone, they have to live with that code. Code is free like a puppy is free. You have to clean up after it, you have to maintain it. Software lives, it needs work.

And so I think most software developers understand this. And when given an opportunity to support a charity with code, they also recognize that it’s a permanent commitment, that you have to keep going back and keep contributing and keep doing work on it. And many folks are just like, I can’t make that large of a commitment. I have too many things going on. And so they resist doing that. I’ve seen codathons weekend coding sessions to support a charity where they’ll build a brochureware website, which is a great idea, but again, the charity has to live with that software. At the end of the weekend, the software developer gets to go home, but the charity actually, there it is. They now have this app with whatever problems it may have, whatever maintenance it needs, and you may or may not be able to get that same developer back. And getting a different developer on that code is even more difficult. And it was a sprint of code, it was a weekend. What kind of code are you going to write in a weekend?

So with those things in mind, knowing that developers do want to donate their time to charity, do want to do good with their software, why does open source exist the way it does? Often the software we write at work is not our passion project. You can only do so much forms over data where you’re like done it, but if it’s paying your bills, you keep doing it, you are good at it, you are valued in that, but it’s probably not your passion project, which is often why we end up in open source writing things that mean more to us. But could you do that as a charity project as well?

And the challenge of course is that software is more than the code that is written. It is the project management parts, it is the planning of features and the writing of user stories and hopefully the organizing of tests and then giving a space for programmers to work and how do you care and feed for the app? And that was really the essence of humanitarian toolbox was this what if we did all the other things so that volunteer developers could sit in a place where they knew their code could do some good? And it would be properly cared for so that they can put in their volunteer hours and then walk away with a clear conscience when they have to do the next things in life that matter to them. And that started to work. It took us a few years to figure out how to do it right.

We chose disaster response because it was an equal opportunity problem. Disasters happen everywhere in the world. Everybody needs help in it. They’re technologically unsophisticated. So there’s lots of opportunities to introduce mobile and cloud and techniques that we know how to use to actually improve their ability to respond to these things. And it was something that every developer could relate to, whether it was a tornado or a hurricane or an earthquake or a typhoon. Pick your disaster. We could make a difference here with software. And so that has been the mission.

And I thought it was a good enough idea at the time that I literally just went looking to see who’s already doing this because we’ll just support them. And I found pieces of organizations and different bits and we started connecting with them and looking at how they were working, knowing we would be able to recruit, knowing the one thing we had in our pocket through stuff like .NET Rocks was the ability to reach developers and encourage them to be a part of things. So it took time to figure out the right way to do that. And ultimately we ended up creating a 501-C3, an American charitable entity. And that provided mechanisms for us to receive grants and to do tax credits. We’re looking at certifying in different international spots. So like become a UK charity as well, or Canadian charity as well. But the ability to get developers up and running, that worked. Folks wanted to work on these things. We found some great projects and we were able to make contributions.

Jamie

The humanitarian toolbox is a large collection of is it mainly open source? Is it completely open source?

Richard

Yeah, we’ve pretty much gone totally open source. And there’s a few reasons why not only does it generally make software developers more confident that we’re not doing a for profit thing, sneakily on the side, it’s like, hey, all the code is in GitHub. I also don’t have to pick which charities get to use the code. It’s like, dude, the code’s on GitHub. Feel free. Right? github.com/htbox. You want a copy? Fork it, go, take whatever you like so I don’t have to pick a winner. There’s no need to do any of that. I get to work with whoever wants to work with us and work on the projects that make sense, take contributions from different sources. It just solves a ton of problems to just be open source.

Jamie

So literally anyone can contribute something?

Richard

Absolutely. There are work items sitting there waiting for folks to pick up. We do have a few sort of beginner items still, so if you’re jumping in for the first time, there’s stuff there. They’re certainly always looking for good tests. So folks that want to work on the testing side, there’s plenty of issues in the various projects there. So you got to pick what you want to work on and what inspires you and grab an item and run with it.

Jamie

I see, Ffantastic. I’ll be sure to put links in the show notes to all of these.

Richard

Things because thanks, I appreciate that.

Jamie

You’re very welcome. That at the very least is something that, like you say, it’s something that we can all give back to and we can all help out with.

Richard

Plus feeling good about writing code. It’s not just work, will code for food. We often forget as software developers this the impact that our software can have. We make companies remarkably more productive. The idea that we’d also work with disaster relief workers or volunteers and make them more productive too, it’s just more of the same. But often we’re so enamoured of our technology, we often ignore the business ramifications of doubling productivity, of just saving time.

The already projects, which is one of the HD box projects initial implementations was focused on a Red Cross initiative for putting smoke detectors in homes that didn’t have them. And the early stats when they were doing this, the manual way where they set up a stand at a home improvement center and take down names and eventually get enough together that they could send out qualified installers that were the volunteers to install them. Typically it would take a few months to get that whole thing together. And the day that that person could volunteer their day, it’ll be a Saturday. They’d send them out with eight smoke detectors to install the with eight addresses and people weren’t home or they’d forgotten about it, they wouldn’t let them in. And so often they’d only get two or three of the smoke detectors installed. When we were doing the first trial runs using the software, so that we were now utilizing social media to do the campaign. So we’re gathering names faster. We were able to ship out the smoke detectors to the volunteers that didn’t have to go to a central location.

We’re using mobile apps so that they have the GPS stuff already sorted out. We tied in Twilio so that on their way to each location, they were able to call ahead automatically. And now we were getting 70-80% of the install successfully. So we used that volunteers time more efficiently and ultimately protected more homes. That’s a real world consequence for what was not a terribly complicated piece of software. If you think through what that is about organizing volunteers and using GPS data to coordinate things and a little bit of SMS on the side, it’s not rocket science, it’s just the right piece of tech in the right place. But its result is I think we saved some lives. I don’t want anybody to have a house fire, but if you’re going to have a house fire, have a working smoke detector. And if we were responsible for getting that smoke detector in that house, well, we saved those people that day.

Jamie

Yeah, I don’t think I’ve ever thought about it like that.

I know that there’s a few of us that get together. So there’s a friend of mine, Paul Seal and James Studdart, who and I mentioned earlier on together and go to random hackathons. And we went to one this year in a city called Nottingham in the UK. And when we were there, they were asking for do something to help the people of Nottingham. And we came up with a system that allowed people to walk around and, “oh there’s a vulnerable person in need. And for some reason I’ve got my phone, but I can’t make a phone call.”

Richard

Right.

Jamie

Well, I can use this app to then let whichever emergency services or the local council know there is someone vulnerable in this place, in this GPS coordinates. And this is what I can observe. This person is maybe laying in a street doorway and it’s raining and it’s not very nice out. They’re obviously looking for somewhere to stay. I can’t help them, but I will let someone know who can.

Richard

For sure. And who makes phone calls on their phones anymore anyway. Like putting it into the app model connects it with the modern mobile phone consumer. So they’re far more likely to do that than they would to ever make a phone call.

Jamie

Precisely. I mean, that whole competition was a 24 hours, like a hackathon. So it was along the same lines as what you mentioned earlier on. So the code wasn’t brilliant, and if we had actually shipped it and send it out to real people, it would have crashed a couple of times. And the system wasn’t set up for load balancing and all that kind of stuff because it was 24 hours. We just had to build a prototype.

Richard

Right. One of the mantras I’ve always had with HT Box is let us not do adrenaline fuelled programming. Let us do sustained engineering over time so that we are proud of the software we wrote, that we do have time to go back and improve it, and to sustain it because it needs to keep getting better. And I think that’s a very different model. It’s not as exciting, but it is ultimately making better code.

Jamie

Yeah. Let’s take a step back and really consider the actual ramifications of system performance using this particular pattern or this particular library, and maybe what’s the support like for this library or this pattern? If the original developer decides to give up and pass on maintenance to someone else, does that mean our app will suffer?

Richard

Yeah. Well, how well have it worked? And I think it’s one of the things that we’ve worked really hard on at HT Box is recognizing that every developer is a volunteer. Nobody gets to be in the critical path because you need to be able to go home. And so documentation is incredibly important, tests are incredibly important. Everything I can do to allow a new volunteer to step in on any aspect of that project and to understand where that developer got to and what that was about is important. And so it’s what it takes to make really sustainable software.

Jamie

So I guess the last few things I’d like to ask if that’s okay if we shift slightly away from HT Box because, you know, it’s a very important project, but you know, I just want to shift slightly away from it a little bit.

Looking at you’ve had this dual wonderful position where you’ve seen the evolution of .NET as a first person event and you’re able to now obviously look back and listen to other people’s opinions on what happened and their different perspectives and all of those kinds of things, collecting all of those stories. How do you feel that or do you feel that the .NET ecosystem, maybe the community or the way that the software is built these days, have you seen it change much? Has it changed radically? Has it changed for the better, for the worse, in your opinion?

Richard

Well, we’re living in a dichotomy in the .NET community right now, where all of the incumbents, the original .NET users, many of them are still there and still happy with the standard .NET, live in a Windows world. And so a lot of the work that’s gone on around Core has not been relevant to them.

Maybe they’re not web developers, maybe, perhaps they don’t care about the fact that it runs on Linux or that it’s open source for that matter. I’m still meeting companies on a routine basis where their company policy is no open source code. That’s not an option. And so they have not looked at Core at all. And I think it’s very expensive for Microsoft right now to essentially be building two versions of .NET, the ongoing development of the standard framework, which is also compliant with .NET Standard and then .NET Core.

So it’s been several years, the .NET Core first ship in 2016, so now a couple of years in. I think the weight of these two lineages are starting to show and that the moves you’re seeing around Core 3 are about trying to bring the community closer together. Adding the Windows SDKs that run on top of Core 3 so that you’ll have a WinForms and a WPF, which may not be cross platform or open source, but are designed so that an existing .NET application built against the the standard Framework could be lifted and shifted and just run with Core 3 and the Windows SDKs on top of it. I think that’s super important and it’s a movement towards bringing together the community under a single umbrella of .NET.

And I’ve certainly seen this in conversations in the show and with listeners that there’s concern for that split, that there’s the Core folks over there and the standard folks over there and they are not going in the same direction. And I think there’s an effort at Microsoft to end that, to get them together in the same place. I don’t think it’s going to happen immediately, but I’m appreciative that we’re moving in that direction.

Jamie

I can agree that I think it’s not going to be an instantaneous step to sort of bring the communities together because like you say, we have two years of public builds of .NET Core and maybe three, four, five years prior to that, of actually building and prototyping it versus 20 years of here is Framework. This is definitely always going to run on Windows. We can make promises about how it’s going to work and it’s got to be backwards compatible and it’s got to be able to do X, Y and Z as well as A, B and C. Whereas Core, they can kind of go, no, don’t need that API. No, don’t need that, no, don’t need that. If they wanted to, they don’t have to, but if they wanted to, well.

Richard

And you’ve also got a new class of developer coming into Core that never use standard and just think about it completely differently. And so it’s kind of a confusing time, I think, for a lot of folks, especially ones that have been involved with .NET since the early days, that they’re just, who are these people?

I’m excited about what’s coming, knowing I’m still a year away from putting the book out - I expect - that by a year from now the story is only going to get better, that we’re only doing more. If there’s any epilogue, I think, to talk about it’s the fact that there is this dichotomy, there is these two worlds, and how we get those worlds, hhe mission of getting those two worlds closer together is a worthy mission, a positive mission, and maybe it’ll be done by the time the book’s done, maybe it won’t be. But I’d like to end with future looks bright.

Jamie

Let’s hope that we can do that. I do know that over here in the UK, certain public sector and enterprises, they won’t touch it, like you say, they won’t touch anything open source. And they have this stack of hardware from maybe 15 years ago that is running all of their critical business line applications and you have to slot whatever you’re being contracted in to make you have to slot that into that whole setup. And I think especially with the point that you made about the newer developers coming into .NET Core never having lived that, being able to slot into that ecosystem is going to be quite difficult, I think.

Richard

Yeah, absolutely.

But I think it’s achievable. I think everybody wants to be together. I don’t think anybody wants to feel, quote unquote, left behind. Not that I think that Microsoft is leaving anybody behind, but that you do have a split in innovation going on and there’s actually more divisions than that. The windows side of things with UWP, that was actually a different build of .NET. And with the reorganization of windows, I think part of the thing that’s going to happen there is that we’re going to consolidate more of the .NET world into a common version so that we have more confidence that it’s going to work the same way across the board.

I think we’re not dumb with Xamarin integration yet that all of the things that was built by Miguel and he boys, it needs to be improved and needs to be part of a whole. I think there’s a vision there of truly a one .NET that works for everyone. I don’t know all the twists and turns that it’s going to go through to get there, but I think it’s a worthy goal. People wonder if there’s anything more to do and it’s like I feel like it’s a big stack to do here. We’re nowhere near as good as we could be.

Jamie

I think what we need to try and remember, as well as a community, is that the .NET, the ecosystem, the technology stack, all of the different levels that are involved in this. This is one of the biggest engineering efforts in history, I guess, at least in the tech space, and that things are naturally not necessarily going to go wrong, but there’s going to be a lot of hindsight and looking back on things and going, actually, maybe we could have done that better.

Richard

Sure.

But hindsight’s always got better vision. And certainly part of writing the history book is showing the twists and turns of the path we’ve already been through. What’s fascinating to me is that it has lasted as long as it has. I remember folks talking years ago about, “so what comes after .NET?” And the fact that we’ve completely transformed we the fact that Microsoft has completely transformed .NET, but literally as a rewrite in the past few years is astonishing. Rather than just making something completely new to carry that forward.

Jamie

One or two last questions and then you can go off and enjoy your day. Of course I’m sitting here in the dark because it’s 07:00 p.m. And that’s what happens in winter.

Richard

Yeah, it’s eleven in the morning here in west coast of Canada, and it’s not that bright outside either. It’s dark and gray and rainy.

Jamie

Okay, so the last few questions. Obviously folks who are listening to this are going to know who you are, but let’s say that they want to find out more about the humanitarian toolbox or the work you’re doing, or Run as Radio or .NET Rocks. What’s the best way that the can sort of catch up?

Richard

Yeah, I’ve kind of spread around. I don’t have a one central home page for any of those things. I hang out on Twitter a lot, so @richcampbell is an easy way to reach me. And certainly you look at my bio on Twitter, it says .NET Rocks dotnetrocks.com, runasradio runasradio.com and humanitariantoolbox. Which if you can spell humanitarian, that’s great - humanitariantoolbox.net, if you can’t htbox.org is the easy way to get there. Or if you’re comfortable on GitHub, github.com/htbox, and you can look at the projects, and look at the work items, and come be part of our team.

Jamie

So would you recommend that anyone who is interested in helping out with Htbox, they can literally just have a look at GitHub, choose an issue, maybe raise a comment on it and say, “hey, I’d like to take this, have a discussion with people,” and then just do it?

Richard

Yes, please. Before you write any code talk on the work item that you’re interested in, let the project managers engage with you and get a picture for where we’re going and what we’re thinking. And if you don’t have cycles to do coding, or if you’re not a coder, we take donations. We are a 501-C3. If you go to Htbox.org, there is a Donate Now page. Every bit helps. We largely spend the money on project management, so we’ve come to appreciate that professional project management is necessary to keep all of our volunteer developers productive. If you qualify, if you’re in the US or you have, like Canada does, a treaty for allowing charities to cross over, it’s tax deductible.

Jamie

So just real quick, is the technology stack htbox .NET, or is it pretty much anything goes?

Richard

There’s a variety of different texts and different projects, so it’s what makes sense at the time with the volunteers that we have in place. So in the case of the Already project, it is a .NET Core project, but there are others that are not. So you pick and choose what you prefer to work in, what tech stack we prefer to work in, and what project means the most to you.

Jamie

I see. So literally, almost anyone can help out.

Richard

Absolutely. And like I said, there’s lots of ways to help out. We have had the good fortune to work closely with testing conferences that will run competitions for finding the most bugs in our software. So often we’ll get dumps of tests and reports for certain projects because they use that as a sort of charitable initiative to try and make our software better. There’s lots of different roles for making a great piece of software that makes a difference in the world.

Jamie

Well, like I say, I’ll make a point of putting all of these links into the show notes and trying to drive people to that because it’s the most worthy of all causes I’ve ever heard of. For sure.

Richard

I appreciate that. Thank you, Jamie.

Jamie

I mean, I’m not sure whether all three of the listeners are going to be able to help out, but I’ll try.

Richard

Shows live forever, Jamie. You never know who’s going to hear it.

Jamie

That’s it.

Well, that’s all the questions I have. So I just want to say, Richard, thank you ever so much for taking time out to talk with me today. I realize, obviously there’s a huge time gap between yourself and me, and obviously it’s cutting into your daytime.

Richard

My pleasure, Jamie. And isn’t it amazing? We live in a world where halfway around the world, we can have a conversation.

Jamie

It really has been an amazing conversation. I’m going to totally enjoy editing this because I’m going to learn so much the second time through, if I’m honest.

Richard

I appreciate that. Great to talk to you.

Jamie

Thank you very much, Richard.

Richard

Thank you.

Wrapping Up

That was my interview with Richard Campbell. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and a collection of text snippets from the interview. The show notes, as always, can be found at dotnetcore.show.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice, and to come back next time for more .NET Core goodness.

I will see you again real soon. See you later folks.

Ontological humility is the acknowledgment that you do not have a special claim on reality or truth, that others have equally valid perspectives deserving respect and consideration. There are many ways to look at the world, and each way has its bright and its blind spots. Only from the perspective of ontological humility can you accommodate that diversity and integrate it into a more inclusive view.

This is a quote from Conscious Business: How to Build Value Through Values which helps to describe ontological humility.

Follow the show

You can find the show on any of these places