S01E05 - Which technology should we build with? Transcript

Drew: Welcome to the differential product conversations podcast where we try to demystify how great digital products are made by answering questions product owners have but are too afraid to ask.

Colin: Alright, so we are up to a new episode. The setup of this episode is to address and discuss the various technologies that might be used to develop your digital product today. So our goal here is to make you aware of them and not let them scare you. Let's dive into the key questions:

What technology should we build with? What is a tech stack? What are all the different things that people are maybe throwing around? And how do I think about that? 

So, Drew, the high-level thing is, I have my team. I know the problem I want to solve. We have a process for how we're going to do that development. What choices do I have and in the actual development technologies, and how big does that matter?‍

Drew: You definitely have lots of things to think about. I think there's some ways you can narrow it down. So obviously initially it's platform decision. It's where am I building this thing.Is it an iPhone app? Is it an Android app? Is it a web application that they can access in their browser? There's lots of bleeding happening here. There are technologies like React Native where you can build in a web technology that will then create a version of this in native applications. So native iOS application, native Android application, there's all sorts of different ways to go about that. Those are the two I think of where there are web technologies and then native device technology. That’s the first approach. 

Some definitions we could put around stuff you'll hear, which I think is a good way to frame it: you have languages, you have frameworks, you have libraries. Those are probably some common definitions you'll hear. I'm going to maybe butcher explaining this but hopefully it makes sense. 

A language can be thought of as a programming language. There are a large number of them that can operate in these different platforms. Languages like PHP, C++, C Sharp, JavaScript… C1, C++, and C Sharp, they have variants that work on operating systems. Then you have ones that are web technologies and ones that are both, so that can get blurred a little bit. But in general those are programming languages. 

They are easy to think about because new ones don't come around a lot. They've been around for a very long time. Swift is probably the newest... I guess not; there might be some newer ones. Swift was, like, five years ago. Go is a newer one. There's all sorts of newer ones that have popped up, but they do stand the test of time. They aren’t popping up constantly.‍

Colin: And that is actually when I'm typing code on my computer. How is that communicating back to the actual machine or the servers or clients and things like that? The language is the fundamental building block of how humans communicate with computers.‍

Drew:  Yeah, I think it's fair.

Then framework on the flip side is one that will probably change a lot and can have wide fluctuations. It's different. A framework is always built on top of a Language.

There's a popular framework called Ruby on Rails. I think that's a good example because Ruby is the programming language; Rails is the framework built on top of Ruby. The framework part is essentially just lots of different configurations and settings and things done for you. A lot of boilerplate, a lot of different ways for you to get away from the details, and it just does it for you. It's all written in the language. You could look at Rails and look at all the Ruby code that does things for you, but it just simplifies that. I think that's one example of framework. 

React is another one. That's very popular these days that you're sure to hear about, and that's written in JavaScript the language. JavaScript runs inside of a web browser, it can also run on the server and via node. So again it gets more and more and more and more complicated there. But in general React the framework is the same thing. It’s all written in JavaScript, but then people use React, which gives you different ways to work with JavaScript and to build user interfaces in an easier way because the framework itself is providing it for you.‍

Colin: I like to think about frameworks as like, there are some of the principles and patterns all wrapped up into a package of, how can I just follow some of these things? It does give me the configuration files. But how can I really start building something and not have to think about how are all these things coming together? People can build on top of these frameworks. So most people you're going to work with will work with these frameworks.‍

Drew: Yep. Yeah, that's totally fair. And then the third one is library. It’s another one you'll hear and this is more like a nuance I would say, but I would think it's kind of a continued progression. 

So Language is the core thing. It's just exists and that's what gets compiled. You have the framework, which is written in that language that gives you some of those things you're talking about. It gives you a lot of best practices and patterns that you can reuse without having to do it yourself. A library packages it up into bigger pieces of functionality.

There might be an authentication library or there's different ways to do larger pieces of functionality within a framework within the language. ‍

Colin: Is that where, Drew, where you would have; is language or library similar to a plug-in or a module or a component or some level of smaller set of functionality that you can use but you may not use in all of the different cases. The framework is how the approach and things like that in the libraries or plugins or whatever are smaller set of features that people commonly use but aren't probably core, to “hey, this is necessary for every application”. So it's left out but they're things you can pull and plug in kind of plug and play kind of way.‍

Drew: I think it's a good way to think about it. I think “plug-in” is probably a good word and that would apply in most instances where that equates to a library. But like I said, I think language is clear. Framework and library can have lots of different nuances to it or someone might call it one thing or another. I think it's important just to distinguish between; there are programming languages and there are things built on top of those languages to make your job easier. ‍

Colin: So, we've already listed about a bunch of different languages and even some of the frameworks. PHP and that has kind of CakePHP as a framework and WordPress as like an almost a framework-esqe kind of thing, like you can build on top of it. Java which is used for Android. JavaScript is different than Java… maybe that's a whole different episode. They are different languages. Python has this framework of Django to build things off of. Ruby has Ruby on Rails, JavaScript has React, React Native and node.js are frameworks. Go, I don't know if there's a framework that people are using; I'm sure there is. 

My question to you, Drew, is what do I actually have to take into consideration as I'm looking at the technologies? And how much do I listen to the team that I'm working with? What are the different things that they're going to bring up and will make them excited? What are the things that I should be worried about as a product owner when we're having this bigger platform discussion around languages and frameworks to use?‍

Drew: This is totally a relevant question. It's a relevant consideration, rather, for a product owner to make, or somebody who’s running a team. I mean, there's so many different things you have to think about here. 

I do think from the language standpoint, once you've narrowed down, I know I'm on this platform. So, say we're building for the web. You know, I know I've been limited the number of languages that exist, and that you can feel pretty good about because, like I said, they don't come around too often and they usually have enough backing behind them and user base that you can feel good about it.

I think one question you can start with is “how long has this thing been out?” I think that's more relevant to a framework. So that's usually where you're going to start. You know, hey, we're going to build in JavaScript. So now I want to look at the framework. In the JavaScript world, there are numerous frameworks. There's React. There's Ember. There's Backbone. There's Angular. And they're all - to be clear - solving pretty much the same problem. You can use them interchangeably. They're all written in JavaScript. They're all frameworks for building user interfaces. 

So you have to look at them that way and figure out how long have these things been out? Weighing the balance of something that's modern and new. My team might enjoy using this but stability is also a thing and sometimes old is good and certain attributes for consideration you need to make here. Adoptions, like I mentioned, how many people are using it? What is the backing behind it? There's a very common problem in software where that kind of stuff becomes vaporware or it's just not maintained any longer. Something that you're using could just, the next day the people who are maintaining it on the side of their main job can't do it anymore. And that's obviously a problem. 

You need to look at adoption and documentation and how much is out there for me to learn and my team to learn and how comfortable they can feel about it, which is part of figuring out how easy it is to learn. Can you bring new people onto your team and train them - that's a huge consideration.‍

Colin: One of the blessings and curse, kind of a modern kind of Open Source software... we've gotten away from super proprietary, only one company does this this way... this like, hey, we're just sharing some of these frameworks and libraries and things like that. But if you aren’t maintaining them or updating them, they could be painful and not helpful and hurt your app by using some of those. And then adoptions are going to go up and down. 

So it's a whole consideration to think about. Who's using it? Is it gaining momentum? Is it losing momentum? And where's some kind of forecaster prediction of where that's going to be? Who's the biggest backer of that? Facebook's kind of backing React and React Native and other companies are backing different things. Is the community that's like the core group building on this thing?

So, definitely. I'm just totally agreeing with you, like, that's a big consideration here.‍

Drew: Yeah, and I even think like weighing that, too, where Facebook backs React; they have a team. That's the React core team that builds React, but then the consideration you also have to make is open source.

Like, is this something that's on something like GitHub? It's publicly available, the community can weigh in and help shape this thing, and I can submit to it. That's a huge part of shaping it, if it's backed by a large company. Because otherwise, that company has its own interests in how this thing could be shaped and if it's closed off, then it's not super relevant. So you do want the backing, but you also want to make sure that it’s also driven by the community and the user base to make sure it's shaped in the right way. I think that's a huge consideration to make there. ‍

Colin: Great. Other things I think about with the different technologies are, how easy is it to learn and can I train people on it?

So, the easier it is to learn and the more people that could I could train on it or if there's some super technical thing that solves a specific problem, but it's really really complicated, think about like 3D geometry style things, there's a smaller population of people who are able to approach that and get that. JavaScript is taught pretty well; Python as a language is taught pretty well, and there are lots of things for people to learn. 

You can hire for it! It makes it easier to then have more people be able to actually make meaningful contributions to your visual product. And then the other one which we talked about was the big pool of developers, like, “how many people like this thing?” So we talked about adoption, we talked about that kind of thing. 

My last question for you, Drew, is does it matter - how much do I weigh what my team likes and has skills in when I'm building my digital product?‍

Drew: I think that's probably the toughest thing is that this is a consideration but you need to - you're weighing all of those questions against how much will my team enjoy doing this? And that also depends on your team, too, because if you're trying to grow this digital product to where this is what they're going to be doing, are they going to be wanting to write code for this in this language in this framework with these libraries in five years. Those are questions you need to ask.

If you have to figure out does it matter what my team likes; I think absolutely does. You may need to enjoy the work and enjoy building it in that and need to. And there's something popular in the development world at least for, you know, you hear of UX or user experience of a product. There's also this DX or developer experience, which matters too. How I write my code, and that's why these frameworks like React and a lot of these newer ones are built around the idea that we can build great user interfaces, but really care about the developer experience. So that in building it they enjoy that, and that's what keeps your team building quickly, building happily, sticking with it.

I think it really matters but it's just one of those things like everything. You have to balance it and weigh the pros and cons. ‍

Colin: Yeah, it's great. Okay. I feel like we addressed this one enough. Sort of feel like a broken record in some of these summaries here: “There's a handful of different technologies available for a handful of different things.”

It still does depend. Hopefully, this helps you demystify some of those things. But new technologies are coming out all the time and seemingly every day. Don't just get bought in or sway too much in the latest Promises of the latest Technologies. Look to your team as the trusted opinion in that. Lean on them to make the right choice. 

In our opinion, if you're choosing one of the more popular modern languages, JavaScript, Ruby, or Python, you’re probably going to be in a good spot. You can pretty much achieve anything with the different technology or language you’re choosing. So don't say one is technically better for the solution than the other. People get way caught up on that. I think it matters more about what your team can build from and has the skills in to be more effective. And your speed increases, the quality of the product increases, and team happiness - things like that increase from there. ‍

Drew: I think, at the end of the day, choose something. You can always swap it out later. Yeah, it will be a lot of work for you, but make the best decision with the pieces of information you have at hand and then you'll be able to just go with that. That's what matters. The choice matters more than just sitting on it. 

We could call this the “It Depends” podcast.‍

Colin: Yeah. “Building Digital Products: It Depends.”‍

Drew: It depends.‍

Colin: Thanks for listening. As always, we want to hear from you. So please reach out and give us your questions and challenges and we will try to address them on a future episode. You can reach us at podcast at differential or you can find us on Twitter at @BeDifferential.