Episode 18 - The History of .NET with Richard Campbell

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

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

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

I appreciate that. I think the only thing we’ve done right is that 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 any time soon.

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, then ditch those five because they’re going to be terrible. 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 voice soon.

Yeah, I would agree. Firstly, don’t throw anything away. Your legacy is important too, and I think listeners appreciate that you’re evolving.

Honestly, we’ve dialled the professionalism down a little on .NET Rocks. In the early days we really looked at ourselves as radio and wanted everything to be perfect, and we fixed every little thing. I think more people are comfortable with the fact that there are mistakes in audio, so we’ve left in things that we thought were funny but were mistakes. I think it makes it a little more personable. We’re in an era now in podcasting where that familiarity is almost more important than perfection.

I would definitely encourage you to leave things in, but don’t waste anyone’s time. If I’m looking for a note, or I have to double-check a fact, I’m going to edit that out. If you fumble on something and it’s a humorous outcome, that’s real life. I think people appreciate hearing that we’re not as perfect as the audio engineers make us seem, that we’re human, that there are real, normal human things in there. Warmth and reality, truth, is more important than perfection.

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.

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.

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, where we’re actually making it easier to listen to the show.

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

Yes.

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

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 it. What everybody really wants is that sense of a conversation.

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

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

I may have to emulate that for this episode.

Well, feel free. Everybody needs to learn more anyway, right? Anything we can do to make it easier to learn. Making people comfortable so that they can 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.

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

Well, after a couple of thousand podcasts you get a feel for some things, although admittedly the industry has changed several times since Carl started out in 2002. Being old in this is not automatically an asset. I also struggle with, “are we dinosaurs?” We have a lot of behaviours that aren’t relevant any more, because technology has evolved, the audience has evolved, and the perception of podcasting has evolved too.

I suppose that is a difficult line to balance.

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, that you can only make so many things, and that if you’re not still passionate about it, there’s just no point.

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

Yeah, that’s an interesting question. 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: here’s how this story ties into the fact that we actually made a show with that person 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. The reason is something 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 WinJS, very JavaScript-focused, and they really didn’t talk about .NET. I looked at Carl and said, “what if .NET doesn’t rock any more? What are we going to do if Microsoft is actually going to 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, at that time .NET developers didn’t build stuff for iOS and Android and so forth, so it didn’t make sense to do those shows on .NET Rocks anyway.

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. If .NET is really going away — which we now know it didn’t do, but it seemed threatened at the time — we have another show to fall back on, somewhere we’ll end up putting all our energy.

Then, three years on, 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 which show I should do on .NET Rocks versus The Tablet Show. They were the same, so we rolled them back together.

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

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

One of the side effects of being first is that 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.

Rolling it back in was just, why are we separating this? It doesn’t make any sense any more. .NET is clearly thriving and tablet developers are .NET developers, so let’s put this together. Then we consolidated the two shows. It’s a stamp of time: 140 episodes, still running over on thetabletshow.com.

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

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 that this light is shining very brightly on .NET. You’re in a good place, but you don’t really know you’re in a good place unless you’ve been to a bad place. 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.

I don’t want to shy away from both aspects of what actually happened with .NET. I am a little conflicted as the storyteller, because I was also there. I had my own emotional reactions to it, my own plans for business around it. I’m trying to take the middle road of what were we thinking? Why was it going this way? Was that focus on JavaScript at the time unreasonable, 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, you’re going to get surprised one day when you’re really, really wrong.

Again, it makes a lot of sense. I think maybe the break from .NET to look at JavaScript, and to focus on tablety things and stuff like that… I don’t know. 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.

Yeah, and 2011 was a very, very good year for JavaScript, because that was also when the Chrome guys and the IE guys were going back and forth with the Chakra and V8 engines. JavaScript grew up as a language, I think, in 2011, and Node really took hold, although it had been around for a while. That transition to maturing JavaScript that happened in the 2011–2012 timeframe was compelling. Even today, looking at the end of 2018, at what you can do with JavaScript — not just in the browser, but on the back end with Node and 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. C# becoming cross-platform and open source has allowed us… if you love working in a statically typed, strong API type language, well, hey, here’s C# to help you. You code a different way than you would in JavaScript.

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

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.

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

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: I think I can solve that problem best, I would do it this way. Maybe you’ll agree that it’s actually the right way to solve the problem. The same comes with coding. These different languages are better at different things, so if you appreciate the differences and value those differences, you actually make a better product.

Precisely. 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 at the server side and you’re doing something in the terminal.

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?

I do appreciate your sentiment around F#, though. 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 12 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 Perl, because Perl is remarkably a write-only language, very, very resistant to reading.

A lot of people — especially people who are new to development, I find, and 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 — 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 the other IT professionals to understand, because it’s their job to maintain it, to make it better, and to add new features. It’s not the compiler’s job to do that, it’s other humans. I think Steve McConnell actually calls it our primary directive as developers: to write code that other people can read and understand.

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 of thinking, and that new people who are going to look at your code in the future are going to think differently. 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, then 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. Just because some code already exists, it doesn’t need to be refactored and rewritten.

Well, code that already 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.

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

I’m afraid I’m getting old, Jamie. All I have left is philosophy. I can’t do any real work any more. Nobody lets me type.

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, so deal with my experience.”

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

I am also very aware that much of my wisdom is scar tissue from an earlier age. Someone will approach a technology that maybe burned me ten years ago, and I have to push back on my visceral reaction to that, because it was ten years ago. Maybe it’s different. Just because it hurt 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’re not the sole possessor of all knowledge. All you really have is a bunch of scar tissue. If that informs you to make better decisions, that’s great, but if it stops you from trying new things, that’s not great.

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

Yeah, that’s the joke. The more experience I have in this, the more I’m aware I know nothing.

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

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

I realise we’ve drifted entirely away from .NET, but I do have a question on that, then.

Of course.

If you had a new developer, a 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 step in and go, “I don’t think that’s going to work, here’s why”? How do you approach that?

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 — 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. I would rather you saw the edge of the cliff than have me tell you it was there, so I’m going to have some conversations with you about keeping a close eye out. There’s danger afoot. Have them own that.

It’s no different from raising children, or training a dog, or anything else where the more they understand, the better off they are. Allowing them to see the edges and the dangers and the risk, and to stub toes rather than go off cliffs, is to learn more. 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 actually be that risky any more. That was last year’s problem; this year it’s fine.

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

The reason 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.

Sure.

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. I believe there was an episode of .NET Rocks where you said it may end up being several books, or that there may be several companion books, just because there’s that much information.

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

I’ve had conversations with someone who’s worked in .NET for many, many years, but they’ve always been a web developer, so their relationship with .NET is ASP.NET. Maybe they did some time in Web Forms, and they did some MVC, and they tied in with Entity Framework, but that’s their view of .NET. Then you spend time with someone who’s a client developer, who actually came from Visual Basic, working in the early versions of WinForms, moved over to .NET, but they’re still a WinForms developer. They may or may not have got involved in WPF, but they’re a client-side developer. That’s their experience, that’s their relationship to .NET.

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 who were building stuff in mobile. Windows Phone 7 was actually a variant of Silverlight, so a lot of Silverlight folks jumped over there, but 8 was substantially different, and 10 different again. There’s a story there as well in the Compact Framework, and some of the early IoT stuff. There are 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.

I also want to honour 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 instead talk more about the story of .NET: this product originally built to support enterprise developers consuming Windows, which then evolved away from that into this. 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. 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 nuts.

That’s the story that I’m revealing bit by bit in all of the research. We’re recording this at the end of November, and it’s been about a year of doing interviews. 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. I’m not done; there’s still much more research to happen, so it’s going to be a little while longer.

The meat of that is large enough to recognise that I can just tell that political story and it should be an interesting book. Then the companions could be: how about a book about web development in the Microsoft stack that goes all the way back to Active Server Pages and InterDev, as well as up through .NET itself? The same for client-side development. 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.

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

I would never, ever compare myself to Donald Knuth, for no other reason than that the man helped us figure out how we are as programmers. I am a storyteller, and I am collecting stories to help people understand how we got here. 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. Yeah, I’m not going to do that. I don’t think they’re the same thing at all.

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

Yes. Well, if there’s anything I’m going to do, it’s 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. Their decisions were rational, even if it wasn’t apparent that they were rational to the rest of the world.

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 are some painful moments in .NET history for the average .NET developer who was never an MVP, never worked closely with Microsoft, never really saw behind the curtain themselves. If there’s anything I can do, it’s to let that person know. You remember when you were frustrated with what happened to Silverlight? It was a frustration because it just stopped. There was never an explanation, there was never an announcement, other than what happened in the news, where there were articles saying Silverlight 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 who were there and pull back some of the pieces of what was going on at the time.

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 into the history of computer science and computer programming and development, and how we went from what is ostensibly a science to a sciencey, arty, engineeringy sort of thing.

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. That doesn’t mean 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.

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

Not at all. I’m here to persuade.

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

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 that “History of .NET” is not a great title, even if that’s actually what it’s about.

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

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 add it to the stack and see if one of them will someday reach out to me and go, “yes, this is the thing I want.”

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

Yeah, maybe that’s it.

One of my favourite stories around titles is how we actually named RunAs Radio, which is 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? I’d been working on making an IT podcast for a while, and Carl and I had been going back and forth brainstorming names. Same thing: no idea is too dumb, just write it down. Then we’d go through all the names, and we’d have a session over the phone for an hour arguing about the merits of each one.

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 can get better.” He was like, “all right, I’ll talk to you later.” We hang up the phone, and within 30 seconds he calls back. I pick up the phone. I’m like, “did you forget something?”

He goes, “it’s RunAs Radio.” I’m like, “there it is. That’s the title.” It’s just so apparent when that moment hits.

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

Any time you’re trying to come up with something like that, there’s the core brainstorming technique of just writing down every idea, no matter how wacky it might be, then letting it sit for a while, going back, reading through them, arguing them, and seeing what next-generation ideas come out. That brainstorming strategy is the only thing I’ve ever found that finds this kind of thing.

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

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.

That’s very true.

I know that we recently had — I say we, I recently had — a conversation with Steve Gordon.

Yes.

I was talking to him a little bit about the Humanitarian Toolbox.

Mm-hmm.

Perhaps we could discuss the Humanitarian Toolbox a little, if that’s all right?

For sure.

It’s directly related to .NET Rocks. The origins of Humanitarian Toolbox come from the .NET Rocks Visual Studio 2012 Road Trip. 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. The biggest of these turned out, in hindsight, to be the 2012 one.

We knew it was going to ship in the fall of 2012, so during the summertime — I think it was in July, and I actually still have my original OneNote 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. We put logos on the side of the RV, so we looked a bit like a NASCAR driving from city to city. In the end, the 2012 road trip was 34 stops in 13 weeks. It was a beast.

It was the Microsoft folks who 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? I think if I’d had any brains, I would have taken the easy way out and simply said, “how about we match dollar for dollar for Kids Who Code,” something like that. It would have been the easiest solution. Instead, I went on a bit of a rant about how frustrated I was with how hard it was for software developers to donate their time as coders to a charity.

Code is never free. If you write code 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.

I think most software developers understand this, and when given an opportunity to support a charity with code, they also recognise that it’s a permanent commitment, that you have to keep going back, keep contributing, and keep doing work on it. Many folks are just like, “I can’t make that large of a commitment, I have too many things going on,” so they resist doing it. 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, 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. Getting a different developer onto that code is even more difficult. It was a sprint of code, it was a weekend. What kind of code are you going to write in a weekend?

With those things in mind, knowing that developers do want to donate their time to charity and 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. 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. Could you do that as a charity project as well?

The challenge, of course, is that software is more than the code that is written. It is the project management parts, the planning of features, the writing of user stories, hopefully the organising of tests, then giving a space for programmers to work — and how do you care and feed for the app? That was really the essence of Humanitarian Toolbox: 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 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? 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 are 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. 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. That has been the mission.

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’d just support them. I found pieces of organisations and different bits, and we started connecting with them and looking at how they were working, knowing we would be able to recruit, knowing that 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. It took time to figure out the right way to do that. Ultimately we ended up creating a 501(c)(3), 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 becoming a UK charity as well, or a Canadian charity as well. 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.

The Humanitarian Toolbox is a large collection of… is it mainly open source? Is it completely open source?

Yeah, we’ve pretty much gone totally open source, and there are 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 — hey, all the code is in GitHub — I also don’t have to pick which charities get to use the code. It’s like, the code’s on GitHub, feel free, right? github.com/htbox. You want a copy? Fork it, go, take whatever you like. 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, work on the projects that make sense, and take contributions from different sources. It solves a ton of problems to just be open source.

So literally anyone can contribute something?

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

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

Thanks, I appreciate that.

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

Plus feeling good about writing code. It’s not just work, will code for food. We often forget as software developers 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 is just more of the same, but often we’re so enamoured of our technology that we ignore the business ramifications of doubling productivity, of just saving time.

The allReady project, which is one of the HTBox projects, had an initial implementation focused on a Red Cross initiative for putting smoke detectors in homes that didn’t have them. Look at the early stats from when they were doing this the manual way, where they’d set up a stand at a home improvement centre, take down names, and eventually get enough together that they could send out qualified installers — the volunteers — to install them. Typically it would take a few months to get that whole thing together. On the day that person could volunteer, which would be a Saturday, they’d send them out with eight smoke detectors to install and eight addresses, and people weren’t home, or they’d forgotten about it, or they wouldn’t let them in, 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, we were now utilising social media to do the campaign, so we’re gathering the names faster. We were able to ship the smoke detectors out to the volunteers so that they 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. Now we were getting 70–80% of the installs done successfully. We used that volunteer’s 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 — organising volunteers, 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. Its result is, I think, that 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. If we were responsible for getting that smoke detector into that house, well, we saved those people that day.

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

There’s a few of us that get together. A friend of mine, Paul Seal, and James Studdart, who I mentioned earlier on, and we go to random hackathons. We went to one this year in a city called Nottingham in the UK. When we were there, they were asking for something to help the people of Nottingham, and we came up with a system that allowed people to walk around and go, “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.”

Right.

Well, I can use this app to let the emergency services or the local council know that there is someone vulnerable in this place, at these GPS coordinates, and this is what I can observe. This person is maybe lying 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.

For sure. Who makes phone calls on their phones any more anyway? 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 be to ever make a phone call.

Precisely. That whole competition was 24 hours, a hackathon, so it was along the same lines as what you mentioned earlier on. The code wasn’t brilliant, and if we had actually shipped it and sent it out to real people, it would have crashed a couple of times. 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.

Right. One of the mantras I’ve always had with HTBox 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, so that we do have time to go back and improve it and to sustain it, because it needs to keep getting better. I think that’s a very different model. It’s not as exciting, but it is ultimately making better code.

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?

Yeah. Well, how well would it work? One of the things that we’ve worked really hard on at HTBox is recognising that every developer is a volunteer. Nobody gets to be in the critical path, because you need to be able to go home. 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. It’s what it takes to make really sustainable software.

I guess the last few things I’d like to ask, if that’s okay, shift slightly away from HTBox. It’s a very important project, but I just want to move away from it a little bit.

You’ve had this dual, wonderful position where you’ve seen the evolution of .NET as a first-person event, and you’re able now to look back and listen to other people’s opinions on what happened, their different perspectives, and all of those kinds of things, collecting all of those stories. How do you feel — 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?

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, living in a Windows world. A lot of the work that’s gone on around Core has not been relevant to them.

Maybe they’re not web developers. 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, so they have not looked at Core at all. 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.

It’s been several years — .NET Core first shipped in 2016, so we’re a couple of years in — and I think the weight of these two lineages is starting to show. 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 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 the community together under a single umbrella of .NET.

I’ve certainly seen this in conversations on the show and with listeners, that there’s concern about that split, that there are the Core folks over there and the standard folks over there and they are not going in the same direction. 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.

I agree. I think it’s not going to be an instantaneous step to 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 with Core, they can go, “nope, don’t need that API. Nope, don’t need that. Nope, don’t need that.” If they wanted to. They don’t have to, but if they wanted to.

You’ve also got a new class of developer coming into Core who never used standard and who think about it completely differently. It’s a confusing time, I think, for a lot of folks, especially ones that have been involved with .NET since the early days, who are just, “who are these people?”

I’m excited about what’s coming. Knowing that 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 to talk about, it’s the fact that there is this dichotomy, there are these two worlds. The mission of getting those two worlds closer together is a worthy mission, a positive mission. Maybe it’ll be done by the time the book’s done, maybe it won’t be, but I’d like to end with “the future looks bright”.

Let’s hope that we can do that. I do know that over here in the UK, certain public sector organisations and enterprises 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 line-of-business applications, and whatever you’re being contracted in to make, you have to slot that into that whole setup. 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.

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 Microsoft is leaving anybody behind, but you do have a split in innovation going on, and there are actually more divisions than that. The Windows side of things with UWP: that was actually a different build of .NET. With the reorganisation of Windows, I think part of what’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 done with Xamarin integration yet, that all of the things that were built by Miguel and his boys need to be improved and need 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 there’s a big stack to do here. We’re nowhere near as good as we could be.

I think what we need to try and remember as a community is that .NET — the ecosystem, the technology stack, all of the different levels that are involved in 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.

Sure. But hindsight always has better vision. 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?” The fact that Microsoft has completely transformed .NET, literally as a rewrite, in the past few years is astonishing, rather than just making something completely new to carry that forward.

One or two last questions, and then you can go off and enjoy your day, whilst I’m sitting here in the dark because it’s seven in the evening and that’s what happens in winter.

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

Okay, so the last few questions, then. 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 RunAs Radio, or .NET Rocks. What’s the best way that they can catch up?

Yeah, I’m spread around. I don’t have one central homepage for any of those things. I hang out on Twitter a lot, so @richcampbell is an easy way to reach me. Certainly, when you look at my bio on Twitter, it says .NET Rocks, dotnetrocks.com; RunAs Radio, runasradio.com; and Humanitarian Toolbox, 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, look at the work items, and come and be part of our team.

So would you recommend that anyone who is interested in helping out with HTBox 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?

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 of where we’re going and what we’re thinking.

If you don’t have cycles to do coding, or if you’re not a coder, we take donations. We are a 501(c)(3). If you go to htbox.org, there is a Donate Now page. Every bit helps. We largely spend the money on project management; 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 allowing charities to cross over — it’s tax deductible.

Just real quick: is the technology stack of HTBox .NET, or is it pretty much anything goes?

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

I see. So literally almost anyone can help out.

Absolutely. Like I said, there are 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 charitable initiative to try and make our software better. There are lots of different roles for making a great piece of software that makes a difference in the world.

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.

I appreciate that. Thank you, 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.

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

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 realise there’s a huge time gap between yourself and me, and obviously it’s cutting into your daytime.

Oh no, my pleasure, Jamie. Isn’t it amazing? We live in a world where, halfway around the world, we can have a conversation.

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.

I appreciate that. Great to talk to you.

Thank you very much, Richard.

Thank you.