The Frontside Podcast

Alison Davis: LinkedIn

Ronald McCollam: @ronaldmccollam | ronaldmccollam.com

Show Notes:

Resources:

Transcript:

ELRICK: Hello and welcome to The Frontside Podcast, Episode 80. We have a wonderful podcast today. My name is Elrick Ryan, a developer here at the Frontside and I'm going to be hosting the podcast today, in place of Charles because he's on the frozen tundra. I also have co-hosting with me today as well, another developer from the Frontside, Joe LaSala.

JOE: Hello.

ELRICK: Joe, how are you doing?

JOE: I'm doing well, how are you?

ELRICK: I'm awesome, man, and we have a wonderful podcast today. We're going to be talking about Resin.io and we have some wonderful people here from Resin with us, not one but two people came over from Arizona. We have Alison Davis, who is the director of product marketing and strategy at Resin. Alison, how are you doing?

ALISON: Hey, Elrick, I'm great. Thanks for having us.

ELRICK: Thank you for coming on. Also, we have Ronald McCollam, who is the solution architect at Resin.io, he's on the call with us on the podcast. Ronald, how are you doing?

RONALD: I'm doing great, Elrick. Happy to be here, thank you for having me.

ELRICK: Thank you for coming on. Thank you. Let's kick it off and we're going to talk about some IoT today, some Resin in IoT. What do you guys think is the future of IoT? What does it hold in your perspective?

RONALD: If you had asked me a couple of years ago, I probably would have said that it's a bunch of connected refrigerators and maybe light switches and kind of left it at that. But the more I see the industry evolving, the more I realize that IoT really means that everything is getting interconnected and everything is sending data and exchanging data. I think we'll start to see IoT, not only in smart appliances and lights and so forth on the consumer side, but also on the industrial side. A lot of building automation, a lot of just more general information being provided by the environment and environments adapting to suit humans better. I think really the answer is IoT is going to be everywhere you look over the next few years.

ELRICK: That is a broad takeover of IoT. It's going to be everywhere.

ALISON: Yeah and I'll just add that we also think that IoT is going to become more prominent as compute power really does push further and further out to the edge. We see this trend happening already, where the amount of data and computing that needs to happen is too much to continuously be communicating back up to the cloud and more and more computing will need to take place on the edge in IoT devices and we really see these strong devices weakly connected as we often say as the future of IoT. One thing, we can talk about with Resin is, we see this creating what we call a management gap in between the developer and the fleet owner of these devices on the edge and the devices themselves and that's where Resin comes into the picture.

ELRICK: That's interesting, so these devices are going to be sharing the computation and taking away some of that computations from the actual cloud?

ALISON: Yeah, we think so. I think the devices themselves are getting stronger and it's becoming more and more possible for that to happen. Then there's just simple reasons of physics and economics why it will be too slow and too expensive to continuously be relying on the cloud for compute. This is a trend that we really see happening and something that we want to help fill that management gap between developers and their fleets of devices that are running out on the edge.

ELRICK: I can see how that could be a plus for a company to not have to try to do all these computation on the cloud. As Ronald said earlier, since IoT is everywhere and it's going to be in devices all over the world, we could end up with probably trillions of devices trying to leverage cloud to do with computation and taken some of that away from the cloud would be a definite plus because I don't think that there is a platform that can handle that kind of data throughput.

RONALD: Yeah and even as Alison said, there are just times that for reasons of the laws of physics, you really can't wait for that round trip to the cloud. We'll go sci-fi here. Let's say you've got some automated robot in an environment with a lot of people around, you don't want that thing sending all of the camera information that it has as it's moving through a crowd of people up to the cloud, waiting for the processing to happen there and then being pushed back. By the time it gets there, that robot may have already run over somebody. We really don't want that. You've got to do some of that processing out at the edge where the data is being collected.

ELRICK: Yep. That's both technology issue and legal liability there so we got to make sure there's no robots running over anyone.

RONALD: Yeah, exactly.

ELRICK: How does Resin then blend itself to helping to promote this computation in strong devices that are weakly connected?

RONALD: What Resin does is really enable you to be sure that you are running the right code on the right device and that any updates you push out to that device are not going to take that device offline or brick the device. Resin really sees whatever is running on the device as sort of a black box. We really don't have a lot of opinion about what the right thing to do on your device is. We think you know that better than we do. But what we can do is help you make sure that the devices that you have out in the field are always running the latest code, that when you find security flaws or you want to push an update out, you can always reach those devices and be sure that you can do that safely and effectively. Really, from our point of view, we want to make sure that the IoT is running safely and is always running the latest and greatest, the best code that you can possibly have out on your devices.

ALISON: You need to have a way to remotely manage an update on all of these devices in a way that won't brick the devices or make you lose access to them when you can't physically access the device again. Resin is here to make it simple, easy, efficient, fast and most importantly, safe to update, as Ronald said, the code and software running on the devices so you can push updates as often as you like, send security patches and then remotely monitor what's going on with your entire fleet, all from your laptop.

ELRICK: That's amazing. We've had some experience using Resin here at the office and we've been very excited and delighted with the service. I've been in Boston, actually pushing code down to Texas and it happens like almost instantaneously, which is amazing.

JOE: Yep. We really enjoy using it. I think it's really cool. We're only using it currently on one Raspberry Pi but it be really fun to have a fleet of Pis and get expand that reach. I got to ask what the origin story is for the Unicorn that gets displayed.

ELRICK: Yeah and in that vein, what is the founding story like? How was Resin founded?

RONALD: The founding of Resin is really an interesting story because it's not that there were a bunch of people sitting around in a boardroom with a whiteboard and saying, "What's the next big thing coming along, what can we get into?" This really came about as a result of real world events. Back in the 2012 Winter Olympics in London, the team that would later go on to found Resin ended up in charge of a project dealing with a bunch of digital signs, so think of advertising and information about what was going on in the Olympics. These were all over the city of London. Mostly on a really, really interesting smart bomb proof rubbish bins. They really went all out to make sure nobody could come to harm as a result of these.

But the team was intending to push some updates out to these devices -- update the information on the signs -- and had inherited this project that had been built where they were really doing what everybody was doing at the time. You just SSH into a device remotely, you run a set of script and you kind of hope everything works. That's how we had a whole bunch of people walking around the city of London in the middle of winter with USB keyboards and USB sticks, trying to get all of these individual rubbish bins back online and back up and running after a bad update.

After pulling back from that, they said, "You know, this is terrible. There ought to be a better way to do this. Why did we end up in the situation?" It turns out, there really wasn't a great way to do it at the time. That's where Resin comes from. It's an effort to fix this problem, not only for ourselves but for everybody in the world to make it easy to push updates to remote devices and be sure that you're not going to have to walk around in the cold and the sludge to try to get those things back online if you do a bad update.

I don't really know what the origin of the Unicorn is. I know it was an in-joke with that team that, I guess kind of slipped out more into the real world. I don't know, Alison if you know more about the Unicorn than I do but it's still a fun thing to see every time you do a push.

ALISON: Yeah, I think our CTO Petros, who was also the first person we think anyway to -- when we get into this when we talk about how Resin works -- port Docker to ARM, which as a core piece of the Resin platform, he wanted to add in something fun so that when you complete a successful deployment on Resin, you see the Unicorn and that means that your push is successful and your device has fully downloaded the update. I think that's part of what makes Resin 'Resin' is where we're very, very serious and we want everything to be secure and completely buttoned up. But we also like to keep things a little bit fun and make sure that, not only is it safe and easy to deploy updates but also enjoyable.

ELRICK: We definitely enjoy seeing that Unicorn as well. I've just been pushing the simplest code of all time just to see that Unicorn pop up on a successful build.

RONALD: Yeah, it's always nice to get some feedback that everything worked well and everything is going perfectly for you today.

ELRICK: Yeah, that's beautiful. We were thinking about that as we were talking about some IoT things before. We had not the best product idea in the world and since everyone drinks Topo Chico in Texas, we were like, "I wonder if we had a Topo Chico popper in the refrigerator," and then we're like, "If millions of people end up with this Topo Chico popper, how we then going to update the code on these Topo Chico popper in everyone's refrigerators?" That's where we're like, "Resin.io would be a perfect solution for that," or as you said, half people are walking around in the sludge going to update these devices.

These devices could be located anywhere in the world and Resin seems to be a platform that could handle that type of requirement that you have to update these devices that could be anything and anywhere. I guess we can talk about how Resin then works in order to get that code deployed to anywhere and keep all of these devices updated with fresh code, as you said.

RONALD: Yeah, absolutely and you're completely right. This is designed from the ground up to be something for working with distributed systems, devices that are not really under your physical control. They may not even be on a network that you control so this could be something that is out in the middle of the ocean, up on top of a mountain. Anywhere that you have network access and you want to be able to update a device is really the target for Resin.

The way that this works is there's a lot of bells and whistles and things that we've learned over years of updating devices and managing devices but at kind of a high-level, we maintain a host OS on the device. There's a stripped-down version of Linux on that device that maintains a connection to the network. Really, its entire job is to just keep that device humming, keep it on the network and not do a whole lot else.

Everything else happens inside of a Docker container and if you're not familiar with Docker, Docker is really sort of like a lightweight virtualization. It's a container technology that allows us to pack an application, all of its libraries, even its operating environment into one container that can be deployed and managed very, very easily. Because everything is sitting inside of a container, we can push updates to a container and not touch that underlying OS layer that is managing the network connection.

Even if you do push bad code, that's not great. Your code might crash but the host operating system is still going to stay online. It's still going to maintain that network connection so that you can roll back or push another update to fix things very quickly. Then on top of that, we layer on a lot of technology that we have developed in-house to do things like computed delta between what is running on the device and what code you have just pushed to us to get on the device.

You might have an eight gigabyte application running on one of these IoT devices but if you make a one kilobyte change, we're really only going to push about one kilobyte out to the device. We're not doing a full blast of a firmware update, making you pay for eight gigabytes of data over your 3G connection. We're really doing everything we can to minimize the amount of data that we send over the air, both so updates go faster but also so that we don't have to pay as much for bandwidth or wait as long in intermittent network connectivity environments.

Then the final part of this is that by using Docker, we get for free some of the really cool things that Docker brings to typically larger data center environments. We have things like atomic updates. When you push an update out to a device, if you lose power or you lose connectivity in the middle of that update, that's fine. The device is just going to keep running the same code that it had on it previously until network connectivity is restored. It will resume that update and only once the full container is downloaded and put on the device, it will shut down the old version and start running the new one. There's really a lot of under the hood stuff that we've developed and we've layered on to make sure that when you push an update out to these devices, it's always doing it safely and always doing what you want to do.

I get to say this because I didn't write any of the underlying code. I'm constantly amazed at some of the stuff that Resin does under the hood. It's really fun to see, just how easy it can be to update devices that are anywhere in the world. I'm constantly pushing things to London or to Seattle. I'm in Boston so it's really cool to see these things update all over the world.

ELRICK: That is amazing, all of the various things that Resin gives you out of the box that you don't have to worry about as a developer, as a company. It provides you that underlying foundation for you to then build whatever product that you want to build or software that you want to build on top of it and it's absolutely amazing. I'm blown out the water every time I do something out on it as well.

RONALD: Oh, cool. I'm really glad to hear that. That makes me feel good.

ELRICK: That's interesting. There's so much in what you just said. There's so many different parts. I know that Joe one time, he was wondering how you guys actually do that diffing in the code that's pushed up to then on the download those changes and not the entire bulk of that code. Can you dive any deeper or give a further explanation on that portion of it?

RONALD: Yeah, absolutely. I'm happy to. At a high-level, it's very simple to explain. Of course the devil is in the details. It's just like, "Updating the device. Oh, great. I'll just push bits out to it and run some stuff." If you think about it too simply, that's how you end up having to trudge around in the snow with USB stick. But at high-level, we're tracking what's already deployed on all of those devices. Because the devices out in the field are in contact with the Resin service on the backend, we know what version of your code is running on every single device at any given time.

Because of that, what we can do is when you push a new version of your application, we can just do a binary diff against the image that was pushed out earlier to the image that you just wanted to push right now. We can say, "This device is running version one. I want to bring it to version three." I already know what version one is. I, obviously know what version three is because I have it right here. We'll just calculate a diff between those two versions and send only that diff out to the device.

Then because the device is fairly intelligent, we can do a lot of computation at the edge to just reverse that diff and apply it on top of what's already there. These are Linux devices. They can run the same code that we use on the backend to generate that diff just in reverse, to generate the final image that we want to deploy. Even if you've got devices on five different versions of your application and you want to push them all out to the latest version, we can apply a different diff for every single device and push that diff out to the devices and they will then apply it on top of the container they're running. From the user perspective, it's nice and easy. Under the hood, there's a lot going on that we've developed to make sure that process always happen safely and securely.

RONALD: Yeah, that was, honestly one of the big issues that we've seen in the IoT space in general is that the tooling and the workflow that people are using, I don't want to insult it but it's out of date. It's very much a 20th century mindset. People aren't tending to use the latest tools. They don't have continuous integration. It's really like I'm writing some C code or assembly and I'm blasting out a firmware update. That's worked in the past but it doesn't get to the scale that you can do things in the web and cloud world.

Look at Facebook. They're doing multiple deployments a day sometimes to production and when was the last time you heard about a deployment taking Facebook down. There's a lot of tooling and a lot of really cool development that has been worked on and put into practice over the past 10 or 15 years to make those things possible. We're taking those same tools and we're bringing them to the IoT world. Just like you mentioned, when you do a deploy through Resin, you're actually doing a get push. We're using the exact same tools that you would use to deploy to a cloud environment but now, you're deploying those out to an IoT environment so we can fit right into a continuous integration pipeline. We can let you do things like distributed development.

Resin is a very distributed team. We have people in something like 19 or 20 countries. We're using these tools to develop Resin. We kind of said, let's use those same tools to bring that experience to the IoT world. It's a really great way if you already have some experience with cloud development or modern desktop software development to be able to use those same tools for IoT, without having to come from a really heavy hardware background or firmware background.

I, myself am a software guy and a web guy from way back so it's really cool for me to be able to deploy things on the devices without having to think about assembly code or firmware blobs or things like that. I can just write, even maybe some Electron code, get push that and it lands on a Raspberry Pi and I've got my code running on a device somewhere out in the world without me having to learn a new tool set. It's really powerful from that aspect as well.

ALISON: An important point is that we want to bring the best and most modern and newest tools to the IoT but we also want to bring a workflow that feels native to developers who are coming to IoT from the cloud and web world. Given the growth that we think will take place in IoT and more and more devices moving out to the edge and more compute are moving out to the edge, we'll need more and more developers to be building software and code for these devices and we want to make it very accessible and easy and native to all developers and to the workflows that they're used to so they can develop applications for IoT and have it feel like a very native workflow.

JOE: You've hit on what I think is like a very important point about this. The IoT is a marriage of these systems programming, embedded programming and web development in a way. That's a very different codes that is written. People who write code in embedded systems, it's a very different world than what we do as web developers. The one thing that you might be able to bridge that gap with is a common workflow and we're all used to version control or used to kind of pushing code out the way that we push code out and Resin sits right in the middle there. That's worth a lot, I think.

ALISON: Exactly.

RONALD: That exactly it. There are millions of mobile developers and millions of web developers but only hundreds of thousands of traditional embedded developers. Being able to bring those millions of developers using their same tools they're already familiar with to this IoT space, I think just really dramatically increases the opportunity for people to get involved and to build the next cool thing.

JOE: Definitely.

ELRICK: That is totally true because we were able to hook up Resin into CircleCI so we can get a continuous integration and continuous deployment pipeline. It was definitely a painless solution to set up. That is testament to that, if anyone wants to build something on top and start to add other things into Resin that you guys definitely do have those hooks for people to then, add whatever they need to build, whenever they need.

RONALD: Yeah, definitely. We think that the days of walled gardens are really over. We don't want to see companies try to lock other people or locked developers into a single application or a single environment or a single device. We really want these things to be as open and interoperable as possible. Part of that is just making sure that everything that we do is also open and interoperable. We expose all of our APIs to anyone, you don't have to use any of the Resin tooling, you can wrap that right into CircleCI, for example, you can pull that into Jenkins, you can pop this right into your development workflow and just keep rolling right along and we're happy to be a part of that.

ALISON: I think that brings up another important point about what Resin does too is that we're really committed to open sourcing all of Resin and currently everything that runs on the device, including our operating system -- resinOS -- is open source so that people can see exactly what's going on. We even had people take our operating system and tweak it to support new device types or add in their own functionality on top of that OS. We're working really hard to actually open source all of our backend as well. That's something that's really important to us in this world of open and accessible software for IoT. We want this to be something that feels approachable and open to anybody.

ELRICK: That is amazing. I didn't know that all of the code or majority of your code was open source. You heard it here first. If you want to go and check out some awesome code, head over to GitHub and look up Resin.io's codebase.

ALISON: Yeah, all of the code on the devices and the whole operating system is all open source already and then where we're releasing all of the pieces of our backend so that if you want to run Resin on your own, you can do that. Hopefully, by the end of the year, I think is our goal.

ELRICK: We've been talking about Resin and all of the benefits that Resin would give developers and companies that want to build products and it has a slew of things that it gives you out of the box, if you don't have to build that you can then build on top of. It will be interesting to hear some case studies or how people are actually using Resin in the wild to bid out their products. Do you have any specific case studies or things that you can talk about in respect to how people are using it out in the world?

RONALD: Yeah. We have a huge variety of companies using Resin. We like to say that it's everything from smart locks to skyscrapers. The smallest physical device that I know of that we're managing is smart locks like actual door locks on houses and buildings. Then we have things as big as skyscrapers like industrial automation, building automation. It's really all over the place.

One of the most interesting use cases to me is there's a company called OpenROV that does underwater drones. They have remote submersible vehicles that are exploring and doing cool science underneath the ocean. They're managing the software that's running on those devices using Resin. They throw these submarines out in the ocean, they let him tool around on their own. When they come up to the surface, they send back data and check in for updates so they can be constantly refining what those submersibles are doing out in the ocean without having to physically go pick them up or bring them back in to make changes. It's a really, really exciting thing to see.

But we've got similar stories in things like power generation. I mentioned earlier out in the middle of the ocean or on top of a mountain that was literal. We do have companies that are making wind turbines that are in all kinds of environments that are very difficult to get to. They really want to get the top performance out of these devices. If you can pull a 1% increase in power generation from a wind turbine, you've really started making a lot more money. That's a very significant improvement. They have devices in these wind turbines that are constantly monitoring every part of the turbine itself and the environment so they're feeding data back and then they can use that to build a new model of the best way to say, angle blades on a turbine and then push that new model out to the device without having to go miles out into the ocean or up on top of a mountain to physically touch those devices.

Again it's a really cool way of being able to pull data back in, modeled it in the cloud and then push that back out to the edge for application without having to physically visit every one of those devices. It's just really exciting to see all the cool use cases that Resin has being used in.

ELRICK: That is amazing. I actually gave a talk one time and I said, these devices could be out in the middle of the ocean somewhere, who knows? And someone could be pushing updates to it and it's amazing to hear that someone is actually doing that. I didn't just pull that out of the thin air. This is a real thing.

RONALD: Yeah, absolutely. We've got, like I said, out in the ocean, on top of mountains. We've got ones in the middle of cities. Anywhere that you have a network connection, you can put a device. We even have some companies doing things over 3G or even 2G modems, I think like out in the jungle or in very rural areas where you want to be able to collect things like environmental data or maybe air quality information. Really, anywhere that you can have a network connection, you can have a device that you're managing and updating and making sure it's kept up to date without having to physically go touch that thing.

ALISON: And Resin really is use-case agnostic and we see end users using Resin in their workflow, no matter what project they're working on. It all comes down to, I think all of these companies and projects are looking for ways to operate more efficiently and to gather data about their businesses and their projects. Any company in any business can use IoT to improve their operations. We see more and more companies finding ways to incorporate IoT into their work and I think part of that is driven by the availability and accessibility of tools like Resin devices, like the Raspberry Pi. That's affordable and easily available and quick to get up and running on. That's a new trend and I think it's enabling a lot faster and broader adoption of IoT.

JOE: Absolutely. It feels constantly like we're right on the cusp of something with IoT. But we do work in that space a lot just in our own time and as part of the work that we do here at the Frontside, we're always finding the tool set seems a step behind and Resin is a stark contrast of that. We're coming into a whole new era of computing with something with a very powerful tool in our belt already. That is very well fleshed out. Thank you for that.

RONALD: Yeah, thank you. It really does feel like we are on the verge of a sea change in how we see computing. We've gone, like I said from a few years ago thinking of IoT as sort of silly things like smart refrigerators. I shouldn't say silly but just sort of one off use-case like smart refrigerators or smart lighting. Now, to the extent where it's really about pervasive computing and I think we're just barely starting to scratch the surface of what that means and how that's going to change the world when we start having data about everything that's going on in the world around us. All of the equipment that we have and all of the compute power that we have around us is able to adapt to us and change as the needs of the environment change is just a really exciting time. I don't even think we can predict what the world is going to look like in 15 years as a result of this.

ALISON: As IoT and edge computing becomes more pervasive, we touched on this at the beginning but this is where management and security become really important and you hear a lot of people in the press and elsewhere talking about the security of IoT devices and how they're vulnerable to attacks. This is where something like Resin is really important where you need to be able to access and be able to update and send security patches to those devices remotely and to send those updates constantly so that they're not vulnerable. As this field grows, which we think it will exponentially, we really need to find ways to fill this management gap and Resin, hopefully can help do that to some extent.

RONALD: I think that traditionally, if you were building a device, you think like a hardware manufacturer like Alison says, you're not thinking about necessarily security and updates because in the past, it was just, we build a device, we'll put it out in the world and that's it, unless the things are catching on fire and we have to do a recall, we just move on to the next thing. But today, all of these devices are connected to the internet, which means they're constantly being attacked, people are looking for vulnerabilities and as soon as one of those is found, that spreads across the world like wildfire.

We see the news articles on a weekly basis of IoT devices being used as part of botnets or being taken offline. Having a way to make sure that you can constantly address those issues as they come up is really, really important. Even if you're a hardware manufacturer, once that device is released, you have to think like a software company. You have to be thinking of updates. You have to be thinking about security all the time or you're really letting your customers down.

JOE: Yeah, that's very true and the only way to mitigate threats is to constantly addressing those threats. I've worked in the security space. There's no such thing as secure really. We're never going to reach a level where it's like, we solved it. You have to constantly be rolling with the punches, so to speak. It's great that that's built in with Resin.

RONALD: Yeah, exactly. Security isn't really an end state. You don't ever get to say, "Yes, I'm secure now." It's a process. It's how do I deal with things as they happen because they will happen.

ELRICK: That is definitely true and people shouldn't be afraid to be constantly pushing data to these devices because as you said, people and some of your customers are using Resin on 3G and 2G networks so that is proof there because of the diffing that you do in the backend and you only have to push down a small subset of your code that you can definitely just constantly be pushing and staying up to date to make sure that you're on top of your security issues.

RONALD: Yeah, exactly and it's only going to become more and more important as we expect these devices to do more things and work with more data and perform more analytics at the edge. We just have to stay on top of that as an industry.

ALISON: And we have customers who tell us that before Resin, they used to be afraid to push updates and they would put it off until the last possible minute. We want to create an environment where the opposite is true, where you push updates all the time, not only to push any security patches but also to make your applications better and push better code out to your devices. We want people to feel empowered and they will able to do that as often as they would in the cloud [inaudible].

ELRICK: Yeah, that's definitely true because as you said, as we're getting more web developers and people into this space, we're used to, as web developers constantly pushing code and constantly sending updates about our codebase out there. As more developers from this base come into the IoT space, that's definitely something that they're going to be looking for and Resin does provide that capability out of the box.

JOE: It's interesting that it follow the same pattern because we weren't always used to that. We used to plan on a quarterly basis and releases would be these huge multi-day headaches with people on call. We kind of started going towards this very fast incremental thing and it seems like that's a pattern that isn't just web, I guess.

RONALD: Yeah, definitely. That model really has evolved from a lot of heavily painful work. Lessons people have had to learn over the course of years or even decades, tools that have taken thousands of hours to build, all of these processes are hard won knowledge. We really should be applying that everywhere we possibly can. Let's bring that into the IoT world and not start over from scratch and have to relearn all those lessons and reinvent all those particular wheels.

ELRICK: Resin is being used by a lot of varying companies and you have a wide customer base. Are there any use cases that came up that then pushed you to say that we have to build some for the features into Resin or some other type of software to help Resin or leverage Resin?

ALISON: Yeah, definitely. We've seen over the last couple of years, as you mentioned a lot of different use cases and customers using Resin. Our goal is really to make it easy and simple for fleet owners, as we call them, people who are managing fleets of IoT devices. We want to make it easy for them to scale as quickly and seamlessly as possible. Anytime we build something, either into the platform or adjacent to the platform, it's always with that in mind.

One good example is the tool that we built called 'Etcher,' which some people may be familiar with even if they aren't familiar with Resin. Etcher is essentially a way to earn SD cards and USB sticks and essentially provision IoT devices in a way that's much easier than just using DD, if you use that or any other solution that you might be using and that was borne out of our realization that this was actually a big pain point for our users, that they were having a hard time provisioning their devices. We just built Etcher and actually released it as its own standalone open source tool.

Similarly, that's actually why we built our own operating system, resinOS, because there was no operating system that existed yet that would allow us to run containers on constrained IoT devices. We did the same thing, where we release that as its own standalone open source projects so that people can benefit from resinOS, even if they aren't using Resin the platform. We're always looking for ways to make that process of scaling up and deploying fleets easier and releasing those projects as openly and broadly as possible.

RONALD: Yeah, to add to that going forward, we're also looking to make some improvements into the Resin platform just based on a lot of the feedback that we've gotten as people are managing these very large fleets. We are, right now working on improving the experience when you are managing multiple containers on a single device. A lot of times, people will have microservices where they'll have separate Docker containers for each function that a device is doing and it's doing multiple functions. We're working on improving the user experience of deploying those individual containers and managing multiple containers on one device.

We’re also looking at ways to extend Resin from Linux devices into some smaller devices and some things that are not necessarily running Linux but are still out in the real world, out in a customer environment or out in nature, wherever you have those devices that you want to be able to manage them. We want to wrap that into the Resin experience as well. It's really a constant process of refinement just based on what we see as the IoT develops. Again, it's a really exciting time to be in this industry.

ELRICK: That is wonderful that you guys are keeping your finger on the pulse, in terms of your customer base and the feedback that you're getting to how people are using Resin and then implementing and looking for ways to improve the platform and then also open source and get your solutions into the hands of developers and into the hands of your customer base and that is a testament to just how wonderful Resin is as a company and as a platform. I think everyone out there should then go out and use Resin or at least attempt to use it because the entry into using Resin is very low. You can ramp up and start using it any time and extremely quickly.

ALISON: We encourage anybody who is interested to sign up and it's free to get started. Your first five devices are always free. We have great support. We have a really active community forum so there's lots of people there to help guide you along. But as you said, the barrier to entry is quite low by design so really anybody should go ahead and try it out. If you have a Raspberry Pi sitting at home or at work, we like to say that you can get started over a lunch break and it should only take you about 30 minutes to get your first successful push and see your first Unicorn.

ELRICK: That's awesome. You heard that. Go and use Resin and on your lunch break, you can see a Unicorn. Well, that's it for our podcast today folks. We had a wonderful podcast talking about Resin.io, the future of IoT, all the places that you can use Resin and how to deploy code all over the world, to all your embedded devices and all of your IoT devices. On behalf of Joe, Alison, Ronald, the Frontside and myself, I would like to thank you all for taking the time out to listen to this podcast.

Remember you can reach us at Frontside.io. If you have any projects that you're working on and want to tell us about it, you can reach us there and you can also, if you want to learn anything further about Resin, you can head over to Resin.io and remember you can see that Unicorn at lunch time. That's it for the podcast today and thank you all for listening.

Mike North: @michaellnorth | mike.works

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 79. My name is Charles Lowell, a developer at the Frontside and your podcast host-in-training. With me today is Elrick, also at the Frontside. Hello, Elrick.

ELRICK: Hey, what's going on?

CHARLES: Today, we are going to be talking with Mike North, who is doing all kinds of interesting stuff as per the usual so we'll jump right in. Hey, Mike.

MIKE: How is it going? I'm glad to be here.

CHARLES: Last time that I saw you, I think it was about a year ago at the Wicked Good Ember Conf and we were standing on the beach, drinking scotch and talking about Fastboot but you were doing something completely and totally different then than you are now so I was wondering, we were talking the conversation before we started rolling, that your role nowadays is independent consultant and personal dev trainer. I was wondering if you talk a little bit about that move from the CTO role that you're playing at your old company to kind of moving into that independent trainer, like why and how.

MIKE: Yeah, I do remember talking about Fastboot at Wicked Good Ember. It feels like things have moved quite a bit since then. I have always loved teaching developers. When I've been a team lead, it's the favorite part of my job just because I get profound satisfaction out of helping people get over these hurdles that most of the time took me a much longer time with blog posts and podcasts and incomplete examples and libraries that were out of date and Stack Overflow with half answers.

I've decided to dedicate myself to trying to make it easier for people in an increasingly complex web development world to wrap their head around everything. While I was a tech lead or a CTO, I always had to split my focus between helping developers grow and something else. Oftentimes, that something else was where the deadlines were and the time pressure was. It felt a little bit like I was driving a car that only had first and fifth gear where you're like on the bleeding edge of open source and what was the latest commit to master and [inaudible]. Then like, "Oh, let's be extremely patient with this person. They've never seen promises before because they came from another programming language. Let's help them digest this at their own pace." It's this slow and patient process of building up from the fundamentals and then the bleeding edge is like, "Let's use Babel Stage 0." It was very hard for those two aspects to exist at the same time in myself so I decided I'm just going for the training side. That's really all I do these days.

CHARLES: It was so, but now would you qualify that as the first gear or the fifth gear?

MIKE: That's the first gear. It gets you off the ground. It takes you from stop and gets you moving and then you have to develop your own expertise beyond that. But I like to think I'm developing a really, really excellent first gear. Today for example, I'm converting a bunch of Python developers at LinkedIn who are basically the ops team. I'm teaching them Ember and JavaScript at the same time through a series of about 20 exercises over three days. That process is many weeks long without assistance so this is like, "Let's get rolling much more efficiently and quickly," than via DIY approach.

CHARLES: Now, do you find you have to custom-tailor for the environment or the developers moving from like someone coming from, say C# would have a different experience than someone coming from Python?

MIKE: Absolutely. When I have my material, I have sections that I can drop. If you are a C# developer, I do not have to explain conceptually what 'async' and 'await' mean. You've been working with that for a while. I probably throw up a little example in C# and then the equivalent in JavaScript to sort of create a bridge from your existing expertise into the JavaScript world. Another one -- this is very true -- is teaching Ruby developers how to use Elixir. You don't have to say, "This is a router. We have controllers. There are actions and controllers." There are so many parallels that really it's more useful to help, rather than teach things from scratch to create connections back to the expertise they already have so they're not starting from zero and they can say like, "In the Ruby world, I would think of doing XYZ." Now, I have a map in between that and this new thing.

CHARLES: Obviously, there's a lot, a lot, a lot of languages and environments that you could transition to, probably more than matches your own personal experience, in doing that frontline development. What kind of research do you have to do to develop a curriculum for, say someone coming from Clojure or someone coming from Scala or something like that? Maybe that never happens.

MIKE: I have a pretty, pretty broad background. My entry into programming was a subset of C and then I graduated to C++ and Java and Ruby and I used to do ASP stuff. I've written iOS apps. I feel like I have enough of a foothold into various areas like I know one JVM language. That is usually enough. If you're running a lot of Clojure, I can at least speak Java to you because odds are, you're working with that and you're seeing that and you know it.

Oftentimes, I have what I need. There are situations where I can borrow something in a very cursory level. Not to rip on Scala but I have not found it valuable to make connections to that particular language for clarity and [inaudible] but I have used Haskell before and I'm not a Haskell developer but it is a pure functional language. When trying to help people understand how is this different, then the JavaScript got them running where the Ruby ends up running. It's useful to use something like that. It's a very small language, very simple and you can wrap your head around the basics.

ELRICK: What are some of the particular challenges that you face when bringing in a developer outside of the JavaScript ecosystem into JavaScript since JavaScript is kind of the Wild West that you can do everything in JavaScript? What are some of the challenges you face in bringing in a new developer from Python or C or whatever that may be?

MIKE: You put it very well. It is definitely the Wild West. You can do anything if you have enough [inaudible] yourself and enough power to get serious stuff done. Really, it's like the explosion in number of choices and tools, the explosion of complexity. I learned JavaScript when it was something that you sprinkle on top of your Rails app for a little interactivity, a little animation on a screen or something like that. I was lucky to learn it at that point in time when that was the norm because I've been able to gradually accumulate for more than ten years now. The tooling like using Grunt, using Golf, using Brunch and then stepping up to other more sophisticated build tools. I learned those one by one in the context of real projects.

Now, it's like the mountain is so high, people don't know where to start so that's a big challenge for developers. To throw them into a meaningful project like if you asked a mean JavaScript developer, not angry but the average JavaScript developer, they're like maybe --

CHARLES: I should dare to say that the average JavaScript developer is mean.

MIKE: A little bit and probably maybe [inaudible] with me as well, depending on [inaudible]. But they're going to spin up some project with webpack and Babel and all of these tools. If that's your first exposure to the language and to working with the language, you're operating in an environment that you don't understand.

Research shows that is the less effective option there to slowly building things up over time. I spend a lot of time going back to the basics and making sure we're not working with promises until we've explicitly focused on them, chained a couple together, managed errors and then now, we can work with Fetch. We're not going to jump into that and throw ourselves into this deep end of the pool. We want to incrementally build up skills. It takes a little bit longer but when you have that understanding as you're learning, you get a lot more out of it because anything that you can't get a grip on to as you learn it, it sort of just evaporates into thin air and don't retain that, even if you kind of fill in those holes later.

CHARLES: Yeah, it could be so hard too. Actually, this has been an experience that I've been having, I would say almost for the past two years, as the tools advance, not only you are starting from a place of not understanding but the tools themselves do not teach you. I've had two moments where I got really mad. One actually was on an Ember project and one was a project using webpack but it was the same fundamental problem where in one I was actually working with someone who was very new to JavaScript and an error happens and the stack trace was some just big bundled garbage that gave no insight at all.

MIKE: In vendor.js.

CHARLES: Yes, in vendor.js or in bundle JS. It was like, "How is anyone supposed to learn?" The most fundamental thing about working with Ruby or working with Node or working with anything is you get a stack trace.

MIKE: Debugging is really hard. I think it just takes a little time reaching out to people who are experiencing the Stockholm Syndrome like most of the time, JavaScript developer. We all are working with Ember CLI and webpack. I'm not ripping on these tools but we're used to that complexity in our lives. When we see that stack trace, we're like, "Oh, well. I probably need a source map. I'll make sure that that's there. It's natural that I'm debugging a file that the browser is not really seeing like it mapped back to my source code debugging." This is natural to us.

But if you put that in front of a developer who hasn't been living under those circumstances, the number of times they raised their hand is like, "What the hell is this?" It is just amazing and it really helps. I've reset my expectations to what a normal programming experience should be and JavaScript does not provide that today. That is really challenging to keep someone in the midst of all that.

CHARLES: I feel like it's hard and do you think we'll ever achieve that? Or is it just going to be a constant hamster wheel of progress versus the tooling to educate what progress has been made or to communicate what progress has been made?

MIKE: I think the tooling is fine but it's just that we have a gap in terms of learning experience. We just need really -- I'm not voluntary here because I've got a ridiculous backlog -- a couple long tail horses working with vanilla JavaScript, rendering some stuff on the screen, maybe a course of React but no JSX yet, just create component. A couple of things to fill in a gap between where maybe code school leaves off and where you are expected to be by the time you start interviewing for a spot as frontend developer on a team but there's a huge chasm right now. There's the intro guides and then there's professional life and trying to bridge the gap between those is ridiculously a challenge right now due to the huge ramp up of complexity from like, "Let's do some stuff in the console," to, "Running transpile JSX code with async [inaudible]. We've got regenerator in there to polyfill generator functions." There's so much in your average JavaScript at these days.

CHARLES: Your work that you're doing at LinkedIn, part of it is trying to bring and train developers who come from more nontraditional backgrounds, including a lot of things like boot camps. What is your experience of their experience coming in? Are boot camps doing the right thing? Are they teaching the right things? Are they trying to kind of parachute them on top of that mountain? Or do you find that they're just at the base camp, so to speak? Because it sounds like your approach is like you've got to really start from fundamentals so that you can understand the layers of complexity if you're going to, someday stand on them.

MIKE: I think a lot of the boot camps are doing an excellent job. These days, the employees we have at LinkedIn who come from boot camps, I would bet on them against your average MIT grad every time, just because their education is so practical. It's amazing that in the world of computer science, the stuff that you're taught in school is a little bit farther removed than one would expect, compared to the stuff that we do every day in our jobs -- building real apps.

I do not need to know in my day-to-day work at LinkedIn how an operating system works or how to build a device driver. This is a little bit too fundamental. It's the wrong abstraction for practical everyday work for most people. Where in these boot camps, they focus completely on the practical. In fact, I've been fortunate enough to get involved with the REACH program here at LinkedIn, where we hire explicitly people from nontraditional backgrounds like boot camps. They're not all from boot camps but many of them are. We just hired 30 of them in March.

The pilot program, I think we've hired two or three in our New York office and it just went really well. It started like, "Let's double down and double down again and double that again." This time, we're doing 30 and I expect there will be a new round next year where we poll even more. The idea is we take these REACH candidates and pair them with a mentor engineer for six months. At the end of that six months, we had to make a decision as to like this person at the level we expect of an entry level software engineering hire. From what I've seen, we're doing really well at preparing these folks and they're unbelievably valuable to the teams that they've been placed in.

ELRICK: That's amazing. That's very interesting. Is there a standardized curriculum thing that each mentor will follow to get this person after they entered his REACH program and then ramp them up or is it like each person just goes and looks at what the person knows and then ramps them up accordingly.

MIKE: I'd say, it's a mix of both. We have a set of technical trainings for them or we'll have a testing expert from within the company and teach a little testing seminar to them. There's that standardized curriculum there. But the nature of being taught by boot camp or teaching yourself is that you're going to have holes in your knowledge and it's not often predictable where those holes will be. That's why we make sure we do this mentorship very explicitly and over a long period of time so that if it turns out that you never learned about how to work with tree-data structures. That was not part of the go-no/go decision that brought you on but we should probably, at least get you there. At least to the point where if you're traversing a down tree and you're like parent and child, what is this, what do you mean by leaf-level node. This is stuff that is actually meaningful for web developer in some cases.

CHARLES: In the context of the work that you're doing with the REACH program but also touching on something that we talked about at the beginning about the first gear and the fifth gear, part of generating a curriculum is still being in contact with what's up in the fifth gear right because ultimately, what you're trying to do is you're working with people who are in first gear or looking to get a smooth transition in the first gear but at the same time, you want to set them up and you want to be in contact for what's in fifth gear now is going to be first gear in five years. How do you feed that in?

MIKE: I'm fortunate to have a great team that I work with here. This group that I roll up to in LinkedIn, they're experts and you probably know of like Chris Epstein and Tom Dale and Steph Petter. A 15-minute coffee break with one of these people is enough to keep [inaudible]. Sometimes, it's a little bit like drinking from a fire hose because it's like I spend an hour with a student trying to help them understand like, "This is why a Promise is useful. Here is the callback equivalent," and then now, "Let's dive in to Glimmer. Why this track annotation is the right way to go for automatic updating." It sends me for little bit of a loop sometimes but it is definitely keeping me up to date.

The other factor, of course is when you've been doing this for a while. History sort of repeats itself so a lot of the patterns that we're seeing today, I've seen somewhere else. I was working with code splitting when I was writing Dojo JavaScript code years and years ago. I was defining my module layers in a very explicit way. I had to do that. I didn't have done a webpack that would figure out, put these splits are. But I have that experience to look back to and for that reason, it is not often that an entirely new concept comes along. Oftentimes, they're like amazing refinements on things that how to smell like stuff that we've used before in the software engineering world.

CHARLES: Yeah or here's something that has never been used, is very prevalent in these other context which we're going to apply here.

MIKE: Exactly.

CHARLES: And like, "Oh, my goodness. It's a perfect solution." In addition to the work that you're doing with LinkedIn and developing those training curricula and stuff, you're also doing some work for Frontend Masters in an area that's very exciting, I think to me. I'm sure it's exciting to you because you decided to throw a whole lot of time into developing a course for it. That's in the development of progressive web apps, which for me has been like this thing that I'm so curious about but I'm like a kitten playing with a little yarn ball. I want to dive in but I'm just going to tap it with my paws right now.

MIKE: Yeah, it's a really interesting area and I think that even if you're not using progressive web technologies today, it's one of these things that sort of reinvigorates your energy for JavaScript's future and what may be possible soon. Steve and I have put together this amazing progressive web app course, which has I think like 18 short examples of iteratively building up a grocery shopping app. If you've used InstaCard or something like that, we start out with app already built and it's like a single-page app as doing everything that you would expect. After a few of the exercises, it works offline. After a few more, you can add stuff to the card and background sync, push it to the API when you come back online. We get deep, deep, deep into service workers.

That’s one of the areas that my work at LinkedIn and my teaching with Frontend Masters overlaps really well because I've been heavily involved in creating our service worker for LinkedIn.com. I may be able to take some of what we've learned here and disseminate it a little bit so that, hopefully fewer people have to learn the hard way. It's best to keep things simple at first and add on functionality.

I'm about to cross like the [inaudible]. This is my favorite just because the example turned out to fit so well and in particular, on Frontend Masters, I think Steve and I have had contrasting teaching styles but they complement each other so well because I'm like the 'melt people's brains' instructor. I love to throw people exercises that are like 120% of what they can do and it's going to hurt, just like when you're lifting weights at the gym, like you're going to beg for mercy but we're going to make you strong.

Then Steve, just listening to him, even with I am in the classroom and he is teaching me Electron. He's so energizing and he's really funny too but not in an overtly cracking jokes kind of way. He's just so fun when he teaches. I think it is a really good combination just because things lined up just by luck and through hard work and just the right way out of a couple of important areas.

CHARLES: Now, just for people who might not be familiar with the term progressive web apps, what does it encompass? Do people actually call them PWAs?

MIKE: No. I'm going to start, though. I like that. That carries very well over a video chat or something. Nobody knows how to spell that: P-U-A? P-W-U-A? It is a rejection of the old idea that in order to take advantage of some web technology, it has to be supported in all of the browsers that we need to support. The idea here is to hold as a core tenet of our design practices, the idea of progressive enhancement, meaning we serve up a basic experience and where we can take on these superhero features, like the ability to work offline, the ability to receive push notifications, we go ahead and do so.

If your browser doesn't support this, that's unfortunate. No big deal. You still get a good experience. But if you're using a very recent version of Chrome or Safari or you have a new Android device, these browsers can take advantage of sophisticated metadata or sped up a background process that can serve up data to your app and your app doesn't even know that there's something between it and the API. That is the idea of progressive web apps -- apps that become superheroes where possible and they still work and provide a great basic experience for antiquated browsers like IE8 and Safari.

CHARLES: The idea theoretically, you could work without any JavaScript or whatsoever. What's the ground floor there?

MIKE: That is ideal. I think server-side rendering, which is what you're talking about there, even if JavaScript is not working, just HTML and CSS will provide a basic experience. That's great but that's not a modern browser technology thing. If you have JavaScript turned off in today's Chrome, like Chrome 60, versus IE9, both of them working with them without JavaScript. What we're really talking about here is app-like characteristics, where we are pushing web technology to the point where you will swear that this came from an App Store. It's on your home screen. It's running in the full screen. You're getting push notifications. It works offline and you can store a large amount of structured data locally on the device. All of the stuff sounds like the list of reasons to reach for native mobile technology because the mobile web is not good enough. But in fact, it has a feature set of this family of progressive web technologies. It's really like a web app that is so good and so modern that it feels and looks just like a native mobile app.

CHARLES: That sounds so hard to do right.

MIKE: Well, it is now, just because what we have to work with can be thought of it like a basket of ingredients, rather than a solution that we drop in. But over time, as more people start working with these ingredients, I think we're going to see a lot of consensus around the best patterns to use and boilerplate code will fall away as we can identify that the set is in fact commonly needed and not a beautiful and unique snowflake.

CHARLES: Because it seems like the thing that I always struggle with is not wanting to put the critical eggs in the basket of a superhero feature or have you being able to provide an alternative if the superhero feature doesn't exist. Some features, if you just don't have it, that's fine. You can turn it on if the capabilities available but certain features are very critical to the functioning of your application. I'm casting about for an example and I'm not finding one immediately but --

MIKE: Offline is a great one. That fits pretty neatly. If you're using an older browser or if you're using Safari, which by the way, I should stop ripping on Safari. For the listeners out there, we saw a commit lend in webkit, where service for APIs are beginning to be stubbed out. No longer do we have to look at length. Service worker, enthusiasm and Safari has got it in the five-year plan. There was motion last week. We haven't seen motion in ages so thank you Safari Team. Thank you. Keep up the good work.

CHARLES: Is there a discipline of Safari-ologists who monitor the movement of Safari to bring this news?

MIKE: Of course, we monitor it because right now, Chrome and Firefox, they are pretty much hopeful in terms of supporting this modern stuff. Opera supports this modern stuff. Samsung's fork of Chromes support this modern stuff. Especially when we think about the mobile web, you got to worry about Android and you got to worry about iOS Safari and right now, like we've talked about these progressive web apps, you don't get that superhero experience on an iPhone or an iPad.

Once we crossed that threshold, this is going to have a breakaway level of adoption because there are no more excuses. Essentially, for a mobile web experience, you can send push notifications to the user. That is huge. That is probably at the top of the list for why some people use native apps, instead of mobile web. The more we can do that, the more we can make it so that a great LinkedIn experience can be delivered to your phone without having to install a binary.

I just have to update Facebook the other day and it was over 100 megabytes. Why do we need to do that? You should be able to make it work with less. I'm sure that there's some great stuff in there. Apparently, Snapchat filters are popular but I don't need this. Can we code split that away or something because I don't want to have to download that? I can't even download it on the cell network because it's over 100 megabytes. It's really exciting to see the web start to compete with this heavy mobile experience because now I think is ready.

CHARLES: Now, when you talk about push notifications, you're talking about being able to send things to my lock screen.

MIKE: To your lock screen while the browser is not on the foreground, while the app is not open. Essentially, you're installing a lightweight process that runs in the background. It receives events that originate from your server and the user can tap on them and then your little lightweight worker process in the background decides what to do when that tap happens, like open up the app, take them to this URL or something like that. That is a game changer. That's huge. Or background sync like the user added some items to their cart and then they lock their phone and now, their plane has landed. That's why they were offline and they get back on the internet and without them having to touch their phone, now we can push that data to the server and everything's in sync, rather than like, "Please revisit your app. We need to run some JavaScript code to flush IndexedDB or API." It still feels like a hack at that point. This is a fluid experience.

ELRICK: Wow. This is exciting for me as I don't have any more space on my cellphone, thanks to all the apps that I have to install to do various things on the web.

MIKE: You're not alone.

CHARLES: Yeah, it's crazy and just the amount of code sharing that you can have, I guess that doesn't happen much these days on the web where you've got these popular libraries out on CDNs so that the chances are that you've got jQuery 1.2.1 on your cache, you've got 16 versions of jQuery so most of your web applications don't have to do that. I guess we kind of do the equivalent of statically linking everything.

MIKE: There is a benefit near that where we have imperative code managing our cache, instead of just relying on the HTTP cache or app cache, if you have a vendor.js file that is not changing over six months, there is no reason you should be re-downloading that every time you deploy your app or letting the browser evict that, just because memory pressure is high from Google image search results or something like that. We really don't have much control over it. But with a service worker, we can say, "Hold on to this," or maybe like prefetch the next version of the app so that we're going to show you the old version now but the next time you refresh, here's the new version available instantly. It's downloaded in the background and it's like click to update your version, like it's already here waiting for you. That's huge. That's amazing.

CHARLES: That is amazing. Although the complexity skeptic in me is thinking, "Oh, my goodness. Now, we've got all this state that we're storing on the server. We have to have data migrations." We need some sort of migration mechanism for our clients-side state and perhaps some transaction and rollback in case you're not able to successfully migrate your data. It sounds like a lot of fun but I'm just imagining we really are getting started here. Has there been any work on that aspect?

MIKE: If you've ever worked with IndexedDB, it does have a concept of migrations. Basically, the data you store on a device has a version and when you read in what's called a file but it's a database, when you read that in, the first thing you do is you basically bring it up to date incrementally. You'll bring it in, you're looking for version nine like your code wants version nine. What you see is version two because your user hasn't been at your site for six months and you're going to take it from two to three to four to five to six. Each of those, essentially constitutes a migration. We just have to apply the same principles of forward-compatible changes.

The escape hatch here is remember it's progressive enhancement so if we had to destroy everything, fall back to a basic experience and start from scratch, like discard all of our data, it's really being held there as an optimization. Some people use this immutable caching strategy or basically, like rolling out a new service worker version constitutes for the most part. Any data that wasn't created by a user you're going to discard that and you're going to fetch it new. You don't have to worry about like, "Crap. This six month-old thing is still plaguing half our users and we can't get rid of it," like you can have [inaudible].

But you should really check out this course. It is simpler than you think and what we demonstrate is not a trivial like hello service worker. It is taking in a classic single page app, making it completely offline, having it exist on the home screen and I think the service worker ends up being no more than 100 lines of code. It's not too bad.

ELRICK: I'm definitely going to check that out because my progressive web app journey is still on just service workers.

MIKE: That's very [inaudible], though.

ELRICK: Yeah. I'm definitely checking it out. Sounds like a really fantastic course.

MIKE: I've been focusing a lot on this area and another one is security. The reason I picked these two is because developers are not really going to learn about these on the critical path to [inaudible] plus they learn about them the wrong way. As the JavaScript world is becoming radically more complex with each passing year, I've tried to target some of my efforts towards areas where they are not getting as much attention as I'd like to see, just because we have to focus somewhere. Obviously, getting the app out and figuring out how to make the build tools work for us. Without that, we can't do anything at all.

One of the courses that's coming in September for Frontend Masters is a one-day web security workshop or we'll do with like cross-site scripting, how to work with certificates because if you start playing with HTTP/2 -- the next generation of HTTP -- you will need to generate some certificates for development at least today you need to. I've seen some amazingly smart developers get this dangerously wrong to the point where they compromise their own machine and anything that's on that machine, just by trying to set up dev environment.

Typically, I'm an optimist but when it comes to this PWA stuff and security, I am paranoid. I feel like, we as a community need to get together and have the discipline to brush up in these areas so that as we introduce all of this new stuff, we don't end up opening a bunch of holes. Nowhere near the same rigor as put into frontend compared to backend and now, the line is blurred. Right now, we're server-side rendering so our code is running on the backend somewhere so injecting something can really mess things up in a bigger way.

ELRICK: Yeah, I think that's a fundamental characteristic of someone does going to be involved in security paranoia. You have to be paranoid about everything.

MIKE: Yep. I don't trust anything.

CHARLES: It's important to make those things easy because I'm definitely fall more into the hippie camp like, "Everything is going to be fine. Let's trust everybody," which is I know is totally unrealistic. But then you get into these secure technologies and you learned enough of it just to get the task that you're going to do and then you forget. SSL is a great example. Over the course of my career, I've learned how SSL certs have worked probably, at least 10 times.

ELRICK: Right, [inaudible] you had to set it up in production.

CHARLES: Yes, exactly and then I promptly forget about it, never worry about it again and then the next time I'm like, "How did that work? What’s this trust chain? What?"

ELRICK: Exactly. I read a study from Carnegie Mellon a couple of years ago that showed developers observe security best practices dramatically less than the general public and the general public is not good. Do you know what I'm talking about when I say a certificate warning and a browser, there's big scary red screen saying like something is wrong here? Before the Chrome team put some effort into improving that, 70% of people would click through those and proceed anyway. After their improvements, over a third of people still clicked through and that number when you just look at Canary versions of browsers, that number is actually considerably higher close to 50% of our developers.

We’re trained by every broken certificate system that exists on the internet like the legitimate ones or maybe some things just expired. They're training people to just click straight through these things and as a result, it is terrifyingly easy to mess with people. We have to remember as developers, our machines, those have the private deploy keys and those have the SSH keys to commit code to GitHub, we have to treat that like it's a private data. It's really, really important that we make it easy and that we make sure that that easy path is also very safe.

CHARLES: Absolutely. All right. Well, thank you so much Mike for coming by and talking with us. We touched on a lot of subjects but I feel like I certainly learned a lot.

MIKE: Yeah, thanks. It's been so much fun talking with you this morning.

CHARLES: Anybody who wants to go and check out those courses, they're on Frontend Masters. Now correct me if I'm wrong, you've obviously got the one on progressive web apps or PWAs. If it doesn't work offline, it's faux-PWA.

MIKE: Yes, I like that. That's going to become a t-shirt sometime soon.

CHARLES: The fundamentals of progressive web app development, which is now released if I understand correctly.

MIKE: Members have access to everything, you can watch the raw video now. The edited course will be available later this year.

CHARLES: Okay, and that's with Steve Kenny. I am very much looking forward to looking at that and learning more about it. Then you've also got ones coming up in September on TypeScript web security in Visual Studio Code.

MIKE: Yep and members can watch that as a live-streamed event. Frontend Masters even ask people to watch the comment stream so you'll have a proxy question asker or hand raiser in the room. It's really a great experience to be part of a live thing.

CHARLES: Oh, man. That sounds awesome. Then if you are obviously doing your independent consulting and if people want to get in contact, how would they do that?

MIKE: You can find me on Twitter, @MichaelLNorth or you can visit my website, Mike.Works and I have all of the courses I teach and outlines and I can just open up a little chat bubble on the lower right, ask me any questions that you have. I am really passionate about teaching people. If you like that's useful for your team, please reach out and I'd love to talk.

CHARLES: Fantastic. Thanks, Mike and thanks everybody for listening to us. If you want to get in touch with us, you can always do that. We're on Twitter at @TheFrontside and email, [email protected]. Thanks, Mike. Thanks, Elrick and I will see you all later.

MIKE: Thank you so much.

ELRICK: Bye.

Jason Jaynes: @jasoncjaynes

Jeff Wilson: @ProfDumpster

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 78. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. With me today are Jeff and Jason from Kasita. Now, Kasita is one of the most exciting products that I think we've gotten to work on here at Frontside in the last five years. We're going to be just talking about it because, I think it touches on a lot of the aspects of what makes software development and startups and just the emerging economy exciting.

I'm really thankful that we get to have you all on the podcast. Welcome Jeff and welcome Jason.

JEFF: Thanks for having us.

JASON: Excited to be here. Thanks, Charles.

CHARLES: Now Jeff, you are the founder of Kasita, the CEO and I believe your official title over there is 'Professor Dumpster.' Maybe you could actually unpack for us a little bit of what does that title mean? How did Kasita come about and what is it today?

JEFF: A couple of years ago, I did a radical, social experiment around housing. I went and sold everything I own for a dollar an item out of a 3000-square foot house and moved into a 33-square foot used trash dumpster for a year. The idea of that project was to live in 1% the size of an average American home and try to use 1% the energy and water of the average American home.

The project took a little bit of a twist, you might say and about part way through it when the dumpster started getting tricked out, I started thinking about the whole nature of housing and how we need to do something different and how that grand future probably would not be a gated community of dumpsters.

CHARLES: Now, I assume you cleaned out the dumpster before you actually went to live in it.

JEFF: Yeah, it was a fixer-upper. We give it a bit of a scrub and did some testing to make sure there wasn't anything nasty left in there. That went for about a year and a couple of months after that, I actually first set down with Jason because he was the only person that I knew in the entire startup scene, in the entire world. He said, "Wilson, you had some crazy ass ideas like this dumpster thing you told me about. This one might actually work, this Kasita thing." Here we are today, we're working together.

CHARLES: Wow. This was something you just did on a lark. You didn't have the idea of starting this business but it was actually through the process of actually living in this dumpster for a year that the idea emerged or was there a master plan going in?

JEFF: I don't know, Jason do you remember any kind of master plan when I first told you about the dumpster?

JASON: No. When we first met to talk about the dumpster, it was an early morning, I believe in 2010 or 2011 and you're incubating the idea. At that point in time, there was nothing on your mind or you aren't looking towards the future of housing at all. You were just trying to figure out how you were going to move into a dumpster and people thought you would be crazy. Of course, I've validate it and I thought people would think you would be crazy.

CHARLES: That is a pretty radical idea, the future of housing being 1% of what it is now. How do you see that playing out? How is that possible? How do you shift people's mindset away from that?

JEFF: One of the bigger things we're trying to do with Kasita, there needs to be a massive shift in the wider way that we live in our homes. As everything else is moving towards on demand and as a service and as everything's being sort of productized, those are some of the core ideas behind Kasita. We think about Kasita a lot more like an iPhone or a Tesla than we would think about it as a single family home or an apartment block or even a micro-unit. That's why Jason and I are standing together here today is I represent a lot of ways, a kind of vision and origin story of Kasita but in a lot of ways, Jason represents the future of the software and integrated IoT that's going into these things.

CHARLES: There is definitely a lot going into these things. I remember when Jason first started telling me about it because it is like an iPhone or a Tesla but, I think especially the Tesla is a great analogy because you have not just like a normal software or even really a hardware project, you've got architectural concerns. You've got manufacturing concerns. You've got, I assumed geopolitical concerns in terms of the politics around zoning and housing and real estate, all rolled up into a big startup. When I think startup, I think let's get a web application up and running and we're providing some service. This is cross-cutting at least five industries, it feels like if not more. I'm curious, what's been the experience in terms of wrangling that aspect because I think it is very unique in a startup today but it got me wondering is this going to be the normal in five years?

JEFF: We've seen a movement recently in the venture community. Even a few years ago when we first started raising money was highly-regulated industries are hard, hardware is hard, "Thank you very much. We're going to go looking for our next two Stanford computer science dropouts to shove into a wee work and not have to deal with all of this kind of stuff." I think I've seen a shift to where people from the individual level up to the folks funding these things, see the massive opportunity in highly-regulated complex problems like housing and you're right. Jason and I are looking out over our shop floor here where we've got guys out there that are plumbers or traditional electricians all the way upstairs here to folks that have been mayor pro tem of large cities with PhDs. Bridging all of those individuals into a startup culture and then looking at the complexity of the landscape from a regulatory standpoint, autonomous cars are a breeze relative to the kind of complexity we're dealing with.

CHARLES: Did you know this complexity walking in or was it a classic overoptimism?

JEFF: No, it wasn't classic overoptimism. I'm always asked, "Are you a designer? Are you an architect? Are you a real estate developer? Are you a technology guy?" and I think if I would have been any of those besides a guy living in a dumpster, I wouldn't ever been crazy enough to try this.

It's one of our core precepts as well. Jason had never worked with IoT stuff before. Our head of manufacturing used to build LEDs for Philips. Our quality guy inspected Cadillacs. Our manufacturing engineer built Boeing jets. The ideas that we're not pulling a lot of people from these traditional industries, we're pulling smart people that are passionate about our mission and to solve this, what is really a Rubik's Cube of a problem.

JASON: Yeah, I think the other thing to add to that that Jeff is not getting himself enough credit is that from very early on, Jeff always looked at Kasita as a product that was going to incorporate multiple disciplines. He was very careful in how he orchestrate it and built the team to make sure that he was bringing the right expertise and the right areas together and then forcing those different disciplines to figure out how to meld and work together to build the Kasita. But the Kasita was from the beginning just about building a micro-urban home. It was about building a product of which part of that was a home, where people live obviously, but there's a whole lot more to it that we're working towards. I think even go back and Jeff, it might be relevant for you to talk a little bit about the approach that you took to just create an initial design for Kasita, which I think is revolutionary in itself.

JEFF: A big part of our DNA was product from conception. When I was living in the dumpster, I recruited a couple of the top architects in the country really to help me turn that dumpster into a home. The way you're trained in architecture school, I think a lot of folks come in there with Buckminster Fuller kind of dreams and you're told pretty quick that you better bring things up to code and you better make things that sell or you're not going to eat when you get out of here.

The idea was that we would start off with a product designer and not design a home. The kind of struggles in the dumpster taught me that we needed to go at a different approach so I went and recruited an industrial designer. One of the requirements for that person that he or she had never designed a home. This person had lived under a staircase and never designed a home so I said, "You're perfect."

CHARLES: I like that and I'm curious, Jason from your perspective, what was it like to have gone through this? It sounds like what you're doing is asking people to bring their expertise but not their set of expectations like the industrial designer. What was it like for you coming primarily from the software development world to step into this pan-technological realm and what was that experience like and what were the things that stretched you and you found surprising?

JASON: I think early on, I realized that it was going to be a bit more challenging maybe than I thought. Really, what it required was me to think outside of my discipline. Obviously, not only from the perspective of what we were doing on the IoT frontend, how we were melding software and hardware together but then going all the way over to the physical building structure and thinking about on a weekly, daily, hourly basis on how we are interacting with the other disciplines.

An early example was, and this is one that I remember that's quite funny is one area that we wanted to make sure that we had covered in our research and understanding from IoT perspective was smart locks and how we were going to provide a smart locks for the data. We went out and did a lot of investigation, brought a number of leading smart lock solutions into the lab and tested them and narrow our list down. Then I recall vividly walking over to the architects to excitedly tell them we had selected our smart lock that we were going to use.

They very quickly inform me that that lock wouldn't work because we needed a mortise lock and not a standard door lock. I realized that you can't work in a vacuum and just solve your problems. You have to be working together to make sure the solutions and the products you're selecting at work in accord with the overall design. That's continued to manifest itself.

Every day, I'm down on the manufacturing floor, working directly with the electricians and others to make sure that our equipment is placed properly, where are we going to place our equipment, how are we routing around plumbing and pipes and other things that exist there and how are we locating things properly. It's an ongoing experience, which has definitely taken me out of my traditional software role but it's done so in a very exciting way and I've enjoyed it. It's just realizing that you have to actively be communicating across the organization with all groups and really, you can't take anything for granted.

CHARLES: The number of different disciplines and technologies is really staggering, even if you limit it to just considering the set of devices that you're integrating. I was actually hoping we could talk a little bit about that. Now inside each Kasita, at least the ones that you're building right now, how many different devices do you have? How do you take all these different devices and turn them into a product or integrate them into something that itself is one product?

JASON: If you were just to look at the technology bill of materials, what the products are that we're incorporating into our current Kasita design, there is around 50 different products and product parts that we're bringing together to build out the technology solution. If you narrow that down to what the end user is actually seeing and looking at, there are about seven noticeable products that the end user would see or they would recognize everything from a Sonos connecting amplifier to an Amazon Dot to a Nest Thermostat.

Obviously, getting to that list of bill of materials and deciding on that 'subassembly of technology pieces,' took us quite some time in a number of iterations and a lot of outside engagement and talking to experts and trying to decide what were the best devices to bring in. But the other side of the equation was something that we kind of decided very early on in the process and kind of thinking the world of first principles was that, we wanted to make sure that Kasita was the primary interface to the user. We didn't want somebody else sitting between us and the end user. We wanted to be able to work with other products but we still felt at the end of the day that the end user, when they were living inside of a Kasita, when they were controlling the Kasita, when they were changing the state of the Kasita, they needed to go through our interface.

With that as an initial first principle, you can begin to imagine that all the other parts of the system architecture and the way that we design things, the way that we select products and built things, it begin to derive themselves. Everything from that, immediately we needed an app and lo and behold. We were able, fortunately to work with you guys, the Frontside, to help us get our initial app concept up and going. It went from there and I can talk more about it.

CHARLES: I think I really like that as a first principle. I really just want to inject a vigorous sense of agreement because I think it's so important, especially when this is the place where you're living. You want to imbue that inhabitant with a sense of ownership and control. I don't know if you would be able to do that if there were a bunch of different touch points and it didn't feel integrated under one product. In other words, this is my home, this is my Kasita. Is that the idea behind making sure that there was really only one interface?

JEFF: We prefer to say 'Mi Kasita.'

CHARLES: I love it.

JASON: Absolutely, that's the idea. I think from a consumer perspective, if you've ever personally gone out and ventured through the halls of Home Depot or Best Buy and purchased some smart products off the shelf and brought them into your house and try to get them up and running, you very quickly learn that. It's not only challenging to get these devices connected in a way that you can control them but there's also this notion of there's an app for that. Every physical device you ended up putting in your how, has its own app for control and that becomes very overwhelming in a very short amount of time for the user.

We did not want that to be the case with the Kasita. We wanted them to walk in the door from day one and immediately feel at home and feel like they have complete control of the Kasita, in much the same way when you go purchase an iPhone or you purchase a new Garmin watch or you purchase a new Android device, you're up and running with that ecosystem and you're interacting with that interface. We wanted people to be interacting with the Kasita interface to control their home because that's part of the product.

CHARLES: I like that. It must present some unique challenges because I think you said it best. Every single device that you have comes with its own ecosystem and that ecosystem has its own APIs, its own web interfaces, its own applications and though there are walls around those ecosystems, what are some of the challenges you encounter in trying to punch holes through those walls so that you can hand information and control from one ecosystem to the other while providing a seamless experience to the user?

JEFF: When you're talking about that, Jason one of the things that is often left out of this equation is at this specific point in space-time, it's very difficult to do that. But then to have any sort of semblance of planning for the future and future-proofing the system as developers usually call it, one of the reasons why you don't see a lot of Nest thermostats in multifamily development is because a developer knows that they're not going to ever have to replace a normal light switch. If it's a Lutron switch or if it is a Nest thermostat at some point, it's going to have to be replaced. Not only the physical replacement of the stuff but from a software side, making sure that we can continue to communicate with these devices in the future, I think is a big problem to solve.

JASON: That's absolutely right. I think very early on, we recognize and realize that we were going to have to build software and a component that acted, if you will as a gateway for sitting between the end user and the end devices and facilitated the control of the end devices. Obviously, being able to accomplish that, one of the challenges is and I think, Charles you've seen this in your world because I know you've got experience with IoT is this whole proliferation of standards and protocols like if we're going to talk to the lightbulb or we're talking via Z-Wave or ZigBee, or do we have to go through a Philips Hue hub because that's the only way to actually communicate with it. Is there a separate way via Thread or Bluetooth you communicate with this device?

In a very quick fashion, you get to this point where you can imagine that you've got a physical hardware controller that has four different radios in talking to four different device types. One for talking to Z-Wave, one for talking to ZigBee and it becomes overwhelming. We did a lot of research across the protocols that were available, mapping them across the devices. Early on, we were excited about the potential of Z-Wave but more recently, where we've shifted our attention quite honestly is looking for devices and device manufacturers who see the opportunity and Wi-Fi enabling their hardware devices and then providing either direct control of those devices in an IP-centric way over a local area network or even through the cloud.

What that affords us back to Jeff's future-proofing concept is if you have Wi-Fi up and running and the device can get on the Wi-Fi network and there's a way to communicate with it, then it makes it a lot easier for us to sit between the user and that device and send commands and control that device. The other side of that, which I think continues to be a challenge and will be a challenged for the foreseeable future is a lot of the device manufacturers to the point that you brought up are still forcing you to go through the cloud to communicate with their devices. They don't allow for a local area network communication directly with the device and there's good reasons for doing that. But what that means is if you lose internet connectivity, you no longer have control of that device.

CHARLES: Obviously, you've got probably pretty strict criteria about what it takes for a device to be integrated with Kasita. Is that a nonstarter right there?

JASON: It's actually not. A nonstarter with be the device communicates via protocol that we can't interface with or the device works over a Wi-Fi network but has no API for controlling cloud or local. The third piece of that equation and fundamentally is the final nonstarter and really probably should be the first one and it's one that we take into consideration every time is that there should be a physical override for the user if internet connectivity is lost. What I mean by that is if we select a smart switch and the smart switch goes offline and there's no more connectivity, the user has still be able to walk to the wall and press the power button and the light should come on.

There always has to be an ability for the user to fall back to the same old fashioned physical control in the absence of Internet connectivity or local area network connectivity. But the primary things are ability to fall back to physical control, ability to communicate over Wi-Fi or standard IP-based protocol, then the third one would be some form of API access, either remotely via the cloud or locally via the local area network.

CHARLES: Wow, that's actually a great list. It's got me wondering, obviously you've encountered devices that have fallen on both sides of that divide. Do you feel like that's just a blip and we're going to be trending more towards devices that are happily and easily integrated or are we still seeing some moving and jostling as people maybe try and corner little parts of the market and make their device deliberately make it not easy so that you'll try and force people into that ecosystem?

JASON: The latter, however we have two guerillas in the market right now that I think are helping drive the other direction in the way of Amazon and Google with Google Home and Amazon Echo. What they're doing is they're saying, "If we sit in the center and one of the interfaces for voice control for the user to control their home, then we're only going to work with devices that we can communicate with and that we can control through the cloud," and quite frankly, what that does is it puts the burden back on the device manufacturer.

You could actually say three if you threw Apple in there. I don't want to leave Apple out with HomeKit. But my point is that the device manufacturer now has to find a way that the end device can either communicate via standard TCP/IP network-based connectivity that we all know and love from a developer community perspective or they have to insert a hub into the equation that can handle that form of communication and then communicate over its own proprietary wireless connection, which is in the case of Philips Hue, it's exactly what they do.

JEFF: I would draw analogies here to some people get really tired of this, particularly the real estate people of me talking about the iPhone but that kind of leap into and integrated piece of hardware and software. There were certain things happening in 2007 that didn't make the iPhone or something like it, something that might happen but something that had to happen. This kind of cold death to the universe that we could see with all of these walled-off ecosystems, go in their directions and iterating into a space to a nobody owns anything and nothing talks, I think Kasita is a solution to that to where we're looking like combine all this stuff under one roof and build a single user experience, much like not having to pull your Palm Pilot out of one pocket, you're Rio MP3 player out of another and you're your Razor or whatever it was out of the other like integrating into a single experience, rather than a sort of convenience, which is what a lot of the IoT spaces right now in these walled-off ecosystems.

CHARLES: That actually makes a lot of sense and clarifies it in my mind quite a bit. It clarifies one thing but then, immediately raises new questions. When the iPhone first came out, you had a set of basic integrations between your MP3 player and your web browsing and your calling and calendaring, so and so forth. Then, I don't know what was it like, a year and a half later, they actually came out with an SDK so that you could actually develop apps -- third-party developers could actually develop. Sell and distribute in apps -- to the iPhone. We're all really happy with the way that worked out.

I guess my question is does this analogy carry forward then also for Kasita? Is there a future where you have third-party developers who are actually selling integrations or apps that would run on this integrated IoT product that is Kasita or am I stretching the analogy too far?

JASON: I think the analogy is good with the exception that we're not looking to control the entire IoT ecosystem in a way that Apple maybe had look to control the mobile phone ecosystem with providing all of that in one box and the iPhone. We want to work with numerous hardware providers and even from that perspective, numerous folks that want to provide interfaces into our system. As we develop an architected Kasita technology system, we've taken an API-first approach and that's allowed us to build our user application layer right on top of that API but in the future, we see the opportunity to work with third-party developers to extend that, up on that and build their own interfaces to the end user.

Then on the other side of the equation, if you think about what's actually controlling the devices, we're architecting that system in a way that a hardware manufacturer could take an SDK and add Kasita support for their product directly in and make it plug and play when it gets to the Kasita. We definitely see the opportunity, Charles to reach out and allow everybody to be part of this. We consider it quite frankly, a necessary thing. But we don't also want to pretend that we would look to control the whole ecosystem because we just don't have that level of scale, if you will.

JEFF: And you know --

CHARLES: Not yet.

JEFF: Yeah, and we try to keep our ego in the dumpster, so to speak as well.

CHARLES: What would a third-party app even look like in the context of Kasita? Have you thought of like what are some things that you might be able to do?

JEFF: If you don't want to call it directly an app, I think the first stage -- Jason and I haven't talked about this -- maybe more like an Alexa Skill to where you can have the Kasita do certain sets of tasks around a particular experience, which we're already building into the system the idea of moods but I don't know in terms of apps.

JASON: Yeah, it's actually a really good idea. Even though we haven't talked about it, it always scares me a little bit when my boss is coming up with ideas on the fly that we have to implement but --

JEFF: But actually we will have our first -- we're going to call it a skill app, a Kasita skill app. We'll be releasing that say, October 1st.

CHARLES: You heard it here first, folks.

JASON: To take Jeff's idea a little further, I think that is an interesting concept when you think about the Kasita as being an end product and you provide interfaces whether it's the ability for people to write skills that tie into the Amazon Echo or an IFTTT-type capability. The Kasita, as a whole can be controlled -- all the lighting, the sound, all the different temperature, etcetera -- so now you're asking end users to write skills, to control the entire state of the building or of the home and not just doing it on a one-off basis writing skill to turn this light on and off or set the thermostat to this level. You basically box all of that together and make it much easier for people to get from Point A to Point B through our system.

JEFF: Could you say that we're turning the entire Kasita into a board for people to play with, like treat the Kasita as your breadboard?

JASON: I think there is some opportunity for that to the degree that will allow the user to have that much flexibility on the hardware side. I think it is still up for question but I think there's a lot of opportunity there, Charles and not only inside of the Kasita but then you can begin to see other applications as Kasita begin to multiply and people use them from many purposes. Let's take a sample of somebody owns 10 Kasitas and they use them as Airbnb properties and they allow users that live in Kasitas to come in for a short period of time into their Kasita and bring their Kasita profile with them. Immediately, they can make the Airbnb Kasita feel exactly like their Kasita feels when they're at home. Those are some interesting opportunities and ways that we see this technology potentially evolving.

CHARLES: So it will have the same moods, the same behaviors. Any customizations or third-party extensions would also be in effect provided they were software-based?

JASON: Yep.

CHARLES: That would actually be quite amazing. I guess the other question I have in terms of hackability of Kasita is we're very interested in the IoT space and very interested in these products and we have some side projects here at Frontside also like I do a bunch of hobby stuff at home, where I try to integrate a bunch of these things. But one of the things that I really like about what you all are doing is that it's very much 'omakase' in the sense of there's an option of 10 smart locks, there's an option of this thermostat, there's an option of a million different devices but what we've done or what you've done is selected ones that we know are going to work well together.

We've built the software, the control systems, both computer control systems and human control systems to get them to work together as a cohesive product. I would love to do is say, "I would just like to buy that product for my house," even though my lame tinkerings with smart switches, smart locks and audio controls and lighting, which are fun and gratifying the first few times but they don't really play nice together, give you that super sweet feeling.

JEFF: This goes to the overall philosophy of Kasita. We want a turnkey, one-click housing solution. Not only for finding you a place to rent so that you're not fishing around on Craigslist for roommate or having to pay some outrageous fee in New York. You don't have to go mattress shopping. At some point, you should just have to show up with your iPhone and your toothbrush. When you start thinking about the technology inside, it's almost like folks don't really care what kind of Foxconn chip is in their iPhone or even if it was Foxconn that put it there, they just want it to work and they want it to be seamless and turnkey.

It sets up a whole philosophy around, not only our smart kid in the Kasitas but it shouldn't even be a smart kid anymore. At some point, it should just be an experience so ultimately, what sort of UX inside of the Kasita are all of these things bringing you. I shouldn't have to really look at a blue glowing dot that lights up every time I walk by it to be at a comfortable temperature in my house. I shouldn't need a black tube over on my desktop that I yell commands at. I just talk or it should anticipate those actions. That's a future that I look forward to in Kasita to where we move away from having to tinker with devices and even knowing what those devices are to a true-like depth of experience.

CHARLES: I like that a lot. Now, one thing that we haven't covered. We touched on it a little bit at the very beginning of the show when we talked about people feeling in control and feeling like they're truly the owner of the space is the issue of privacy. Obviously, there's a lot of a user's behavior that's going to be passing through software channels as their intentions move through the devices in the Kasita. Of course, all of these devices, they have their own ecosystems, their own vendors so how do you ensure that people's data is going to be protected, especially as it moves through potentially a bunch of different public clouds.

JEFF: Yes, we gave a lot of thoughts to this. Actually, Jason put me on to this book called 'Data for the People' by Andreas Weigend. We took some inspiration on that, from that and set out on what we call it the four cornerstones of this future of the connected home. Those are agency, transparency, security and then the actual benefit that you get from this home. I gave a talk at South by called, 'The final frontier of AI is in your living room.' If that isn't black mirror, creepy enough to attract enough people, I don't know what is.

In that talk, I won't take them out of order. First, we need to make sure that we're focused on transparency. Do people know what's actually being collected on them? I've been toting around my iPhone for 10 years. I'm pretty sure they know everywhere that I have been since then. I'm not really all that sure. Second, agency. Can I actually do something about it? Are we allowing people the ability to switch off, switch on, control where that data goes?

Then third, security. Are we providing another level of security above what you would get out of the box? I'll let Jason talk about that in a minute. Then, the last is benefit. Am I getting ads? Am I getting a slightly better news feed focused on ads or am I getting my rent subsidized? Am I getting a better user experience, better sleep within the connected home? Those are the ways that we think about that in a bigger level.

CHARLES: Is the idea that there's no benefit than it's exploitative? You want to make sure that there's benefit?

JASON: Yeah, I think that onus is if you taking individual data and using it, then the onus is on you as a data collector to try to provide benefit back to the end user. If you can't do that, then I think the question should be why are you collecting the data in the first place? our goal is really looking at it from the perspective of if we know when users are turning lights on and off and what they're setting the temperature in their house to and when they're going to sleep at night, when they're waking up because we know when they turn everything off and turn it back on --

JEFF: Or where this things on the floor are from the vacuum robot.

JASON: Yeah, exactly. If we have insight into that information, how are we taking that information and combining it in a valuable way that benefits the end user? I think that's the first question that we have to ask when we start looking at the data that we're collecting. But at the same time as Jeff said, that data collection really has to be based on this notion of agency, transparency and privacy or security. An agency is simply I have control over whether my data is collected. Transparency, from the perspective of I understand how my data is being used and where it's being sent and then of course, security, I know that my data is being securely transmitted and stored.

When you think about security, we spend a lot of time thinking about not only the data at rest -- once it's been collected is it properly being stored and encrypted and protected -- but then how is that data being transmitted and are we putting the proper fail safes in place to make sure that somebody else can easily gain access and take control of my home and of the things that are important to me by finding back doors into the system and ways to breach them? Those are the cornerstones that we think about and we put first and foremost in our mind as we build out our architecture, build out our system and as we begin to take that data and to turn it back in useful and interesting ways for the end user.

CHARLES: I think that's really important. I think it's a great comfort to hear that you all have a framework for thinking about this so that it's going to be integrated into every aspect of it. I think it's just so important, especially when it's something as critical as the space in which you're living. It's good to hear that it's not just an afterthought but that it's something that's been integrated from the start.

Well, Jeff, Jason thank you guys so much for coming by and talking with us. I really think that Kasita is an exciting product and I think that it was an exciting project, certainly for us to get to work on, even though we were only seeing a very small sliver of it. We still got to perceive the whole enchilada that you guys were working on and see that just what a unique startup that really is, not just you're moving outside of software, integrating a bunch of different devices, integrating that with a unique home that's going to be designed, architected, manufactured and then thinking, then even rolling it up a degree further about how is this going to be integrated into the urban spaces in which we live.

I hope that we see more startups that really engaged all those different disciplines. I think that with the technological changes that are happening, that's more and more a possibility. The price on software, the price on materials, the price on these smart devices is all coming down so it really enables people to take on scopes that might have been just completely impossible, even with someone who's overly optimistic. I hope that people look to it as an inspiration and it really was a great project for us to work on. I also understand that if someone does want to jump into this space and get involved, you all are hiring.

JEFF: That's right. We are hiring for a broad range of positions. We're expecting to be doing a lot, more hiring soon. You can go to Kasita.com/Work and at the bottom of the page, you can also see that we have an open house here in Austin every Thursday morning from 9:30 to 11:30. The folks can come in and check out the crib.

CHARLES: All right. Fantastic. I certainly really enjoyed getting the tour the space, what was that? Back in March? When you revealed the baby units?

JEFF: Yeah, it was March at South by.

CHARLES: Yeah, it's really something to see. If you are in Austin or you live here, take the time, go see it. It's really cool. With that, I guess we'll wrap it up. Thank you everybody for listening and as always, you can get in touch with us at @Frontside on Twitter or Frontside.io or send us an email at [email protected]. Thank you all and see you next week.

In this episode, we talk about IoT: what’s coming, why we’re intrigued, and how we’ve already started it incorporating it in our office. In the next episodes to come, we will be having guests on the show to take a deeper dive into this technology. If you have any suggestions or know people we should reach out to, please get in touch!

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #77. My name is Charles Lowell, a developer here at The Frontside and your podcast host-in-training. Today, I have with me two other developers here at The Frontside. This is going to be a Frontside-only podcast and we're going to be introducing a topic that hopefully we're going to be podcasting a lot about in the coming weeks and months just because it's something that's kind of grabbed the interest of the office and seems like it's something that needs to be talked about.

Hello Joe and hello Elrick.

JOE: Hello, Charles.

ELRICK: Hey, what's going on?

CHARLES: Everything, really. Today we're going to be talking about the Internet of Things and we'll be talking a little bit about how we came to be interested in this topic and why we think this topic is important. Let's talk about why this topic is important. I think that this is a very important topic because IoT is only becoming more and more prevalent. It's emerging from the status of being this niche or boutique or very esoteric technology that's only worked on by a very small group of people to becoming very, very open and available and accessible so that anybody can buy a Raspberry Pi or an ODROID or Arduino and slap some Linux on there and connect it over the internet to a bunch of different things and the space of creative possibilities is just exploding.

For me, it's very similar to where we were in the early 80s. You know, I see these IoT devices as being the hobbyist's computers, the Z80, Apple IIe, the Commodore 64 and that the people who are hacking on those things 30 years ago are going to be the people who are now leading the tech space today. I think another big and relevant analogy is web technologies. There was this inflection point where web technologies became very open, accessible, available and the people who were in it ended up being able to ride that wave for 10 years to where we are now.

In both of those examples, we had the hardware and the PC revolution where the computation was distributed across a bunch of these different devices. Then over that time, we saw a migration over to the cloud and these web technologies where everything was centralized. Now, I actually think that there's a pendulum swinging back where we're actually going to see more and more computation distributed amongst physical devices, except this time, it's not going to be manifest as a PC. It's going to be manifest as these networks of devices that are just all around us.

I really do think that we are on one of those watershed moments where these distributed networks of tiny devices are going to be the big next platform that when you invest in it now, this is something that's going to yield dividends for the next 20 years. I think it's an important topic but I don't think we had a well-crafted thought about it but we just kind of stumbled into the space.

I was thinking we could start a little bit by talking about how we got into this and how it captured our imagination. If you rewind the clock to the stone age of 2015, I think it was the end of 2015 and it was Christmas break, that's often a time when people go and they hack on individual projects and Brandon, his project that for whatever reason, he decided to take on was he was really into Hue Bulbs at the time. We had Hue Bulbs around the office and we wired up some demos to control them from a website. He decided he wanted to take those Hue Bulbs and make them so they were accessible from our Slack.

He built a server in Elixir because he also wanted to learn Elixir because if you're having fun in hacking around, it might as well pick up as many new things as you can. He built an API in Elixir that talk directly to the Hue Bulbs and the Slack integration that talk to the Elixir API and we actually are able to control all of our lights purely from Slack. We could turn them all on, we could turn them all off. That was great but then as we began to use it, we were wishing that we had control over our lights from our phones. We wish we had control over them through the website. I think, Elrick, isn't that was your first contact with the Frontside, wasn't it?

ELRICK: Yes. That was my first contact with the Frontside. I was working on the lights app. I initially started working on just the user interface and bringing some different animations and working on the actual experience and the user story on that side about controlling the lights and what particular things you needed to do in trying to craft a UI around that. That's what I initially started.

CHARLES: That was really fun.

ELRICK: Yeah, that was really fun. That just started progressing more and more. As you said as we started to think about how could we access these lights from different places, using different devices and then that's how we stumbled into the Internet of Things.

CHARLES: And it turns out, there's actually a lot of tech in the form of platforms out there that have been developed to help with this, although I would say that the water are still pretty murky as to kind of the best set of patterns to follow.

ELRICK: Yes.

JOE: That's hard to find information, especially with regard to design patterns. Since we've been working on this light thing, there's been so many times I've Googled and looking for prior art and found none or next to none. It's very much the Wild West.

ELRICK: Yeah, because it's like going from a point where you're controlling one piece of data per se, like you have one sensor that does one thing. Now, it's starting to grow until you can have one sensor that can do multiple things and send it across different types of data and then how do you structure that data, how you capture it, how do you hold that state somewhere and it's one to one source of truth. It's just going to be the Wild West of how do you manage this, how do you structure it. It is definitely growing and changing constantly.

CHARLES: I think one thing that is difficult is it feels very much like they're aligned in terms of silos. For example, the Hue has the Hue Bridge, which is capable of talking to the light bulbs and then they also have an API which is under development by which you can connect publicly to servers hosted by Philips to talk to the hues inside your office but if you want to integrate your Hue API like we did with Slack or with your iPhone or maybe some other device that you're trying to control, it becomes a little bit more difficult.

You have all these vendors like Nest, MyQ and there's a whole bunch of lines like doorbells and smart this and that and everything and they're very good at talking. They have an ecosystem, this large vertical ecosystem, assigned with each one but actually getting cross cutting communication is a problem that I think is something that we've had to deal with and it's very, very difficult where we want to start having these devices talking to each other.

ELRICK: Yeah, that area right there is ripe for innovation. I don't know the names off the top of my head but I know that there are people trying to make a smart hub per se. You can think of it like Jarvis from Iron Man. You buy that thing, you put it down in your house, you tell it all the devices you have and that takes care of all the communication between everything. There's definitely an area there that someone can step in and say, "You know what? I figured it out and here's your Jarvis Box."

JOE: We're starting to see stuff like that with Alexa and Google has something similar. That's a little scary to me. I think that the one thing that needs to be made clear is when you're talking about these silos, it's a very good point because we think they're decentralized. We think these things are decentralized but in a way, they're not yet. We don't have peer-to-peer communication necessarily like Hue. They're going to public API but you're going through their ecosystem. You're passing through their lens, so to speak. We think Slack has distributed teams but there's a centralized server where those messages passed through so how do we break from that into full decentralization?

CHARLES: Right, I know that's –

ELRICK: The Jarvis Box. You could probably have a server at your house that keeps all your data there and then it spits out what it needs to spit out to the IoT server somewhere if they're doing some collection. When you leave your house, to say, "I need that information to come back to my cell phone now." Maybe in the future, you'll be able to control that, either from your house or just send out the pieces of data that you need and the centralized stuff, you can just keep at your house.

CHARLES: The whole question of ownership is one that I feel is something that we have not addressed head on. Everybody is just rushing forward with how do I implement this, how do I get it done and it definitely is worth taking a step back and understanding who owns the things that I'm working with and that I'm inviting into my home. I think that smartphones provide a great example of how it can work really well for the consumer.

I think certainly, in their inception I think this is mostly true if you have an iPhone. Most Android devices, you actually own that piece of hardware and the things that you install on it are very much controlled by you. I think that Apple especially, gets a big shout out for making sure and putting in those safeguards so that anyone who's participating in the ecosystem has to first acknowledge that the data is going to be owned by the user. I think that's maybe a little bit less true than it was back in 2009 or whatever but I think that there's definitely a lot of thought that went into that upfront, that I worry isn't going into with Alexa.

Is Amazon protecting? Is there an understanding that if you're participating in that ecosystem that ultimately, the thing is owned by me? I feel the same way about a lot of these AI and robots where it may participate in the conversation but who is it really serving? Is it serving you or is it a proxy to serve somebody else like a Google or an Apple or an Amazon?

JOE: I may just be a pessimist but I think it's safe to say that it's almost always the latter when money is involve.

ELRICK: They had some situations arise where the powers that maybe we're trying to get the actual recordings and different things as Alexa is always on. Let me turn mine off because she's going to say, "Oh, did you ask me for something?" I have one sitting right here in front of me. They have been in situations where people had said, "Because that's constantly recording and that recording is going somewhere," and then if situations have arisen, they said, "We want that recording," and then Amazon is like, "No. We're not going to give you that recording because that is private information."

They're trying to find a way to get around that and what laws and things are going to come out of this area that we're in right now, it's still unforeseen. But I think that companies that are in this space, know that the future of their company rests on them protecting that data and user data because if you don't, then people will sidestep and go elsewhere.

CHARLES: Right. In so far, they hold that as a value. In so far, people are conscious of those concerns. If that's something that people are willing to pay money for, then you've got a market driving force pushing you in that direction. But if people don't care, they don't think and they're just like, "Whatever. It's cool," that's not going to be something that a business is going to roll into their product because ultimately, if people care, then it'll affect their bottom line. If they don't but it won't and they're going to act in their own best interest.

ELRICK: True.

CHARLES: I do worry that there needs to be a social awareness of what kind of powers these devices actually will end up having over our lives and hopefully, those will guide it but you're absolutely right.

ELRICK: True. I view all of this IoT stuff and data is not too far off of what people do on Instagram per se like you have your pictures, you can either post crazy pictures or you can post casual pictures. How you use the power that these IoT devices are giving you is essentially falls into your hands like what am I going to send across this thing. I think that hopefully, the power falls into the user's hands and they empower people with these devices and not make them feel like a prisoner in their own home or car because this IoT things are popping up in vehicles now.

If you step into your car, you start talking and your car is listening. If they go from it like the same way we approach our applications and such and say, we're going to empower the user, I think if these IoT companies take that approach and learn from the mistakes that were made in software by not empowering users, then after a couple years they're like, "Oh, my goodness. We need to empower the user." When Steve Jobs was preaching about this in the 80s and everybody thought he was crazy. Don’t fall into our mistakes. Empower the users and I think that this technology in this space would just keep flourishing if they do that.

CHARLES: Absolutely but it is going to take a generation of engineers to make sure they're always pushing in that direction, a generation of users who don't just wait for companies to hand power to them but demand it.

ELRICK: Demand it, yes.

CHARLES: Yeah, demand it and a generation of business owners who are going to listen and think about the long game and realize that that's the path to long term health and viability.

ELRICK: Yep, even outside of the whole privacy thing where it's like there's too much data being sent out. People are building just cool stuff with IoT that doesn't really send that much data outside of normally that we do. Even on our phone, people use GPS all the time and that is sending data about all your locations, where you are, what restaurant you're at, what bus stop you're at, what bus you're on, what plane you're on and people are building a lot of cool things, just even using that.

I saw the other day that someone had a bicycle, it has GPS and lights and gyroscopes and all kinds of stuff in that bicycle. When you're riding, the lights will go off and say, "It's time for you to take a right." It will blink in a certain sequence or take a left. It register your speed and it all comes back to your phone so it's not too outside of the norm of what we do on a regular day. There's people building things just in that sweet spot per se with these IoT devices that are building some pretty cool stuff.

JOE: It's a very good point because Slack doesn't have to be centralized. It can be peer-to-peer. Hue doesn't have to be centralized outside of having a bridge on your local network. We don't really need to be phoning home for all of this stuff and if we move towards like a true decentralization, we don't need trust at that point. A company has our best interests at heart if we think about it as your trust ideal to remove the need for involving third party in the first place.

CHARLES: Yeah, so what would that look like? I'm going to fast forward a little bit because we were a little bit further along on our journey and we've been experimenting with Amazon IoT services and we've been maintaining our own APIs to control our Hues directly. While they're still going through the bridge, it's not incorporating any other ecosystem but we are still routing all of this stuff through this low level Amazon infrastructure. There's a class of problems that that solves which it does help to have those primitives to be able to access your IoT devices through a firewall, to have them and be able to, at least have a known way to update themselves and distribute software to them.

There’s these fundamental infrastructural problems but at the same time, Amazon doesn't have any access to that data that's moving through their land, so to speak. What they're essentially doing is leasing you a railroad but they don't have new visibility into what's contained inside the cars.

JOE: Do you know that?

CHARLES: I actually don't know that because of course, it's through the Terms of Service.

ELRICK: Who reads EULAs? They're too long.

JOE: I think it's more often than not, people are going to use convenience over privacy.

CHARLES: That's true so it is in keeping with what I understand of other Amazon services, which do have those guarantees. I don't know in particular for the Amazon IoT. But let's talk about that a little bit. Let's talk about a little bit about our setup and why we went to using Amazon IoT services and what it provides for us.

ELRICK: We decided to use the Amazon IoT platform as a means to allow us to one control the bulbs from anywhere, to get access to them and then also to be able to distribute that change to anything we want. Coming through IoT or coming through their platform, when a change happens, you don't necessarily just have to send it to our one set of bulbs. You can send it to anything you want. You can send it to a phone, to another application somewhere, to a database. It gives you the ability and the flexibility to distribute that change or that state change anywhere.

CHARLES: Which is I guess getting at the heart of it is actually managing this distributed state beast of a problem and really, the AWS IoT just helps you get your foot in the door. There are still a lot of cans of worms that are involved once you get there but for the first point that you have said, I want to unpack that a little bit because it's a problem very familiar to us but might not be to the listeners, you've got the set of devices and they come up, they connect to your Wi-Fi and that's fantastic and they can talk to other things on your Wi-Fi, on your local network and can discover services there. But what if you want to control them from outside like I want to send a message from Slack and have it affect the lights in our office. You've got to move through some public cloud to do that because Slack servers are not on our local area network.

What you can do then is have essentially one thing that the IoT services provides is your device comes online and it immediately calls home to a generic location and opens up, what is in practice a web socket. You can program in whatever language you want but that's probably the analogy that's most familiar to everyone. It basically connects a web socket that then you can send messages to it in real time so any time I want to connect to that, I can do it and I don't need Hue's API. I don't need Slack's API. I can just talk to one API which is the low level Amazon -- AWS IoT API -- and I can send real time messages to my devices. That's a huge problem solved right there. But it's hard to maintain that infrastructure yourself. We could write our own AWS IoT but then we'd probably host it on AWS anyway.

JOE: The real world is not a JSON Blob. That becomes a problem. In college, I took a course where we programmed robots for the majority of it and what you quickly find out is that you can't count on revolutions of a wheel or what have you. The world is imperfect. Keeping a state is one thing but keeping state reflected back and keeping state up to date is where the challenge has been for us.

CHARLES: That is right because you've got this highly distributed systems. That's kind of a second class of problems that it attempts to solve for you. You got these highly distributed set of devices but even if the connections are 99.9% reliable, sometimes they're highly latent. You can't control the latency on the connection and sometimes, it fails altogether, which can affect one, how do I even read state from these things. Is the button pressed? Is the button not pressed? Is the light on? Is it off? Is the wheel spinning like you said? Or is it off?

These are things that you need to know and then you need to react to those changes like, "We're spinning at 90 RPM. I want to bump it up to 10. How do I get my system to converge on that desired state based on my current state?" It's hard because you don't know all of the demons of distributed state management are in full like they have ripped off their masks and they're roaming about.

ELRICK: Yep. I saw them introduced something the other day but I haven't had time to dive too deep into it. It was something called Greengrass that it will continue to gather and allow you to utilize your devices locally and it will keep all that data and then it will do the diffing, let's say when you connect back online until what your old state was and what the new state is and then go about updating everything.

JOE: That could be very useful.

ELRICK: Yeah. It just got implemented probably three weeks ago or something like that. It's inside of the IoT platform. I just clicked in and they said, "We have a new feature now called Greengrass," but I haven't got time to dive too deep into it but like you were saying, state management is something that's extremely difficult, especially across a distributed systems. They know it's a problem and it seem to be addressing that problem and trying to make it simpler for people and give you these tools to say, "Here are some stuff that you can leverage," and a lot of that is great.

CHARLES: I think that's an excellent point and I think that it's also worth mentioning too that there's two sets of state that you have to manage. There's the runtime state, which controls the flow of data as your system operates. Then there's the static state of just what is the code that's going to run on this device. Let's say, my robot or my button that's got V1 of the software, that all it does when I push it, it rings a bell. That's V1. I want to add this awesome feature to this button that when I push it, it rings a bell and it also pops open a Topo Chico from the refrigerator or something like that.

The question is how do I get that software from my laptop with that Topo Chico enhancement all the way to my button, which is what essentially amounts to being across the internet inside this private network. In the current state or when you're first starting out hacking, let's say this is based on a Raspberry Pi, I just burn a new Raspberry Pi image with my new software with V2. I walked over and I stick it into the Raspberry Pi and that doesn't really cut it. That does a great job but now, I want to turn this into a business and I want to have 20,000 of these things installed or let's think big like every home in America gets one. Every home in the planet, I want two billion of these type of devices. What happens when I come out with V3?

ELRICK: Then you can either go the route of hiring --

CHARLES: Hiring a favor.

ELRICK: -- Technical folks to go out, to update all your Topo Chico poppers or have your users struggle to do it or what we did, implement Resin. Let Resin update your Topo Chico poppers around the world.

CHARLES: Right. There are a lot of problems in terms of static state management, runtime state management, peer-to-peer communication and problems of resiliency and robustness. I'm hoping that we can discuss these over the coming weeks and months because each one is a topic in of itself.

ELRICK: And offline management too.

CHARLES: And offline management too, there you go. There's another one. There's a lot to explore, a lot that's unknown and there might be people who have answers to all of these and there might be papers on them but they're buried in weird corners of the internet. I'm hoping that we can fill the podcast with a couple of guests to come in and talk about these different things.

ELRICK: Yeah, that would be fantastic.

CHARLES: Yeah, I'm really looking forward to it.

ELRICK: I started playing around with Watson IoT. It is an IoT service that allows you to leverage the natural language processing and computing from Watson. It's pretty awesome.

CHARLES: Wow, that is really cool.

ELRICK: That's another space of IoT that we can explore and hopefully, we can explore over the next few podcasts.

CHARLES: Yeah, awesome you all. Well, I think that's about it for this episode. Thank you, Joe.

JOE: Thank you, Charles.

CHARLES: Thank you, Elrick.

ELRICK: Thank you, Charles. It was fantastic.

CHARLES: And I look forward to hacking on the lights with you guys. That is always one of my favorite things to hack on. I don't get to do it enough but I think we're going to try and have a big throw down on state management on Friday, right?

ELRICK: Oh, yeah.

CHARLES: It is going to be exciting. It's going to be super nerdy and we'll let you all know what the outcome of that is. See you all next week. As always, please don't hesitate to get in touch with us. You can get us on Twitter at @Frontside or send an email to [email protected]. We always love to hear from our listeners. Take care!

Drew Covi: @drewcovi | about.me

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode #76. My name is Charles Lowell. I'm a developer here at The Frontside and your podcast host-in-training. With me is Elrick Ryan, also a developer at The Frontside. Hello.

ELRICK: Hey, what's going on?

CHARLES: Not much. Are you excited about today's topic?

ELRICK: Very excited.

CHARLES: Yeah. You got a personal stake in it because today, we have in the room, not only you but also two developers who are also designers or designers who are also developers. Our guest today is actually the first person who fit this description that I ever worked with. It was a great experience, a great collaboration and his name is Drew Covi. Drew is a senior supervisor of product design at HUE Studios in Golden Valley, Minnesota.

DREW: Howdy. How are you doing?

CHARLES: Good. Thanks for joining us. Now, you're going to have to explain to us two things, one, what is a super senior product designer and let's start off talking about HUE first. What exactly is HUE because I think it's a cool organization?

DREW: I'm working with four people and I'm working on all sorts of brand new ideas. I think the greatest opportunity that I've had in my career at this company, Honeywell is just working with physical product and the digital space. It's a unique opportunity. Not all companies focus on both so it's really been a learning experience for me and working with a great group of creative individuals is also been a real privilege. They say that at the end of the day, the most important thing is other people that you work with and really the entire team here has been fantastic in welcoming me and letting me explore and grow as a developer and as a designer. It's been great so far.

CHARLES: Fantastic. Working with that group was absolutely wonderful. What does HUE stand for?

DREW: HUE is Honeywell User Experience. Our previous CEO, Dave Cote often called it 'huey' but it's just HUE, without the Jersey accent. I'm going to probably misrepresent but we have over eight to 10 studios throughout the world. Each one focuses on different businesses for the most part. The one here in Golden Valley tends to focus on homes and buildings technologies. The studio out of Seattle, actually tends to focus on, again I'm going to get the acronym wrong here but it's essentially worker safety in industrial safety.

CHARLES: What is it that you all do at HUE?

DREW: What we do here at the studio here in Golden Valley is we support various businesses throughout the homes and buildings technology space. About fall of last year, Honeywell went through a bit of a shift in their business and they used to do all automation control solutions. Last fall essentially, we saw that one large business that was headquartered and based out of Golden Valley, break into two areas of more direct focus.

Out of Seattle, we have folks working on, I think I mentioned before but Seattle works on sensing and productivity solutions. We focus on homes and building space so we're both providing upfront research to understand what the customer needs. We're actually creating everything from very rough user flows to final UIs and we're also working with industrial designers to create final products. Those industrial designers work very closely with engineering.

Honeywell has a long reputation of very strong engineering when it comes to the hardware space. We've prided ourselves on excellent instruments and excellent performance. One thing that very few people understand is that we don't just do thermostats. We're in the business of turbos. We're creating the turbos for your car. We're creating all sorts of HVAC equipment. We're also handling various safety equipment. All of these items need designing, not just for end users and consumers but they also need designing for the workers in the field.

If we make a product that is more efficient, easier to use and in some cases, more attractive, not only it does lead to more sales, it leads to more efficient work forces that can work quicker essentially. You could get up on a roof and get off in record time. We're not just designing consumer products. We're actually focused on a lot of other items as well, with oftentimes very large returns on investment.

CHARLES: In the work that you do and HUE does in general, it sounds like there might be a large software component. Digital design is kind of we know in the web space but then also a lot of industrial design of just how does this thing going to look, how is it going to feel, how is it going to persist, how durable is it going to be, how is it going to withstand usage. Would you get involved in that process?

DREW: Usually, the entire organization gets involved with the process very early on. One of the other shifts that happen in the fall as we get involved less in the production and more on the actual marketing side, like marketing deciding what's going to be built. We're actually really at the beginning and understanding what problems need to be solved at first. As far as my practice and my skill set, we do get involved with all that discovery phase work but when it comes to actual deliverables, we oftentimes see our deliverables around the actual creation of understanding user interactions.

We will take research from our user research in OVOC, which is an acronym for Observational Voice of the Customer and we'll take those learnings and translate them into whatever solution we decide to build as a team. My output is going to look like a user flow, something you build in OmniGraffle or Visio and then it can start there, which is in the physical space and then we'll actually revolve those concepts into wireframes as well. Wireframes that will then be handed off to other team members who specialize and focus on visual design. Basically, it's kind of a very hands on process from the very beginning to the very end. It's essentially just understanding everything from the physical to the digital.

CHARLES: When we were working together, at least in your case, it doesn't stop there. You're actually doing a significant amount of the implementation as well. Let’s explore how did you actually end up getting to that position where you were working through interactions, wireframes and workflows and then also, getting to actually build the product in the form of a complex single-page application.

DREW: Sure. Absolutely. One of the components that I kind of brought here to the team was a bit of a deeper understanding of frontend web development. I'm often pulled into conversations here and there. In the case of the project that we were working on specifically, it was essentially kind of early days on that project. We had a product that was pretty old and need a lot of work and it was basically, need to be rebuilt. We hadn't seen a lot of single-page applications at that time. In my case, I actually had worked on a couple small projects in my previous job and we can get into that in a little bit, where my career path took me.

But essentially, it was me trying to kind of pave the way and eventually have that work scale. It was kind of proving that it could be done, showing how it could be done and then getting other developers on board. My role here has oftentimes involved, basically becoming a liaison between our design teams and our development teams. Ultimately in this case like you mentioned, it did wind up in turning into code that ultimately got factored into production code.

It was definitely a time where we were experimenting with what role we would play. I will say in full disclosure that more or less which we're trying to move towards, basically making better informed decisions but not playing as much of a role in actual production code writing. It's something that we want to help scale. I think we'll talk about that kind of role and how well it scales hopefully in a little bit here but ultimately, it kind of changed a little bit. I don't do as much code as I used to.

CHARLES: Right but nevertheless, the skill is there. Don't sell yourself short. You weren't slapping together a bunch of jQuery plugins. You were standing up, basically a full stack system with a StubDeck background, then Node.JS. This is back in early days where there was a custom-build tooling. You were using CoffeeScript. There was a lot of exploration and clearly, there is a fierce curiosity which you are actually exploring and actively kind of skinning and moving into the development space, which doesn't happen until people achieve a certain level of comfort.

Whether or not you're exercising those skills, I think they have served you well in terms of the things that you've been able to build but also acting in that liaison and understanding what's possible and stuff like that. Obviously, once I met you, you were already there. I'm curious in exploring that journey of coming up the design ladder but also coming up the development ladder too. Maybe we can talk about each one separately and then see how they intertwine. Let’s start with the design side. How did you get into that?

DREW: I can take you way, way back. I love to talk more about this in a little bit but I think we, as a generation, are kind of very unique in that. We were raised in the birth of the internet. Some of us are old enough to remember the early dial up days and I certainly was one of those. I grew up basically obsessed with drawing and art and painting. I was a designer and artist raised by an engineer, essentially. My dad didn't really have a lot of opportunities to explore his creative side to basically make a living. I want to say that although graphic design existed to a certain extent, there wasn't really the same blend of engineering skills required so he decided to take the tack of I'm going to become an engineer so I was raised in a household where he was building everything but he was also a talented artist.

As a kid, I basically did a lot of advanced art classes. I'm kind of a nerd, pretty much a huge nerd. I dropped my entire tenure as a high school student. It was also kind of dawn of video games as well so we had computers coming of age. We had video games coming of age so I was raised looking at digital art effectively, 8-bit, super accessible. It's kind of so early on that it was something that I could actually fathom getting into and creating on my own. I never got to creating any games but I will say that by my late high school years, I was using a tool called AOLpress. For anybody who has ever heard of that, congratulations. You're one of the few.

CHARLES: I've never heard of that. AOLpress, we're going to have to link to that in the show notes.

ELRICK: I've never heard of that either.

DREW: It's awesome. It's got a Wikipedia page. It's got hieroglyphs and stuff. They really went all out on this product. It's basically the precursor to the Dreamweaver. It was a very, very WYSIWYG. I'm sure you've heard of Microsoft FrontPage, maybe. It was basically a precursor to FrontPage, I would say. Same thing, those are the days of framesets and all of that. I was a kid in scouting at the time and I wanted to build a web page for the troops so I built one and put it out there. I kind of remember that moment where I was like, "I'm going to write something and put it on the internet and anybody can see it." That whole experience was just super exciting.

I know that if anybody's following Kickstarter, there's one that was started called 'What Comes Next Is the Future.' It was made by Matt Braun and Matt Griffin and it really explored the birth of the web. I would recommend it on your listeners to want to really dive deep if you didn't live through it, check it out. It's a great, great film. All the regulars are there as you'd expect. Zeldman on there, talking about it amongst others.

But if it were for the web, I don't know that I would be who I am or where I am today, just because it's such a unique platform. It's so open. It's so readily available. There's no barriers. I would say that I was just an arts student in high school that picked up AOLpress and then got addicted to the web. From there, it was kind of off to the races. In fact, I didn't even know that I could make a living as a graphic designer until late high school. I decided that I wanted to go to school for graphic design, went a year at the University of Minnesota-Twin Cities and at that point in time, it was pretty much all print design and then Flash. Flash took over in my second year and at that point in time, it was Flash and framesets and tables. There was no CSS for layout. It's very early days. It sounds like you might know what I'm talking about. Have you been there?

ELRICK: Yeah. You know, they say everyone in the world has like a twin and I'm like, "Drew is like my technology twin."

DREW: Yeah. When we were raised in that time and we had to hack it with framesets and whatever tool -- FrontPage or AOLpress -- you basically, from very early days, realized that you had to force this stuff to happen. It was not easy. There was no documentation and where there was documentation, you were grateful to have it. I remember when I was, probably just about to graduate and if I look back at my portfolio piece, it was definitely still Flash. It was Timeline-based Flash. I also think that in many ways the way the web evolved was perfect.

As a designer, I was very comfortable in the Timeline tool. Before ActionScript 3.0 and before they went on object-oriented on us, it was super accessible. You could add little bits of code here and there and create animations. It kind of got you hooked. Then suddenly, I found myself needing to create full screen Flash applications and needing to actually write code. I actually having to say, "If I want this Flash experience to scale, then I need to calculate where things go. I can't just X-Y coordinate and done," so that's where I jumped off and started getting into CSS.

CSS was kind of early days as well. Again, this is before iPhone. This is like people were using CSS but people didn't really think it was that important. It was actually kind of discouraged because everybody in the world was using Internet Explorer and why would you need to know CSS. It was unreliable for different browsers and Internet Explorer was the worst.

I remember sitting in a Dreamweaver conference, when it was Macromedia had a conference and they showed a webpage and then they hit the print button and they said, "Does anybody here know how this happened?" because the layout had changed, everything looked better and different. It was perfect for print. I remember my hand shot up because they was like, "Nobody was really familiar yet with that print style sheets?" Incidentally, I don't think that people still are familiar with print style sheets but it was a time when finally people were starting to understand that style sheets were more than just a layout tool. You could change them for all these different form, factors and all these different platforms. It was a fun time to be coming up in this age.

CHARLES: It sounds like one, CSS and two, Flash were actually kind of gateway drugs into the development world?

DREW: Absolutely.

CHARLES: We still have CSS, clearly but do you feel like Flash, despite what some people might think about it, it was a full virtual machine that was running. You could code on it with ActionScript. It's kind of like the JVM but only for running inside the browser. Do you feel like designers might not have that gateway available to them anymore or maybe is the web just as big of a gateway to move into that?

DREW: Yeah, for sure. I certainly think, beyond a doubt that had it not been for Flash, we would see a lot less creativity in the space. I say that only because at the time, if we had just gone from tables and tried to slowly evolve things, we'd have a much different feel, I believe. Certainly, it's a gateway drug. We'll be in a different web today without it. Is it still required? Are there any equivalents?

I've seen a number of drag and drop web UI on the web tools out there and many of them claim to create production quality code. It's certainly possible to get there without Flash. I think, it's certainly its time has passed but we do see tools like Sketch for instance. These are all very much screen-based design tools that seem to leverage a lot of the same web styles and the web approaches. I think we definitely have the tools there to replace Flash. But I think from my perspective, it would be very interesting to go back and imagine, would we have immersive full screen web experiences without that Flash?

CHARLES: Yeah. I remember it being very much a topic of conversation, certainly at the beginning of each project or when you were going to implement a feature is, "Are we going to do this using Flash? Are we trying to do this with native HTML? Are we going to use EGADS or Java applet?"

ELRICK: Oh, man. Java applets.

CHARLES: That was a conversation that was had before the web eventually went out but I think when it was, everything was very, very static. I do think that Flash definitely set the expectation higher and forced the web to evolve so that it could be the natural choice in those conversations.

ELRICK: The time when Flash was around, I called it the 'golden age of user interface' because you can literally build any user experience, any user interface with Flash that you could dream up. There was no limitations creatively in the world of Flash. Nowadays, we're kind of limited without box model but it's getting better year-by-year.

DREW: It's interesting to me because before Flash really died out, we had these... Let's put it this way. I feel as though, for a long time the web was a very much like a poster site kind of approach. You would have tools that were pretty rough on the eyes, pretty hard to use and then like for certain films, you have these very high budget, fully immersive Flash experiences. For a blip, that did actually translate at some point into Canvas-based and then Three.JS, like 3D WebGL-based experiences in native HTML but I don't see a whole lot of that anymore.

It seems as though, it kind of settled down and in many ways, I would say killing Flash kind of evolved the web from more of a presentational platform to more of a usability first platform. It was a bit of a double-edged sword. You could build anything you want like you said but there wasn't a framework to it. It wasn't really responsive and then certainly, when Steve Jobs decided he wasn't going to Flash an iPhone, that was the end of it. Essentially now, we have --

ELRICK: Steve Job dropped the hammer.

CHARLES: That was the memo that was heard around the world, right?

DREW: Yeah.

CHARLES: I just realized that was like 10 years ago.

DREW: Yeah, they're celebrating the anniversary for the last couple of months here. It's been a huge deal.

CHARLES: There's probably listeners that never heard that memo but it's definitely worth a read. The memo obviously, that you guys are referring to is when Steve Jobs basically said that Flash would not be on iPhone or iPad, not now, not ever. That was the end of it.

DREW: People often forget too that when it was first launched, there was no app store. He basically said point blank, "Anything you need to do on this phone, you should be able to do using the web, using native web coding," and Safari at that point in time is really paving the way to bringing those native APIs into the web. You had geolocation through web. In many ways, that too is a huge gateway drug.

Suddenly, you start looking at the web, not as just like, "I could use this as a poster site or as an informational site or a new site. I can actually use this to get things done." They're actually treating this platform as a first-class citizen. That to me was super exciting. I don't know if it gets as much attention anymore in the days of Swift and the App Store but I will say that if your listeners do get a chance to check out the show I mentioned earlier, 'What Comes Next Is the Future,' they even dive deep into just how limiting the app store experience can be. At least with the web, you can create whatever you want to create and people seemed to go that you URL and install on their home screen. This is a feature that nobody uses from what I've seen but if you bookmark a web app on your home screen, you can have an icon, you can have a loading screen, you can have all this stuff and nobody really uses it for whatever reason.

CHARLES: I think it's the install, it's getting the knowledge about the fact that you can do that. It's not widely disseminated.

ELRICK: Yeah, I think its capabilities starting to come up now with people making progressive web apps. They're starting to utilize that being able to put icons on people screens and loading screen and splash and etcetera.

CHARLES: Flash really was kind of the gateway into the development world. I'm curious what opportunities do you feel opened up as you started taking on more web technologies, more JavaScript, more CSS and mixing that with the design that you were doing? What unique skills/superpowers do you think that gave you, that made you, that helped you at that stage in your career?

DREW: Yeah, for better or worse, it really was the opportunity to get a job first of all. I know that the job market has been in all sorts of flux in the last couple of decades but I would say 12 years ago, in 2005 when I was entering the workforce, graphic design was not necessarily a hot field. I can say with relative certainty that the majority of the people I graduate with, didn't necessarily make their way into graphic design as a profession. I would say probably maybe 30% to 40% actually wound up following their degrees.

For the obvious reason at that time, we were starting to see digital replace print. It meant that I was able to get a job for one. It wasn't a dream job necessarily but I was basically a one-stop-shop. I was designing and developing websites as working for a company but in many ways, shapes and forms, I was kind of freelancing as things were. I had a very direct relationship with the clients that I worked with. It was basically churning out websites.

If I recall correctly at the time the company wanted to essentially create a Domino's Pizza of the web where we could use CSS to essentially build the actual HTML once and then restyle it. This is actually was a time when a site called CSS Beauty was just coming of age, I think the site still exists but back then, if you want the CSS Beauty, it's big thing was you have one website and people could upload their own CSS and completely change the layout, completely change the look.

CHARLES: Are you talking about CSS Zen Garden?

DREW: Maybe that was it. There's two of them.

CHARLES: I remember that one.

DREW: CSS Zen Garden was one of them and I think CSS beauty was a clone maybe of Zen Garden for sure. Maybe you're right, Zen Garden was the one where you actually had a website and Beauty was just showcasing certain CSS sites. I think you're right. Zen Garden was the one. When they saw that, they're like, "Wow, business opportunity. We can build a whole site." We were using something called 'Cold Fusion' and... Oh, it will escape me now. I think it was called 'Contribute.'

There's a product called 'Contribute' that Macromedia come up with that worked on Cold Fusion. It was basically a WordPress. You basically set up editable regions, you basically code the site once in that regard in the backend coding and then just rework CSS to create multiple sites. Actually, the opportunity to open up for me, that job was very squarely-focused around the benefits of leveraging CSS. Eventually, that grew tiring.

I kind of wanted to get into the actual marketing and advertising space. From there, I started to just jump to the next job. I worked for a very, very small marketing agency. It was called 'Vetta-Zelo' at that time and we focused on lots more Flash, a little bit of CSS websites but mostly Flash Experiences and they actually used Flash in a lot of kiosks and physical spaces.

I started to jump into that, understanding PHP, understanding databases because we would do things like we would install Flash Experience on little portable tablets that would then sync up survey responses to a web URL that it would then dump it into a database. About that time, I was always trying to teach myself how to get really deep into the backend of the stack.

CHARLES: That was just to make sure that these Flash sites that you're developing would be scalable and more robust? Was that the natural next layer to dig down?

DREW: Absolutely. At the end of the day, we wanted to have immersive Flash experiences and we wanted to have the content easy to update. I would build these really crude backend with text areas and they would update a database and then the Flash Experience would pull that in as content. In that way, we didn't have to go in and re-publish the Flash every time, essentially. It was a much more streamlined process.

I think we even gave some of our clients the keys, gave them a login and password and they could change certain things. There's an outfit around here called 'Crave.' They are a restaurant in town and we built the website for them -- one of the earlier websites. When you have to do things like update times and menus and things like that, it became pretty essential to having some sort of a CMS behind it. It was all based on necessity, in other words. What you said is absolutely true. We had to evolve what we learned and I had to push what I did to lever on different needs.

Throughout my career, I've been the guy who does web and design. One of the things about that is it's kind of a lonely place to be and find yourself in creative agencies, where the majority of skill sets are not in development and trying to explain what's going on or make commitments on timelines and deliver on them. Whenever a bug shows up, it's never really fully understood. It's also a challenge to manage expectations, certainly as a young professional at that point.

CHARLES: Yeah, I would say, what would be some advice you would give to somebody who is straddling these roles at that early career stage where they're maybe working for creative agency and fulfilling these two roles but most of their surroundings is towards the design end.

DREW: Yeah, I would say for the most part, just be upfront. If there's anything that's unknown, be upfront about it and explain. If you are early in your development career as a designer, do your homework before you committing any commitment certainly. I think it's always better to be upfront about these things than to try to over-promise and then scramble at the end. I will say that a lot of my career has been marked with the term code 'code cowboy' as a designer and teaching myself to code. It was a disparaging term, I guess. I didn't really necessarily take it that way but I think other developers are trying to use it in that way.

CHARLES: [Singing to the tune of Mammas Don't Let Your Babies Grow Up to Be Cowboys] Cowboys ain't easy to love and they're harder to hold...

ELRICK: It's so true.

DREW: You know, I'm not even embarrassed to say it because the truth of the matter is when you're a designer, you're used to just making a mess before you kind of landed on what you're done and what's right. The entire creative process is messy. I think it's inherent. If you're one of these designers turned devs and you basically just hack it until it comes together, that's kind of a natural flow from the creative process. Certainly, as you get more experienced, you want to reduce all that uncertainty and potential for error so you do learn to hone your craft, to use version control, to embrace a framework or embrace some model-view controller approach but none of that really existed in the early days of the web. I kind of came up in a time when you had to hack it.

CHARLES: Well, there's a lot of learning that can happen when you're hacking and building things that are kind of ad hoc. As you go, you get to perceive firsthand the problems with them. Without perceiving those problems first, it's hard to really understand the solutions that the internet has come up with to deal with those complexities.

DREW: I would say I was like a solo designer developer throughout the early years, because at 2010, I found my people in a local agency called 'Clockwork' and for the first time, I wasn't the only developer on staff. There was a whole team of developers. In fact, the shop was started as a development shop and they were making headway into the creative space and eventually, becoming full digital partners. But had it not been for my opportunities at Clockwork, I wouldn't have picked up my skill set as a backend coder. From the very beginning at Clockwork, they expected you to get your hands dirty and code and get your hands dirty in the terminal, honestly. Command line was required even in our design work.

CHARLES: And this is all designers needed to be familiar with the terminal tools --?

DREW: Correct.

CHARLES: -- Basic coding?

DREW: Yeah. Essentially, all of our work, whether it was creative or whether it was documents, were all managed in Subversion. As a part of onboarding, you basically learned how to use Subversion. There were some GUI tools for it but for the most part, it wasn't that steep of a learning curve. It was pretty easy to follow instructions and that was the second gateway drug, I would say.

My first gateway drug, again was kind of coming up in the age of the web and getting into CSS and Flash. The second gateway drug was basically being required to learn command line and learning how to navigate a computer without a display. Had not been for that, I don't think my career would have taken the turns that it did. I basically got more into the IoT space. I had set up a home NAS server with Drobo FS, is what it was called at the time and it was just a really basic machine but by jumping into that, I could start to play around with UNIX and tools there. I started using home automation, playing with that and at some point in time, I made the jump from just web into the role that I play here at Honeywell, which is Internet of Things.

We do a lot of Internet of Things. In fact, our latest tagline is 'the Power of Connected' so we've embraced it all the way down to our wood mark. It’s becoming the new normal for most products so it's a good time to be at the center of all these different areas of expertise, to be in development, to be in IoT and to be in design. That’s my path. That’s my journey. I would kind of pick it up at a bunch of fortunate circumstances, honestly.

ELRICK: Having these two skill sets: your design skills and your development skills, what do you believe that that gives you in terms of an advantage? Having these two skills set and being able to leverage these two?

DREW: From my perspective, having both skill sets allows me to understand. I think the biggest challenge when working with large teams, particularly in this space or in any space is to really have a common level of understanding, stepping aside from a functional role and becoming more of a liaison between design development and to be honest with you, as we look beyond that, I took a three or four or five month course in business administration, actually. It was just a night class but I wanted to be able to speak to those needs as well. I think it really is becoming a translator.

Serving as a translator between those items and then also being able to understand where the actual boundaries lie, there are a lot of very talented engineers and talented designers and sometimes opportunities are missed because, either timelines are pushing engineers to cut certain functionalities or certain features and there's a lot of pressure. Where we can lend a hand, where we can point to possible alternatives, I think that's where we really build cutting edge products. When we really know each domain, we can push those boundaries. That’s where I'd enjoy bringing my skill set to the table.

CHARLES: Yeah. I can second that. Having actually worked with you, I think one of the greatest things was the one just with the interactions that you were coming up with, were just really spot on. It wasn't ad hoc. It wasn't some --

ELRICK: Helter-skelter?

CHARLES: Yeah, it wasn't helter-skelter. It wasn't some developer coming up with like, "Hey, this is what this looks like," Or, "This is some designer putting up pie in the sky stuff." It was, "I understand what's possible and I'm going to use that to design the best thing that can be possible." It made the designs very pleasant and some of them were just really fun, I think. Thinking especially like that, the hierarchical tree selector was one --

ELRICK: Yeah, that was fun.

CHARLES: -- Which the implementation of that was just a joy. But then the second thing is being able to speak with you on the development challenges and really know that you understood that language. It really is being bilingual, I guess in the sense that I'm talking to you in French and you're talking to product owners in German or whatever. But because you're bilingual, the flow of information is as frictionless as possible.

DREW: I will say that it was a real pleasure from our end working with your team as well because one of the trends in many businesses throughout the world today is embracing a lean and agile approach to product design development. One of the growth opportunities, I would say in any business is fully understanding how that process works, having the courage to be upfront about what can be accomplished in the time available.

I think one of the other things is fully understanding those three pegs of the stool. There’s always the budget, the time and then the features of any projects. I think that working with a team that understands that really changes the dynamic. I will say that it was equally a pleasure for us to work with your team because there was just a level of courage in being very forthright and very upfront about what do we need to get the job done? What has to happen? You made my job as a translator, essentially.

CHARLES: We aim to please.

ELRICK: Absolutely.

DREW: Absolutely. The latest evolution of kind of where my career has taken us in the company is embracing the hardware element. We’ve talked a bit about the web and then how that evolved and then having to get comfortable of the command line and where that took place. I've always wanted to build. I've loved designing but I always want to build it and I want to put it out there. In the last six months actually, I finally decided that I would pull the Band-Aid off and jump into soldering hardware, writing what code I could and building actual physical hardware prototypes.

I think the next step for anybody who likes to follow this maker trajectory, for a creative looking to become a maker or a developer looking to get into creative is just not stopping. There's always something there and we're also fortunate to live in a time when I can go on at Adafruit, pick up a kit of parts for under $100 and build something that's completely new. Then by the way, they have a full-on tutorial that takes you through every step of the process and gives you bits of code to get started so what's your excuse at that point?

If you've got $100, then you can throw and toss into a hobby, pick up a soldering iron and go to town because there are videos, there's the documentation. Documentation is just everywhere now, where it was never there before. I think the next step for us is seeing how can we very early on show real physical world products to end users and get feedback. How we're taking design now is beyond the digital and into the physical.

CHARLES: That's fascinating. I feel like there's this pendulum that swings through the tech industry of things moving from hardware to software and back again. We’re in the middle of the swing towards the outside or towards the hardware again, like the distributed hardware versus the dumb terminals. It’s distributed across a bunch of devices rather than concentrated on one super-powered desktop computer. The pendulum is going to swing in it but it's just always fascinated to see what the actual arc that it takes is going to be.

This has been a fascinating conversation and the reason I wanted to have it and we were actually talking about this before the show started officially, why this topic of 'devsigner?' I think that it's a role that is emerging. I think it's still in the early days. I think that I went from three years ago having never really met this type of person to having met and worked with you. Now, I would say having met and worked with three people here at Frontside who fulfill that role and now knowing a couple professed devsigner or people who operate clearly in the design and the developer space on Twitter. I feel like it's this emerging career track that might not be fully understood or defined right now but clearly, there's something there so we wanted to explore that.

I'm curious if we might be able to open up the discussion a little bit on what is the future of this role? What tasks will it be set to accomplish? When you're assembling your team, you say, "Get me one of those because we're going to need that." How is that going to be further refined and designed so that it scales as, perhaps an official career in one, two, five, 10 or 20 years?

DREW: I can only speak to my experience in this area and I can say that for the most part, it is a very unique skill set and sometimes, it's hard to come but like you said, you're working now with three people. I think it's growing in prevalence. I believe that where coding was less common in the past, it's becoming so much more common now that it's almost like an expectation just like typing. It is an expectation now. People expect you know how to type. It’s not a surprise that we're going to see more and more of these individuals.

I would say that any design team out there could almost invariably benefit from having somebody with this skill set, somebody who can translate design concept into a working prototype. I've seen it manifest as a prototyping role, more or less just so that we can have a tangible deliverable for developers. I think it does depend on the team, certainly. If you have small teams with talented frontend developers, then certainly you can work in a lean and agile environment and make very quick iterative change.

If you have very large design teams and very large development teams, I would say that having a frontend developer with the skill set in a creative team allows that communication to happen without routine phone calls and lots of meetings, essentially. It’s a crystal clear example. I've see it manifest as a prototyping role because the expectation is this code will end up in production but some of the code may. The layout code may end up in production but the functional bits may not.

That’s not to say that the functionality isn't a part of the experience and that, designers don't care about how well an experience performs. But typically where many designers see the disconnect is in the presentation layer. Having somebody who can carry that over is usually something that is far smaller team can handle. Does that align with your experiences?

CHARLES: Yeah, that makes a lot of sense and I would say that the compliment from having this person on your development team, if you're in mainline development mode or maybe you are a small team, even if it's a production system but you don't have full time design resources, this person can slice and dice the features and understand the hierarchy of interactions and being able to put together some wireframe, some very concrete goals and set those goals for the rest of the development team. But yet also understand what goals are achievable in the iteration. I think it works from the flipside as well.

Maybe what we're seeing is the agile of the [inaudible] of everything. What we've seen over the past 15 years or 20 years, what has been the arc of my career is just seeing these feedback loops in every element of product development getting smaller and smaller and smaller. On the development side, we recognize this as being able to feedback loops and verification. Having your tests, you don't actually have to deploy your system to be able to get feedback about whether it works or have it be fully assembled to get feedback about whether it works.

But then that manifests in terms of continuous integration and deployment. You’re bringing down the feedback loop of getting this out in front of people versus these long deployment cycles that maybe you really have a release every year. It was hard to believe but that was the norm when I started. It was yearly, maybe even once every 18 months. It was not uncommon at all to have released cycles like that. Certainly, three months was very, very short but then those tight feedback loops can also manifest itself, internally in terms of team communication and I think having people who can make those feedback loops between the product and between the implementation, every time you shorten that feedback loop, you're unlocking an exponential amount of time.

DREW: Yeah, I think you kind of hit the nail on the head when you talk about setting scope and understanding things as well. Strictly speaking from agile terminology, having a product or a role that can bridge those gaps is critical. I think that the best product owners that I've worked with have understood, have had an appreciation for design but also have had some degree of a development backend as well so they know how to make those critical decisions. In any sort of iterative or agile environment, you have to dice up these features and figure out which ones are going to ship when they're going to ship. I think, yeah you hit it right out of the park with that. Whether or not you can ever have a full-on team of just prototypers, I'm not as convinced that that's necessarily scalable. It seems like there's certainly a role for teams of developer that will break down features and then there's teams of creative as well.

CHARLES: I think in terms of the person who would lead that team, this role definitely seems very well fit.

DREW: Exactly.

CHARLES: I think it's a great opportunity for someone who's looking for a leadership position in terms of developing and seeing products to market, which is kind of similar to what you're finding yourself in today or where you're headed towards, it sounds like.

DREW: Yeah, for the most part. It seems like I do find myself in a number of calls in kind of bridging those gaps. It’s certainly a different dynamic in the agile environment when work with hardware. That’s something that I think we're still exploring and still understanding. Certainly, there are companies that do agile with hardware but there's a whole slew of different challenges. You’re not just deploying anymore. You’re actually building manufacturing understanding what needs to ship with what. I think the next evolution of our company's growth into this space is how do iteratively produce hardware.

ELRICK: Interesting.

CHARLES: You got to keep me posted. The next time we have you on the podcast, you're going to have it all figured out, you're going to be presenting your thesis, it's a conference talk upcoming, agile hardware.

ELRICK: Yeah, that would be pretty interesting.

DREW: Yeah, I'll let you know.

CHARLES: In the first iteration, you just throw a bunch of boiling solder on the breadboard and see what works. "Okay, now, that didn't work."

DREW: I'll be honest with you. The 3D printing is making lots of possibilities open up in that space but ultimately, you got to ship. We use 3D printing and now we are using these low-cost computers to really prototype real world experiences and near-to-final industrial design. We can do that.

CHARLES: Drew, this sounds like you have the coolest job.

ELRICK: I know, it sounds awesome.

DREW: It become even more exciting than I had initially intended. It’s fun times. I think, again we're living in a time when we can 3D print stuff and have it done within a couple of hours. What better time to embrace these technologies and this creative spirit. It’s kind of all around us. Honestly, it's just being fortunate.

CHARLES: Yeah. Fantastic. This has been a great conversation. Thank you so much, Drew for coming on.

DREW: My pleasure. Thanks for having me, guys.

CHARLES: It's an amazing place. It sounds like even more fun since we got to work with you. If anybody is out there and they're in the design space and they think that, "Oh, maybe I can't do development," or it's too hard. It’s not. There’s a lot of people out there who are doing it and experiencing lots of good benefits. I would say that the other thing is if you're a developer, you should think about looking into the design space, something that you might be interested in. I think it's probably less common that the vectors people move from development into design and not vice versa but there's nothing that says that it can't go that way. Mostly, it's because people just aren't doing and they think that that option is not available to them but clearly, it is and clearly, it's a valuable role. I think this role is going to only get more valuable in the future.

DREW: I would second that thought and that notion. I give a quick shout out to Erin O'Neal. She's a former colleague of mine who's given a number of talks about that very topic -- backend developers caring about user experience, caring about the design. She’s given some talks. You could probably find her on YouTube. Anybody who wants to talk about it, I'm all over the web as DrewCovi. I think I pretty much have that user name in every platform so if you Google me, you'll find me.

CHARLES: We'll look for you. Obviously, you can find us at @TheFrontside on Twitter, TheFrontside on GitHub and feel free to drop us a line at [email protected]. Thank you for listening everybody and we'll see you next week.