 Aha! Good morning. So this morning I want to talk about the futures here. It's all around, all around the world, but it's not clear that you actually can see it, but you will see it in the next few years. You're going to see how things change and how they become different, more advanced, but everything that's going to be true in ten years is actually hiding somewhere today. So I'm going to talk about seven things that exist today that I predict will be your future in the next decade. You will see them all become increasingly important and change the way you think about software engineering. I start with this one and this is not so new actually, maybe a decade old, and it's the concept of scaling out. So if you have too many penguins you go find another beach. It used to be, let's say 1996, so we're going to go back 20 years, that business software was monolithic, it was slow to change, there were ERP databases which was the central database of most companies, still is in some cases, and in that database all of the integration of the company data happened, and that database sat on a single server because it was an RDMS, a relational database, which was a lot of scattered stuff, and so it sat on a single server. Why? Well, one of the problems with the server, in addition to the fact that stuff is scattered all over, is that if you partition your database across servers you can't have both of these at the same time. It can't, data cannot be instantly available and completely consistent all at the same time because there's distance between the servers, and so it was absolutely required that the main data for any company sat on a single server. But then, oh I don't know, around about 2000 along came Google and there was no concept of a single server when you have about 1.3 billion pages, and this is the first snapshot of how big Google was, way back in about 19, in about 2001. There's no way this can go on a single server. So what did they do? When you absolutely are too big for growth, you can't scale up anymore, you can't just like get a bigger computer because it's not big enough. In fact, there's this wonderful saying by Grace Hopper who said, if one ox could not do the job, back in the days when oxen pulled loads, they didn't try to grow a bigger ox. They used two oxen instead. And when we need greater computing power, the answer's not to get a bigger computer, which almost everybody used to do back then in the end of the 90s. Instead, you have to build a system of parallel computers and operate them in parallel and control them with software. So that is scaling out rather than scaling up. And if you look at the history of all of the big internet companies, that's exactly what they did. They didn't try to scale up. They scaled out. So this is 1999 and Google didn't tell us for three or four more years that this is what they were doing with their data center. Lots of little computers that were allowed to fail whenever because they had three copies of stuff and they could detect failure and toss out the bad thing. And hey, there were two more copies, so they could replicate it down to three. And this concept of a data center composed of a lot of little cheap things was really a novel idea. It's not novel now, but when I first heard about it, I think in about 2003 it was like, so that's how they do it. Scale getting big is not necessarily a process problem. Too many of us address it as a process problem. It's an architecture problem. So for example, in same time frame around about 2001, Amazon needed to handle a gazillion transactions like all at the same time. They wanted instant response. Fine. They had a big front end, remember that big single database or big back end and a big front end. And the back end was just the thing that was tying everything together in a very tightly coupled manner. And they had a meeting after every holiday season where the senior execs would get together and say, well, we just made it through the last holiday season, but next year we're going to be ten times worse. How are we going to survive? And finally, Bezos was listening and everybody was saying, you know what we need? We need better communication. And he said, no, we need worse communication. We need less communication. When you get to a certain size, communication doesn't scale. Instead, he said, let's stop having communication. Let's change your architecture so we don't need to have communication. And in fact, when you get really big, that's really your only option. You have to scale out and figure out how to let the little pieces talk easily without through hardened like APIs or something like that instead of having a lot of communication. Scale is an architecture problem. So here is scaling up. Say you have four transactions to complete a shopping sale. Maybe you have looking, you have deciding to buy and putting in a shopping basket, you have actually placing the order, you have fulfillment. And if you're going to scale up, then you have to keep those transactions together because remember databases manage transactions. And it keeps them proper. It keeps them always accurate and complete and can roll back the whole transaction of something goes wrong. And that's what databases did. But they said, we can't do that anymore. So instead, they took those little tiny pieces of a transaction and created separate services. And then if one of them needed to scale out, they would scale just that one or just that one. That's scaling out. Now, when you do scale out, you don't have that database to manage your transactions anymore. So you have to put software on top to manage the transactions, the rollback, all of that sort of stuff. But once you do that, you are living in a different world. So when you think about your problem, think about what Amazon does if you need to get big. You want to break the thing that's big into small pieces. They're transactions. And then you want to replicate your bottleneck pieces. And what Jeff Bezos said is teams should not be any bigger than two pizzas. A team can be fed with two pizzas. So we're talking maybe eight people. And that team should be able to do its job without communication. They should be able to independently deploy and make decisions, which means that the team has to have everybody from figuring out what to do, to writing code, to testing it, to deploying it. So the first cross-functional teams that already included operations right from the start, around about 2001. And in five years later, okay, it took them five years, they pretty much got to the point where they had all of these services actually working and running their infrastructure. So let's talk about infrastructure. So now we have Conway's Law. You've heard of Conway's Law? Conway's Law says your organizational structure and your software structure are going to basically be the same organization, same architecture. And so now what we had at Amazon, for example, with our two pizza teams, was a lot of autonomous service teams that were doing independent deployment. There was a lot of stress and ops. Because now all of a sudden you have all these little two pizza teams trying to deploy all of the time. If there's a better way to give operations heartburn, I don't know what it is. And so instead of saying let's stop doing the deployments, the VP of infrastructure who is Chris Pinkham, said why don't we figure out how to do self-service deployments? And hey, you know what, if we did that we could even maybe sell the capability. Well it was an interesting idea and it kind of went around to the top of the company and he basically decided to move back to South Africa where he had grown up. And finally it got to the top and be so since some others said hey let's do this. So they contacted Pinkham and said would you put together a group and pursue your idea? And he did. Okay, he led a team. It was in South Africa. Some people even moved from Seattle to South Africa to be on the team. And in two years later they deployed EC2, the first elastic cloud. And of course after that the rest is history. It launched in 2006 and now 10 years later basically the cloud has changed the way we think about software engineering. And it's because of this scale out instead of scale up. When we think about infrastructure we have long had an idea of virtualization. That's not particularly new although I guess in the early 2000s it was new. But oh maybe two three years ago we come up with containers and so there's Docker which went public in the very popular because it shrinks the sort of footprint of any kind of deployment into a server and so you basically can put more stuff on a server and at the same time you get portability and consistency and isolation in a much smaller area. But actually not that long after as I was watching the container talk and one of the Amazon AWS events I heard about this thing. Okay, and it was Lambda. And you know I really, the minute I heard about it I said that's it and the reason is because when I did code I programmed machines. I did control systems for big machines that made magnetic tape, sticky tape, that kind of stuff. So my equipment controlled machines and we essentially did lots of little computers on all of the pieces of equipment and a central computer that didn't do much more than pick up a send point and send it down the bus and listen for stuff. Maybe pick up status and pretty much it wasn't what we called interrupt driven what you would call today an event driven environment. And when I heard Lambda I said ah yeah that's what we did. It makes so much sense. Well to process control programmer it made a huge amount of sense. Today when you do that you actually can stop even thinking about the size of your container and whether or not it's big enough for you know different kinds of events to happen because it's just a very short thing that deals with its own infrastructure. And you get simplicity, you get isolation and by the way this is a whole another step in lower cost. And then there's the software-defined networks. So if you look at Google's Juniper they basically say there's no way we can scale with hardware anymore. Our networks have to be software-defined. So this whole concept of infrastructure as code is the only way to get serious scale out of what you have. The idea of scaling out rather than scaling up. So now let's take a look at this new technology stack okay. Back here we are in 1996. We have a client in the front end. We have some you know in middleware and we have a big database as it'll look familiar. Okay but that's not today that's not the way the world works. Some of the world works that way still but they have a little catching up to do because the world today is much more like a thin mobile app or something like that. A bunch of assembled services that developers put together and whatever infrastructure happens to be there. And when you're in this world you are actually in a different world even from a programming perspective. So if you take a look at what happened to our database here do you see that big database it's gone. When I first heard that Google had a cloud or that Amazon had a cloud and it was what 2004 five something like that. No it couldn't have been four it was too early maybe six or seven. And Michael Neigard he was in Minneapolis at the time gave us talk about what's this cloud thing. And I'm thinking well Amazon's a pre-tale store how could they be doing this thing called cloud. And he said they don't have any databases. And I said oh no I'm sorry you have to have databases either they're really dumb and lying or they know something I don't know. Turns out they knew something I didn't know. They knew that this database if you take a look at it in your typical enterprise architecture is the thing that couples together every other app out there. So in order to change anything you have to go back to the data and everything that uses that data has to be changed at the same time. So it creates a massive coupling mechanism and the concept in the new architecture basically you get bigger and bigger databases until you can't get any bigger anymore. And then you realize that you really need to go like this. You really need to split that data off and have all kinds of much smaller pieces with their own local data stores so that you can deal with them separately. So when you get really big you actually have to federate. You can't just have one big mass anymore. So if you have one great big mass you're actually not very big. That's true. So what you have here is a federated architecture. You're scaling out and they each own their own data. And by the way they talk to each other through integration through API's very carefully designed. So there is care here. But the care is no longer in the data structures. The care is in the API's to make sure that they're well defined hardened that when they move to a new version the versioning is done really well. All that kind of stuff. So this is the way that you have to think about infrastructure today. You have to think about independently deployable things that much smaller groups of people can deal with and very carefully defined interactions between with API's. And then lastly there's black swans. So you know of black swans. In Europe the idea of a black swan was so impossible that a black swan was called an impossible event. Until people went to Australia. Where guess what there are black swans. This is one in New Zealand by the way. So a black swan is a totally unexpected and completely unusual event. Unless you happen to be in the southern hemisphere in which case it's much more normal. Anyway when things happen that you completely didn't plan for and completely didn't expect. That's when you're in really trouble. The a couple of big airlines in the US went down for almost four hours. Couldn't fly a plane. One was Southwest and a week later was Delta. Because of a little tiny hardware failure and a switch or a router went out. So that's not acceptable. So when we have these great big infrastructure things we also have to realize that stuff happens. And the other big engineering thing that's changed today is that you have to deal with the fact that stuff will go wrong. And you have to code with the idea that stuff will go wrong. Remember we're on little tiny cheap infrastructure anymore. At any point in time anything can die. So you have to change how you think about that. And you also have to change how you test. So if you look at resilience engineering there's three kinds of systems. There's really fragile systems which unfortunately too many of you have in your computer system. That's what we call legacy code right fragile. Okay. And then there's robust stuff. It used to be robust when it was a baby when it was small but it got big and now it's fragile. And then there's anti fragile and anti fragile are things that actually thrive on being disrupted and being hurt and they regenerate and come back stronger. And it's the anti fragile systems that we're building in our great big data centers today. How do you get anti fragile systems is the way you test is by hurting it by making something go wrong by taking out a server by unplugging things by putting in defects. Netflix is probably the most well known for this. They have a whole simian army which does all kinds of things from regularly injecting faults which is by the way their major testing mechanism. You inject faults automatically with chaos monkey. And should your code do something bad when chaos monkey injects a fault you've got a problem with your code. And it's a key testing technique all the way up to the chaos gorilla which takes out an entire Amazon region and sees what happens. And it's this whole concept of creating fault tolerant rather than fault free. So it's not actually really about service level agreements that are 99.9999 whatever 5 9s reliable as it is creating stuff that doesn't fail badly that fails and recovers really fast. That's the game today. And you have to learn how to do that. And you also have to learn how to code for systems that are going to fail and then recover. So if you look at software engineering just to sort of do a sort of mid mid term summary here. There's the way we used to do things when we scaled up and the way we need to do things when we scale out. When we scaled up we used to do periodic releases because we had that database and we had to sort of coordinate across a lot of stuff. We do continuous delivery now. And if you aren't doing continuous delivery you should ask yourself why not. Because the ability to deliver rapidly is basically the way that you keep your code robust and safe. We used to have this big monolith database which coupled everything. When we realized we need to get really big we have to move to much smaller services or you can't grow. The database used to be the integrator. Is it in your company? Can't last. Not if you want to grow. You have to figure out how to create really good APIs that become the integrator. I have a recent essay I posted on my blog site about databases integrator in an ERP system. I mean you have to have an ERP system but maybe you want this one for that part and this one for people and that one for logistics and this one for manufacturing. What are you going to do? How are you going to integrate the databases? Maybe you don't. Maybe the idea is not to integrate through databases anymore but to integrate through APIs. You need to not have state when you are running on cheap little hardware that can die. Because your service has to be item potent which means you restarted it has to get the same answer. You can't be halfway through restart something and get a new answer the next time because you didn't finish the first time. You have to really think hard about what the stateless programming mean. I'm actually more comfortable with stateless programming than a lot of you because that's the kind of stuff I used to do when I program machines because guess what? They could die anytime. Any piece of equipment in a manufacturing plant can have the plug pulled or do things that go south. We always plan on everything failing all of the time and so we never were able to count on what was supposed to happen before. You have to think about asynchronous communication rather than synchronous communication. This is strange for people who have done synchronous communication all their life but actually it's a difference between a phone call and a text message. Phone calls are synchronous. Text is asynchronous. It works better. Procedural programming versus different programming. You have to think about how do I deal with responding really rapidly to something that happens? How do I structure my code to do that? There is such a thing as consecutive execution versus concurrent. So what if I'm doing something and I have a couple or three different things that are happening at the same time, I cannot assume that one of them completes before the other because I don't know. And then the whole concept of not worrying so much about being defect-free as full tolerance. So these are really big shifts in the way you think about software engineering. And something that you should think hard about, how does this affect my career, my background, the way I think about doing code and also how does it affect the way my company does stuff? The next big thing I'm going to call insight. Okay, so one of the things I think Agile has kind of failed at and still fails at is having a team know what to code, what's important, what's priority, what should be done. How do we know we're doing the right thing? How do we know we're solving the right problem? But from my background as an engineer, I learned how to program in an engineering department, we didn't have outside people coming and telling us how to do code or how to do wiring or how to control big processes. That was our job to figure out. So we were given problems not, problems to solve, not, you know, features to develop or priorities to go one, two, three. So I think what we need to get into our heads is, in any big complex system, one person is not going to have enough good ideas from enough background, from enough broad perspective to come up with the idea, the the instructions for what should be done, what are the priorities, how do we know what to do? Collective wisdom is going to be better. This isn't a pretty good Agile tenant. But do we really live it when we expect somebody else to tell the team what to do to set priorities for the team, to decide whether or not the team has done the right thing? I don't think so. We need to have teams to which we give problems, not tasks, not features even, but problems to solve. And you can scale out with that. Whereas if you have only one person, you're trying to scale up in the minute you get complex, this falls apart. So if you take a look at product design, and I'm going to call what we do product design because we're putting a product on the market. And we own the product. I hear people talking about the business and I think, huh? Who are they? They're us. We are one company with problems to solve. And we work together as a group to put a product on the market. And when we have a diverse team, including people who understand customers, people who understand marketing, people who understand operations, people who understand the data, the the cloud, people who understand how to test stuff, people who understand how to design stuff for users, people who understand how to code, all together, we need a way, an agile, a process, which helps us figure out, as a team, how to make stuff happen. Now we've had impact marketing, good, we've had Lee New X, good. And now we have a new one that I want to tell you about that I heard first in Budapest from Marty Kagan. And it's called the, it's a proven design process, using the design thinking developed at Stanford D. School, and the whole idea of using design to figure out what to do with the team that's doing the work, figuring out how to solve the problem, being walked through a design process. I've written a little bit more about this in an essay I released about what, three days ago, so you might want to read it. But just a quick summary, if you look at this book Sprint, and that's not a agile Sprint, that's a design Sprint. It's a one week process. And it uses the word Sprint because it's time boxed, and so they stole that from agile. A time boxed five day design process, led by a designer, facilitated, excuse me, by a designer. And in this process, you take five days, or maybe you compress it, but typically, the canonical one is a five day thing where you start out the first day, get everybody to understand what problem are we trying to solve and agree on a definition of the problem. You have to ask the right questions before you're going to get the right answers. And then the next thing that you do is you have, excuse me, you have a sketch day. So instead of asking people to jump up and talk, how many of the team is going to jump up and talk? Maybe half. You want ideas from everybody, even if they're working in their second language, even if they're a little bit shy, even if their ideas kind of far out, even if they're different. And so instead of brainstorming, you use a sketching process where everybody sketches up to eight ideas, and then the sketches are reviewed and nobody knows where the ideas come from. People look at them and think about them, and they choose a few of them, not just one, you want an assortment of them, to try out. Now, all this time during the week on Friday, so that's Wednesday when they decide they're going to be real live customers coming in for a demo. And you don't know what you're going to demo yet. You have another day to get it ready. So on Wednesday, you create a journey map of how this demo is going to work. Okay, we're going to demo something to the customer. We have this hypothesis that if we do this, the customers will have this reaction. That's our hypothesis. How do we create a prototype to test that hypothesis? And you write a journey map, you take a few hypotheses and you write a journey map of how I'm going to test this with real live customers. And the next day, a prototype is created. Again, by designers using design tools, quick, easy to put, you get a facade that looks real. The customers think could be real. And on the last day, about five customers come in, the facade, the prototypes are run by the customers with a single person. Everybody on the team is watching through a remote camera. And you see how the customers respond to the ideas that you had. And you learn without writing any code, without any minimum viable product, which ones of those ideas are worth pursuing, and which ones are simply not worth pursuing. So this gives you a lot more ideas. Now, this is not the only way to get ideas, but the whole idea in lean, the idea is to explore multiple options from a broad array, not a few narrow options from the center. So you want outliers, you want crazy ideas, you want to try different things, or you won't get, you know, you won't get the one that is really going to be interesting. The next thing is smart. Okay, so that last one was get the whole team involved in deciding what to do, in deciding how to try things, deciding on priorities. And this one is about smart connected products. Okay, so today anybody here that's working on any product of any kind, I don't care what it is, can assume, if it's not already true, that the products that you buy, the products that you're working on, the products that you see, are going to somehow become more digitized at a much more detailed level. So it could be a self-driving car, these are not all that far away, it could be a tennis racket. You know, this tennis racket, this is a company that was, what is it? French company 200 years old, decided to put a little sensor in the tennis racket, and they went all the way to getting a new rule put in the tennis rule book. There had been 31, now there are 32. And his first rule in maybe what, 50 years. Because what they said was, we want a rule that says it's okay to have this little sensor there. Okay, maybe the tennis person, maybe the tennis star doesn't look at the data until later, but you gather the data, put it on your mobile phone, and then you do data analysis later and find out all sorts of stuff about your tennis game so you can improve. Or, you know, voice entry. Suddenly who would have thought Amazon would be coming the one that is the easiest one to use. Or another thing that's going on is GE, GE does aircraft engines and you know, electrical grids and stuff like that. And they decided that instead of doing appliances, they're going to sell off that, instead of doing financing stuff, they were going to sell off that, and they were going to become a digital company. Because they owned all these aircraft engine and all these big infrastructure stuff, and their customers wanted nothing more than to figure out how to optimize the uptime of their infrastructure. They needed data. They needed to know how to run aircraft further and more efficiently. How to get their electrical grid service before it goes down and stuff like that. So they spent about the last, I don't know, five years completely changing the character of the company into a digital company. They have a cloud and the interesting thing about their cloud, which is called Predix, it's focused on predictive maintenance, focused on gathering massive amounts of data from all those kinds of big pieces of equipment that I told you about. With all of the security and government regulations required for that kind of environment handled. In fact, on their cloud they can even deal with medical data, which is pretty tricky when it comes down to it. I figure for banks, if they can do medical data, there will be a cloud for banking pretty soon. So they, the other thing they did was they put together this cloud and they were hiring many, many very good people and they got to the point where it was kind of ready to release and it turns out it was going to be proprietary. And at the top of the company, the CEO in conjunction with the experts he had recently hired said that's silly. Proprietary isn't the way anymore. We're going to actually make this public. So they stopped, they rewrote everything, same people, but they made it, they made a public. So they now have a public cloud for the industrial internet. So, and then you have Google releasing its deep learning technology. So there's this guy in Japan, his family has grown cucumbers for all his life and he happens to be a software guy, so a software engineer, so he needs to take over the business and the most labor intensive thing is sorting out the cucumbers by grade. So he went to Google's class on TensorFlow and he came back and he was Google's deep learning to set up a cucumber sorting machine. He has now taken massive amounts of labor out of sorting cucumbers. Everywhere you go, everything you look at, this digitization is going to come and you can either be part of that or you can let somebody else take over your business for you if you don't think about how your business is going to be truly digital. So this concept of digitalization, here's an interesting book, it's not the only one, but pretty good one, by Gartner, and you need to be digital all the way down. Forget this, IT is over there doing stuff anymore. You're too late for that kind of isolation. You need to have digital all the way through the core of every product line and you need to have good software engineers sitting in the line business figuring out how to create good digital products. And the last one is platforms. Okay, so if we take a look at platform, let's see, this is a platform, this is in Peru, in Pesach, near Cusco, in the mountains of Peru. It's a market and this has been there for, I don't know how many centuries, so you all understand markets. It's where the buyers and the sellers get together. The interesting thing about this market and every market out there is that somebody is providing the space. This is a square. The city owns the square. The city sets up some rules as to who can who can sell what and where they're going to be and you know what hours it's going to be and when it's going to close and all of that sort of thing. Platforms are the people who own the city square. They don't bring in the food. They don't buy the food. They create the marketplace and when you look at platforms, it's a matchmaker, a business that connects members of one group with members of the other. Here's a bunch of them. Everything from Visa, Spotify, Airbnb, YouTube, you just name it. Every one of these connects two different people and when you happen to be working with these companies, they're not so much worried about one customer being happy. They're worried about creating an environment in which that one transaction, sell a room, create a ride, listen to a song, is a really good transaction and there are a lot of them. And it's all about scale because they don't make their money on selling anything except space in the market. And so they just get a little bit of rent for the stall that's in the market and if they have lots of stalls, they get enough rent to be able to support the infrastructure that they have to put together. So platforms become things that actually if you're in a business where a platform comes in, you're in trouble because a platform is going to beat a pipeline product in the same market every time. You see it with taxis, you see it with hotels, you see it with lots of stuff and there's a reason for that. Economically, platform companies don't have to do a lot of work. Okay, they need scale. They need to focus on the transaction, make sure it's good. They need to do stuff like being policemen and stuff like that. But they have their marginal economics are amazing. If they do one thing good, they can get massive amounts of additional transactions going through their system. So they don't have to put up a new hotel. They just have to go into a city and say, Airbnb is now here in Singapore. And suddenly they have a whole bunch more rooms. So their marginal economics of production and distribution are way, way more favorable than that of a pipeline product. So it tends to be if a platform comes into your market and you are trying to be a matchmaker you're going to fail because platform comes instead. And I think this is what's going to happen to banking, especially in the EU, where we have the open APIs coming in 2018, which means that in the EU, anybody can get into any bank account at any point. Now think about matchmakers. Up until now the bank had to tell me everything it knew about my bank. And nobody else could know. 2018, there's going to be a lot of matchmakers, a lot of platforms coming into the financial industry in Europe because they can, because every single banking account will have an open API that any certified entity can come in and get at, deposit money, look at balances, stuff like that. Now if you're a bank and you're going to compete against that, you have to think open. So let's just sort of sum up and run by those things one more time. Scale over, scale out over scale up. You know I see a lot of people trying to scale agile, but it bothers me because to me that's a scale up philosophy rather than a scale out philosophy. If you're thinking about a scaled agile process, and those of you who are here thinking about that, I apologize, but maybe you should be thinking about your architecture first. Maybe there's something wrong with your architecture that you have to have all that communication and scale. Scale out rather than scale up. Infrastructure as code. It's safer, it's cheaper, and therefore it will win. And it's not just banking that says I'll never be here. Yeah, there will be banking. It's just going to be a banking cloud, and there will be one or two banks that own the banking cloud and the rest of the banks will go there because it's cheaper and safer. So the economics say infrastructure is going to be code and only a few people will own the infrastructure. It will be like electricity. It will be a commodity, but a really well done commodity. APIs are going to be the integrators, not databases. Fault injection is a testing technique you need to get good at, because it's the thing that's going to give you really robust and rapidly recoverable code. You need to not, or yes, you have to get stuff right, but you also have to make sure stuff can recover from any type of interruption. Teams, not somebody with a title, should be deciding what the team does, what the priorities of the team are, and how that should happen. Now if you have 30 or 50 or 150 or 500 people, it doesn't work. So you got to get your architecture straight so that your teams can be small enough so that they actually can take their insight and bring it to bear on whatever problem you need. So look at a little more about some of the videos that Google has on the sprint because it's from Google Ventures, and it's been used by huge numbers of venture companies funded by Google Venture and lots of other companies. Marty Kagan says that people using that kind of process of rapid generation and validation of ideas are the best startup companies in Silicon Valley today, the most productive ones. Digitization, everything will be digitized, even ice cream from last night. So somebody said, tell me, I'm going to give you something and you tell me how you're going to digitize it. And I said, shoot. And he said, ice cream. And I said, ice cream. So it comes in a container. What if the container had a little sensor in in which you could track the temperature of that sensor at its entire time through the supply chain? And never, never let that temperature get out of any kind of spec. So by the time I get the ice cream, it's been handled in the optimum temperature guaranteed its entire trip. And he just named something and I named a way to digitize it. You name something and then think of a way it's going to be digitized. And platforms. So this is where the future is going. They exist today and you need to be paying attention to them because they're going to be coming to a company near you, like yours or one of your competitors. And it would be better if you participated rather than fought against these trends of the future. So with that, thank you. And I think that's the end of my time. Yeah.