Building an autonomous drone

Podcast Transcript

Neal Ford:

Hello everyone and welcome to the Thoughtworks podcast, a regular podcast featuring all things technology at Thoughtworks. I'm one of your regular hosts, Neal Ford.

Zhamak Dehghani:

And I'm Zhamak Dehghani joining you from, San Francisco office for this episode.

Neal Ford:

And we have our guests today from Germany, so I'll let them introduce themselves.

Emily Gorzenski:

Yeah, sure. I'll go. I'm Emily Gorzenski, I'm a data scientist based out of Berlin, Germany.

Jeremy Abbott:

And I'm Jeremy Abbott, I'm the head of product innovation. I'm also based out of Hamburg, Germany, no, Berlin, now.

Neal Ford:

So as I said, the purpose of this podcast is interesting technology stuff. So tell us what kind of interesting technology stuff you want to enlighten us with today.

Jeremy Abbott:

Yeah, today we're going to talk about the project we have. It's called a tech lab and we worked with drones and trying to make them autonomous.

Zhamak Dehghani:

I'm excited to hear about the collaboration of a data scientist and head of product innovation in the context of the tech lab. It's a good combination to have.

Neal Ford:

Intelligent, autonomous drones. What could possibly go wrong?

Jeremy Abbott:

Oh yeah. I mean, the interesting thing is we come also from ... Emily and I are two different perspectives. You might hear that we're both American, but as far as drone experience goes, I'm definitely more of the consumer. I've had like three or four drones. I've only lost two of them, which isn't too bad. I've also built a few, but Emily's, I would say she's definitely more the hardcore a drone expert. Maybe she could say a little something about that?

Emily Gorzenski:

Yeah. Well, what's interesting about that is I came to data science by way of being an aeronautical engineer. So I was actually a control systems engineer in aeronautics and aerospace applications for about 10 years. I studied there aeronautical engineering in my undergrad and I've worked on a lot of these projects. In fact, almost 20 years ago now, I did a undergraduate research project; working on a very similar type of problem back before quad copters were consumer grade devices. And so when we came into the tech lab, what was really interesting is Jeremy had a lot of experience in this consumer space, flying drones and had a lot of really awesome product ideas for what to do with it. And I am sort of a little bit battle-hardened having, not only crashed drones but nearly blown up wind tunnels as well. And so I kind of like hit the brakes on a little bit of the innovation that we initially came to this project with.

Neal Ford:

So it sounds like a real badge of honor in this world is, how many drones you've destroyed?

Jeremy Abbott:

Well, I mean think the big thing is really, it's about less about failure and this idea of risk. But I think when you try things out, you're prone to destroy things or make mistakes and instead of calling them failures, because over here in Germany that's kind of a, not a very nice word for most people. So, I like to frame them as learnings. So I think the more learnings you have, the more you learn actually. And the further we develop. And I think maybe, obviously nobody likes to fail, but we do like to learn.

Jeremy Abbott:

So I think in this regard, and in this context of drones, I think it's important to try things out. And then like Emily said, I've never blown up a wind tunnel or come close, but I have put a few drones in the water or in trees. So I think that just, it's like learning to ride a bike. You have to try things out and eventually you're going to, something's going to go wrong.

Zhamak Dehghani:

Jeremy, you mentioned and Emily yourself, you mentioned that tech lab, a few times, that environment that allows you to test and fail and so on. Can you talk to us a little bit about tech lab and what brought you two together there?

Emily Gorzenski:

Yeah, sure. So the tech lab that we run in Germany is, we try to run it once a year with a team of about four to five people. And it's a six week program or four to six week program. And what we want to do with the tech lab is get familiar with emerging technology. So we see lots of things in blogs and in, on Twitter posts or in the news about people doing cool things with technology and oftentimes these are things that are a little bit outside of our day to day with our larger enterprise scale clients. So the tech lab is a chance to take our software excellence and our product excellence and get hands on experience in these emerging technologies to see, what is the hype really about? What can we do with this? How can we bring this to a point of delivering value to our customers? And what do we do when one of our clients comes to us and says, you know what I think we need to do is I think we need drones flying around our warehouse.

Zhamak Dehghani:

Fantastic. Was the six week trust selected as a good number, what was the basis on allocating six-weeks to this?

Jeremy Abbott:

I think in this regard, historically it's been like six to eight weeks and it's really a question of budget as well. Because as you can imagine having four the five people working on this pretty much full time. It does cost. It's an investment. So I think six to eight weeks was a number they hit upon where they said this is something we can invest in without breaking the bank so to speak.

Zhamak Dehghani:

Fantastic. I think it might be an interesting topic for some of our listeners. Well we'll jump into drone and the technology in a minute, but in of organizations trying to have some form of an innovation center or days that are allocated to developers to try things, creating, a construct that allows developers come together and play with new imaging technology. As you mentioned, it's an area of focus for a lot of our clients as well. I'm curious to know whether there are any success criterias that you would set up as part of, particular tech lab? What make it, in this particular, let's say in this particular case, what were your success criterias to measure at the end of that six weeks?

Neal Ford:

Beyond the certain number of minimal drones destroyed.

Emily Gorzenski:

Well I think among the criteria that we had was, with anything in involved in the hardware space, particularly anything with drones, safety being number one. So we wanted to get out of the project with all of our limbs and eyeballs intact. But beyond that, one of the challenges that we have with emerging technology is that it is often times very difficult to know what an appropriate criteria for success is. And so, we went into this without, there is no guarantee of success. And because this is a new domain, you can't throw code at the problem to solve existing problems like you might be able to code around stubborn database or something like that. So what we were really looking to do is gain knowledge out of this and specifically in the area of how do we test with hardware? What are, what is computing look like in a domain where we are highly resource constrained and what can we learn from that? And also can we have fun while doing this?

Zhamak Dehghani:

Sounds great. All right. So let's dive into this. The drone experiment that you had. What would be some of the highlights perhaps?

Neal Ford:

Can I touch on the last thing you said for just a second? So in many ways, this is kind of like a spike on an agile project except with hardware. So it's been a long time since people who only wrote code had to worry about destroying hardware from the code they wrote. But you're back in that spot where you have to be careful about the code you write. So spikes here have a both a figurative and maybe a literal meaning. And so there's a certain level of risk that you take when you're dealing with hardware, particularly hardware that's flying around that I think is unusual to a lot of developers where, the worst risk is a compiler error or a red bar on a unit test. Slightly different when you see your experiment plunging to the earth.

Emily Gorzenski:

Yeah. And actually I want to, I want to touch back on that in a little bit, maybe a little bit later on. Because I think there's actually some really important learnings that we've carried forward on this that we're actually applying to some of our clients.

Jeremy Abbott:

Yeah, definitely. Over here in Germany we have a lot of industrial clients. So this whole concept of industry 4.0 and this idea of software and being embedded in hardware. So, IoT for, that's what they're calling it now. And so I think this tech lab specifically, it was interesting because it's stuff we can actually apply to some of our clients.

Jeremy Abbott:

Maybe not right away, but some of the challenges like Emily's probably going to talk about later on are definitely going to come up with this whole context of building for software and hardware. It's not as easy as just deploying. There's a bunch of different steps and I know I can reflect back upon sitting together there and yeah, we're going to spike this or we're going to try to respect that. So to me it felt like a lot of spikes. But I think that's what you have to do when you're working with the unknown.

Zhamak Dehghani:

Jeremy, you were playing the, were you playing the role of the product owner in this case?

Jeremy Abbott:

I don't, I wouldn't say that because it depends on what you consider a product owner. I think, I think my experience also was not just throwing ideas out there and having Emily and the team bring them back to earth, which I call first principles. I also had experience doing hardware stuff before. So I was actually soldering things, actually the first time we like paired and soldering stuff and working with different sensors and stuff. So this is also previously before my time at Thoughtworks, I was at Google and I did hardware experience myself and that's why they hired me originally. I wouldn't say I was a PO by any means. I think, I don't even know in this context if we needed a PO. It was more like let's define what our common vision is and then build towards that.

Zhamak Dehghani:

Perfect. What are some of the disciplines that you brought in to the project as a team?

Jeremy Abbott:

Yeah, as a team I think, I mean it was such a, I mean when Emily joined, because before it was like two devs and QA and myself. And then Emily joined because originally I didn't know she was going to join. And I thought for me it was like wow this is this just luck or what's happening? Somehow the stars are aligned because she has that background. She mentioned in the beginning. And that kind of brought everything, all together. And I think one thing about the team, it was so diverse that it, like I said, we had myself, which was more the product I guess the design, Emily data scientists and we had two developers and a QA. So for me this is the perfect product innovation team for the most part. The only thing that was probably missing was a BA role. But I think that being said, I think, you couldn't have a better team to do something like this. It's definitely the most fun I've had at Thoughtworks.

Zhamak Dehghani:

Yes. Magic always happens at the intersection of many disciplines coming together. You mentioned the BA role. What would a BA role do in this scenario, on this project?

Jeremy Abbott:

I think in this term, if I think about product innovation, it's those three circles overlapping this Venn diagram. So you have the feasibility, which is typically, the tech side. You have the desirability which is design. The viability being the BA. And since obviously our client or the stakeholders or the client I guess slash stakeholders was a Thoughtworks in this case, so maybe they would have been the BA role would have been more handholding and massaging and updating on that level. When we had our, when the developers and Emily and myself to some degree had our heads down building stuff.

Zhamak Dehghani:

The communication of what's being done and interpretation of what's being done and communicating to the stakeholders in this case...

Jeremy Abbott:

Yep. In this case, Thoughtworks and the organization at large, definitely.

Neal Ford:

Well, I think, I suspect too that a BA would be really good at figuring out business applicability for whatever spikes you're doing. Figuring out ways to apply that to interesting business scenarios.

Jeremy Abbott:

100%. Yeah. And that, maybe even that would have been like for the long term, after the project ended, the BA could definitely helped formulate. Okay, what are, what would be nice for the next steps when everybody's off the team? Where do we see this going? But I think, like I said, I think the roles were so overlapped. I don't know if you heard that term T-shaped? So you had some people that are very computer science or data science and then you had some people like myself. That was a very, I guess my T shape is more designed, but I can code, but not nearly on the level of a Thoughtworker. But I also did hardware so I think, got it. That's why the teams, I think this whole idea of diversity is not just about gender or background. It's also about skills and discipline. And just, I'd love to have the knowledge that Emily has and the experience. And maybe in another lifetime that'll happen. But, working together, I think that would be that's the next best thing. Actually working on something that's tangible, that we're all pretty excited about.

Neal Ford:

I've often found on Thoughtworks projects that the secondary or tertiary interest people have beyond their primary interest are the interesting things that give you insights in projects. I think that's true anytime you get a bunch of creative people together. But it seems like you really hit a nice sweet spot on this project.

Jeremy Abbott:

Yeah, definitely. Yeah. I mean it was, for me it was amazing. And even towards the tail end, we had another data scientist, Emma, she helped out a lot. And then in the beginning during the process. We have this, one of our colleagues Phillip. He's really, I guess his hobby is like hardware. So he has a 3D printer; that actually works because I have a 3D printer, but it's like an old, old timer, old cars that sit in the garage. You have to kind of really a massage it to make it work. But he was, it was super helpful to have it just do this in the office. And then have all these people kind of see what we're doing. Also, maybe we annoyed him to some degree. Because, if you haven't heard a drone before, it's not a sound you want to hear all the time in the office. Right. So this interest was there and I think everybody was pretty keen to see what we're doing and see what would come about.

Zhamak Dehghani:

Fantastic. You, you mentioned that you had the most fun during your time implementing this drone. I'm curious, what are some of the interesting aspects of building a drone in six weeks? Technical aspects, design aspects that you could share both with our listeners?

Emily Gorzenski:

I think from my perspective, one of the, so there's two interesting challenges here, from a technical perspective. One of the challenges is, what does it look like to do computing in a resource constrained environment? Because often times we're looking at scale, scale, scale, scale. We're` throwing bigger databases, bigger clusters, that problems. And then also trying to optimize on those clusters to keep costs down, et cetera. This is the opposite problem. We're trying to squeeze more performance out of very small computers. And pushing them to their absolute limits and we don't have the opportunity to scale. So what are the trade offs? So the sliders become a lot different in working in a problem like this.

Emily Gorzenski:

The second thing that I think is interesting, in a project like this is, how do we do testing? Because what happens is anything that has hardware in it, our typical CI, CD type of environments, we can still make them work to some degree. But at some level your acceptance testing involves actual flight testing. And you can't, you have to schedule that time and that time is limited. As Jeremy just said, there's, a drone is noisy and it's annoying. And so we had a very limited amount of time. We set aside one hour every day in the workshop in Hamburg, where we could actually fly this drone and test our algorithms and test our code.

Emily Gorzenski:

And then after that hour we had to do all of the analysis and everything else offline. And this mirrors what we see in some of our automotive clients and some of our industrial clients where testing, it can take months to get to that point. And then you have to run everything in a very short amount of time, gather all the data and you don't have the luxury of feedback cycles. So what does that mean in terms of quality? How do we approach that differently as software engineers? And so to me that is I think one of the things that we really need to learn from and that it almost throws back to the old days of software engineering. Where testing was a lot more difficult. Computer time was much more expensive. How do you actually run those things and ensure quality?

Neal Ford:

Well, building for super resource-intensive environments. In my very early days in the computing world, that was a big deal. And it went the other way for a while, but now you're back in an environment. And the IoT space is one of those environments where suddenly memory and mundane concerns like that become first-class citizens again. And it's a very different style of coding than when you have infinite resources.

Jeremy Abbott:

100% and it reminds me, you've probably heard that quote from Marc Andreessen that software is eating the world, but the fact that the world is not digital in the world is hard. You know? It's not only bits, it's bytes and it's fiscal things. So I think this idea of, software is going to eat the world, but I think the world is pretty resistant to making it happen, just by nature. You know? Like Emily said, it's not as easy. We're not just going to set up some AWS cloud server or whatever it might be and just, be flying drones around. You have to inherently think a little bit differently. I think it also, as Neal said, it makes you more conscious of your code and what you're actually putting onto the device because it is limited. But also that means, I think there's this kind of concept of the more constraints you have, the more creative you have to be. And I think that creativity comes out under the constraints and especially in this context in this hardware or software context.

Neal Ford:

So, that reminds me, I don't know if you ever heard the story of a bitblt — bit BLT. But it was an incredibly clever algorithm that was developed way back in the day as a way of drawing things on a screen in highly, highly resource constrained environments. It's considered one of the great graphics breakthroughs for really, really seriously constrained a video screen. So it reminds me of that, exactly what you're saying. A lot of times severe constraint like that leads you to interesting creativity.

Neal Ford:

There's a famous story too of a, this is actually one of those stories that Steve Jobs was constantly pestering the original Mac developers to create rounded corners. And they just didn't have enough resources to draw rounded corners until one developer came up with a really clever way to do it. And he ended up removing a whole bunch of code and got punished by a project manager who was looking at number of lines of code added during the week. And he actually solved this hard problem and removed code and it made them realize that, Oh, maybe, removing code can sometimes be a better thing and adding code to a project.

Neal Ford:

And it was also this clever thing to work in these ridiculously similar, the original Mac had 128 K of memory, which probably sounds pretty familiar to you guys.

Zhamak Dehghani:

I'd like to talk a little bit about the tech stack that you chose, given the limitations of the memory or the processing power that you had. And what worked well and maybe what didn't quite well or was what's challenging?

Emily Gorzenski:

Yeah, sure. So to describe the tech stack, I think it's important to frame the problem a little bit. And so we wanted to start with flying a drone autonomously indoors. And we had seen some other projects where a drone would fly around a car and take photographs of a car. And we were like, well they can do that, clearly we can do it indoors. Right? And the problem is no you can't. Because, it's very easy to fly a drone in a circle outdoors with GPS. It's very difficult to do it indoors when you don't have GPS signals. And so my first challenge to the team was, how would we make the drone hover at one meter exactly? And the purpose of this challenge was to think about what are the actual system requirements? So how do we measure distance? How do we know if we've flown one meter in any given direction? How do we know if we're even going in the right direction?

Emily Gorzenski:

And so this caused us to actually look at the actual technical specs of the drone. So we knew that it had an ultrasonic sensor on board that managed its take off and landing. But beyond that, we didn't have anything. And so we actually, so our tech stack was not just about software, we actually had to go to the hardware level. And so the first thing that we did was look at how do we measure distance? And so we looked at all of the different measurement systems that are out there in the market. And then we had to rule some out, because the drone can only lift so much. And then we settled on some basic ultrasonic sensors, which the trade off is the limited distance and the limited visibility that they have. So we started with a basic ultrasonic sensor, which we cannibalized from another IOT project that was dealing with cars. And we took a raspberry pi and we strapped a raspberry pi onto this device.

Emily Gorzenski:

And so the pi allowed us to use Python, to write our code in Python and to interface with the sensor fairly seamlessly. And there were some open source libraries that we used to shorten this process. And then what we wanted to do was actually get the data off. So we wanted to record the data and analyze it offline. So I had a Jupiter notebook hub, that I had stood up on Microsoft Azure. And built a data pipeline so that the data that we would collect from the drone would go into an Azure cloud storage bucket. And then the Jupiter hub server would connect to that as your cloud storage bucket so that we could analyze the data. Then we get into our second challenge, which is that the drone itself had, has onboard wifi that you can use to control it with an app. So it has a controller on board where you can say fly up, fly down, fly left, fly right, whatever.

Emily Gorzenski:

What you cannot do is say, go forward one meter. So we wanted to put a controller on top of the existing firmware on the drone. But that meant that we had to get the raspberry pi talking to the drone, which meant that the raspberry pi had to talk to the drone over a peer to peer wireless. But then, that meant that the pi couldn't also talk to the wifi in the office. So then we had to work on this batch upload pipeline and lots of shell scripts and, LCD pipelines and all sorts of stuff to get the data to where we wanted it to be. And given that we are working in the spike, a lot of this was kind of ugly, but it got the job done.

Neal Ford:

So you ended up with a whole bunch of hairless yaks standing around it sounds like because, of a lot of yak shaving?

Emily Gorzenski:

We would shave one yak and then om the fur that we shaved off the yak, we would discover another yak.

Neal Ford:

But that's always the nature of those kinds of spikes. But you know, there's a lot of times you learn some interesting things in a, you know, there's kind of ad hoc gluing things together and you know, Oh crap, I've got to get this to talk to that now. So sometimes those are interesting outcomes.

Emily Gorzenski:

Yeah. I certainly learned about Azure billing. My Kubernetes bill came through to my personal credit card.

Neal Ford:

Yeah it's interesting how math works, isn't it?

Emily Gorzenski:

Now we know why companies are in the cloud are doing so well. Right? That's right.

Zhamak Dehghani:

Emily, talk to us a little bit about to the analysis study you had to do on the data that you were offloading and how were you, what, how were you using the data? Where were you using it for?

Emily Gorzenski:

Yeah, sure. So what we wanted to do was figure out were our algorithms working, right? So if we told the drone to go up, would it go up? Could we measure the altitude? And then we also wanted to quantify things like, what was the lag and lead time? What was the frequency response of our controller that sat on top of a controller? And then, to what degree could we safely operate the drone? Because if you have a three second delay between when a command is sent and when the drone reacts, that means that you have to set your limits accordingly.

Emily Gorzenski:

So we are collecting lots of data like that to try to figure out how to actually get the drone to do what we wanted it to do. So our solution to autonomy was to use to whatever extent we could, the signals coming off the drone's controller. And to implement a Roomba style algorithm, where it would fly randomly in a direction until it got close enough to a wall or another obstacle, stop, turn in a random direction and then proceed from there. So we wanted to take that data off of our sensor that we had on the pi. As well as the anything that we could get off of the drone itself, upload that and then do that analysis. So that we could sort of synchronize what is the time between a command being sent in the drone actually reacting.

Neal Ford:

So Emily, one of the things that I think a lot of our listeners find interesting, Jupiter is a natural environment for data scientists, but may be sort of foreign to a lot of developers. But I know it's a very natural way to think about interacting with data and these kinds of projects. Can you talk about the distinction between a data driven kind of project using a Jupiter notebook versus a more traditional unit testing feedback kind of cycle?

Emily Gorzenski:

Yeah. Jupiter notebooks are great for spikes, for research, for doing quick hit analysis. Because they have really great visualization tools, they make it very easy to import data. You can plot things easily, you can explore it easily. Where they are still lacking is in things like unit testing, integration testing. They're still not great at, even at things like version control. There are these big files that are very difficult. They also create an environment in which code can run out of order and lots of issues like that. So they're are really good research tool.

Emily Gorzenski:

I think that they're in this indispensable, it's certainly the first thing that I reach for. In fact, one of my strongest things that I carry from job to job is a Docker image with my perfect Jupyter set up. But when it comes to actually productionizing, there's a point at which we want to take the code that we're doing in a Jupyter notebook and then moving it into a Python. A properly unit tested Python environment or even shipping it into something that's written in Scala or something that you know might be in Java or C sharp or whatever it might be.

Emily Gorzenski:

And for that, what I like to do is at some point in my process, I bring a dev over and I say, you may not understand anything that I'm doing with the math, but I want you to walk through this process of the coding with me and we'll pair. And just trust me on the math thing, because eventually you're going to have to implement this code. I'm a researcher, I'm a data scientist that's trained in, in research and development, in computational mathematics. So I know patterns. I can write production code, but it's not my strength. So we want, the people who are strongest at that to be doing that?

Neal Ford:

Absolutely. We were on a project at one point where they were asking us to fix printers and we were like, well we can fix printers. But, you know we're better at coding.

Zhamak Dehghani:

So Jeremy you mentioned that you were the hands on the hardware, but you were bringing the design aspects to the project. What are some of the highlights from the design perspective that you think might be interesting to people who will go down this journey?

Jeremy Abbott:

I think just working with, like Emily, data scientists that, I mean how many times does a designer get to work with a data scientist? Not so often, right? Working with the devs actually pair programming to some degree, watched them do their magic to the TDD, to all these other acronyms that a lot of people are just like, and that's, in that world you don't really understand. But I think overall for me it was just an eye opening, learning experience. Connecting one of my hobbies, if you look in my Instagram, you know I do fly drones quite a bit to see. And actually, like Emily just said in that last thing, as a designer, you have an idea you want to put in the world. But I think sometimes it's important to have people that bring you down to the ground and start from these first principles.

Jeremy Abbott:

Like Emily said, okay, we want to do this with a drone, but let's just see if we can get it to go forward and what are the actual very concrete steps to make that happen? And I think that's the viability aspect, but also the, okay, this is feasible. This is something we want that we can do and reproduced. And as a designer, I think you have a vision, a story out there, but it takes everyone to make that happen. That's the beauty of this project and working together collaboratively in this kind of setup.

Emily Gorzenski:

Yeah. And I think, let me, I just want to jump in real quick. As somebody who's been in the aerospace industry, I think it was very critical to actually work with somebody that has product thinking like Jeremy does. Because I think often in those spaces, right? The I.T. revolution didn't come out of the embedded systems world. There's a reason that data science, even though it has a common route with control theory and things like logistics problems and convex optimization, there is a reason it's split and developed in parallel and went much farther over the past 20 years.

Emily Gorzenski:

And that is, I think that there was sort of this grand vision, this product thinking that got people to develop the technologies that we now have. Which would have never been developed if we stuck to the more traditional engineering approaches.

Emily Gorzenski:

When I was in undergrad at Rensselaer, there was lots of talk about, how do we make high-performance cluster computing more affordable and more accessible? Because we knew that we needed to be able to run large scale simulations, but super computers were just stapling more CPUs together. Right? And it wasn't until video games led to the development of GPUs, that we really got a breakthrough in parallel computing. And then it wasn't until companies like Google and the eCommerce world demanded that we figure out a way to do things like auto scaling clusters, that we actually figured out how to solve this problem. So even though we had to work on this in the computational methods space for a very long time, it did require this idea of, solve the impossible problem to get to those breakthroughs.

Jeremy Abbott:

I mean, I think the other aspect of product innovation or this idea of thinking and working together is, my take is, and this is a very generalized take, is I think with technology almost anything is possible today. We can clone sheep, and people have actually done some CRISPR and babies in different countries, one country specifically. But I think that being said, I think when almost anything is possible, then we have to figure out, what is desirable? You know what is, I think it's really, a lot of times we hear this statement, human centered design or human centered, but I think it's shifting more to the humanities century now. It's not just for us as humans but all of humanity. And it sounds kind of bold, but I think in an era where we're moving to where we're teaching machines to learn, we're having kids learn coding, what does that mean for us as, as humans?

Jeremy Abbott:

And I think a lot of times this whole aspect of the humanity, this perspective is somewhat lost in, just in the potential of being able to do almost anything. To do cool things, but without having to really think, okay, this really, really cool thing. What does that mean for us in five, 10, 15 years, as humans and as humanity? And I think that is why you need this diverse set of people working together on things. Even if it's, I mean obviously in this case we didn't go to production with what we produced. But I think just having that diverse set of people there, it made us think differently. You know? And I think that's something that we have to hold on to moving forward. As technologists, as people building things for other people. What is, what are we building? What are the implications?

Neal Ford:

But I think the, I think that's critically important there. What you're really getting at is the ethics of software. And I think that's something that people who build software and hardware sometimes don't think enough of the long-term implications of the combination of things they build. So I think it's critical that people think multi-dimensionally about software. Not only is it a technology problem, but it's a social problem or opportunity as well. And we need to look at it holistically like that.

Jeremy Abbott:

Yeah. And I think the only way to do that is have a diverse group of people to do that. I might, I definitely do. I can, I definitely need help when it comes to code, but I think I have, I bring a different perspective. And I think if we all come from the same background and same mindset and we're all like super a euphoric, like I was in the beginning and you do need people that understand inherently this is not always the way it's going to work. Emily did, I wouldn't say she was the brakes on the projects, but she brought us back down. Okay, let's first figure this out step by step. And I was very appreciative of that as well, because I think that's an important thing.

Neal Ford:

Well I think that's one of the meta lessons of Thoughtworks. The Roy social experiment is that the synergy of different kinds of people always generate more interesting results than even really good homogeneous group of people.

Jeremy Abbott:

100% and we, and I mean the implications of that are far reaching now. You see that in the U. S. With the media lab now and the implications and just different areas. I think there is, I think and my hope is I think we're becoming more aware of the implications of what we can build and what we have built. Not we as Thoughtworks, but we as technologists. As people trying to evolve into whatever it might be.

Zhamak Dehghani:

That's I think wonderfully put. I'm wondering, your focus on IOT and the relationship of that with Industry 4.0 in Europe. When I look at globally where a lot of IOT work are happening, there's often China and Germany and UK are on top of the list. And you mentioned that the reason, one of the reasons that you pick drone as an example was that we have a lot of clients in the automation industry that would have applications of various types of priorities. For the listeners who may not be familiar with Industry 4.0 can you share a little bit of context on that and some of perhaps some of your observations, Germany in terms of the innovation that is happening or the type of work that is growing?

Jeremy Abbott:

I mean if we look at the history of computers, right? There's like four eras. And correct me if I'm wrong because you guys are, you all are probably more versed in the nitty gritty, but, it was a mainframe era where we'd all have one computer and we'd have to share it. So you'd have to timeshare. So okay, I might be able to have time at 2:00 to 4:00 in the morning and that's my time. It's kind of like the hardware and we're, and then we went to more or less a personal computer era where we all desktops. And then the mobile era. And now this era, the fourth area is ubiquitous computing or pervasive computing. And I find that the most compelling because all of a sudden from mobile to pervasive or ubiquitous computing, it's not us, as humans adapting to the computer, but the computer is adapting to us.

Jeremy Abbott:

And I think that makes that super interesting because number one, we don't have to speak the language, so to speak, as normal people have computers. You don't have to, I think people that have kids today, they don't have to learn how to type. Maybe they just do all natural language input or prop. Maybe it's all gesture. So this idea of pervasive or ubiquitous computing, I think a 4.0, Industry 4.0 is, it started, it's going to there's going to be a blend of those two together. Emily, you wanted to jump into the conversation in the beginning?

Emily Gorzenski:

Yeah. I think that one of the things that's important or characteristic about Industry 4.0 is that we're starting to get this idea that physical and digital are not two different things. They're not two sides of the business. They're the same side of the business. And that in order to achieve the goals that we need to achieve as a society, we need to get better about these things. We need to cut down our energy consumption, our waste. We need to be more environmental. And the reality is we're not going to get rid of the need to build MRI machines and to distribute, to build trucks that can distribute food to people in, and agricultural technology and stuff like that. What we need to do is be as efficient as possible, as quickly as possible and as cheaply as possible. And so I think that there's a lot of movement in this space to get to that point.

Emily Gorzenski:

So a great example of this is a jet engine, a gas turbine engine. The cycle time to get 1% efficiency improvement is anywhere between 18 and 120 months, at the moment. And that's just for 1%, because we have reached the limits of our materials and our fuels and our ability to design. So barring some incredible breakthrough in material science or engine design, the only way that we're going to get better is if we are smarter. And what manufacturers are doing is they're starting to realize that you could get maybe three, four, 5% more efficiency if you could tailor the way that an engine runs or a turbine runs based on its own particular operating history, which is different from engine to engine.

Emily Gorzenski:

And so we're starting to enter what I think is the most exciting technology frontier and we're just at the tip of it, which is this concept of digital twin. Which is this idea of using the data that a device generates to record information about it. To use it to feed augmented reality, to make it easier to repair, maintain, to make it better and easier to design and to close feedback loops with the engineers, with the maintainers, with the owners of fleets and, and vehicles and things like that to make it more efficient.

Emily Gorzenski:

And so this is this idea of IOT meets data science, meets design, meets software engineering. It's all of these disciplines coming together all at once. And we haven't quite figured out how to do it, but when we do, it's going to be a revolution in technology once again. And I think that we're starting to make strides to that. We know that 1% of the unstructured data that's being generated in industry is actually used. The other 99% is not. And the scales that we're talking about are in the exabytes, per day, across all of these devices across the world. I know some of that data lives only for a few milliseconds and some of it lives for 35 years. So how do we actually take that and turn that into meaning, value, efficiency, et cetera? And how do we do that not just once, but at multiple different timescales?

Jeremy Abbott:

And to your question again, I mean Industry 4.0 is this idea of when the engines, Emily was talking about, have sensors built into them. If they can communicate their networks, then you can do all these things. And that's where I don't think I made that clear. But I think there's the ubiquitous computing comes from Marc Reisner from MIT, me lab. It's this idea where sensors are embedded in everything. And I think the scary bit is there's a lot more happening in the backend. But, the great thing is, like I said before, it allows us to be, who we need to be as humans and not have to, do the, look at the screen, so to speak. I can just speak or whatever it might be.

Jeremy Abbott:

But I agree with Emily. I think it's super exciting time. There's a lot of stuff happening and I think that's one reason, is this idea of the tech lab really, these different horizons, the one, two, and three you might've heard about. It's where, with the tech lab. I think the goal is to be further, definitely on the two or three level and not so much on that one level.

Neal Ford:

Thank you, Emily and Jeremy. Fascinating stuff about tech lab and also the intersection of a hardware and a software. So thanks very much for your, fascinating insights.

Jeremy Abbott:

Thanks Neal.

Emily Gorzenski:

Thanks Neal.

Speaker 6:

And on the next Thoughtworks technology podcast, our guest will be the chief scientist of Thoughtworks, Martin Fowler. Please join us for the next podcast.