 And so this is the problem that we're trying to solve, which is that today developers at development time, before they deploy their app, before they have any information about what it's going to do, and before they have any understanding of this wide and complicated world that their app is going to be deployed into, have to make this really, these really difficult decisions and they have to try to adapt, right? And the reason is because they have to write certain code. You know, has this deterministic property to it and the code that I'm going to run has to have that property, even if it's trying to make complicated decisions. And so what I'm forcing the developers to do is very difficult. I'm forcing them to convert uncertainty to certainty. Our observation is quite simple, which is maybe we can remove the need for developers to make decisions at development time and instead allow them to express flexibility. So what does this mean? So this is one way of doing this. This is not necessarily a very good way, but you can imagine replacing an if-else statement that requires logic constraints with a maybe statement that just provides information to the runtime system that there are alternatives available at this part of the code. And then the developer doesn't have to make this choice. So what am I doing here? Essentially, I'm engaging the machine in a process of adaptation. I'm engaging the runtime. I'm engaging another system. And what I'm doing is I'm saying, hey, by the way, I think that there's a knob here that might be interesting to turn at runtime. I don't know how to turn it. I don't know what effect it's going to have in various places. I don't even know if it's going to work, but I'm exposing flexibility. And what that allows the system to do is adapt. Because by exposing flexibility, I'm actually going to enable runtime adaptation. I'm building an interface between me and the runtime system, where I'm showing the runtime system how my code can adapt. Places in my code where there are knobs to turn that the runtime system may find useful. And this is a very, very brief overview of the whole system design. That's something that's been going to be supported by my NSF career ward. And there's a bunch of sort of fun challenges. So the first challenge is, how do you figure out how to express the uncertainty? How do you work with developers so that they express useful uncertainty? How do you build sort of new paradigms for people to think about, where are good places in my code that I might want to build an adaptation interface? Then there's this whole testing challenge. So you can test to find out how things work in the real world on real users, but that's sort of disruptive. It would be better if we could do this testing pre-deployment. And so what we really need, and one of the things I'm excited to work on, are new frameworks for doing pre-deployment testing in a way that is representative. Because right now we have these monkey testing frameworks, and those are quite useful in certain cases. But they're mainly designed for finding bugs. They are not designed for emulating or simulating real world user behavior. And if we want to actually make these types of choices, we need representative results that sort of reflect how actual users behave and aren't just designed to try to get the app to crash. And then finally, how given this data do we actually convert the information that we now have and the flexibility provided by the developer into good runtime decisions? And we have several plans for doing this. Certain decisions we think can be made in static ways that respond to slowly changing features. So for example, the features of the user, features of the device, the network connection in my broad geographic area that doesn't change very often. And then there are cases where I'm actually going to have to be able to build and deploy dynamic adaptation policies that respond to rapidly changing features in the environment. And that's, I think, going to be much more challenging. So this is a fun project. I think there's a lot here to work on. It's a very interesting approach to creating sort of man-machine synthesis in how we write code. There's a lot of work in the programming language community about automatically generating code to solve certain problems. I think that's fantastic, but I think it's going to take a long time to get there. And in the meantime, how can we encourage humans and computers to collaborate to build apps and services? So what we're kind of trying to get the human to do is indicate the parts of the code that are required for correctness and then build flexibility interfaces that allow the system to adapt it at runtime, then take advantage of all this automation, machine learning, all these really nice techniques. Let the computers do what the computers are good at and you do what you're good at, which is understanding your app requirements and making sure that those are encoded in the certain part of your code. And the goal here is to eventually be certain. So when I get to runtime, I want to make good decisions. I don't want to be doing experiments at runtime. I can in certain cases, but I don't want to. When I hit this branch, I want to know what to do on that particular device at that time for that user under those conditions. That's the goal.