When you're trying to build an app that's secure, one of the important things that you want to look at is how easy is it to understand your app. So, if you go and you build an app out of a set of components, if you go and build it of two components and you want to make it secure, well, you have to go and look at two components when your going and evaluating this app. Similarly, if we went and broke this thing up and we added hundreds of other little components that are all talking to each other, and we have all these complex interconnections between the apps. The more interconnected, the more complex our app is, the more difficult from a security perspective it becomes to make sure that we have done the right thing. And this is why there's an important principle that we want to follow when we're building our applications. And this is called economy of mechanism. And what this means is whenever possible, we want to try to use the simplest possible solution to solve our problem. So that from a security perspective, it's easy to go and look at what we've done. If we don't need to do something in a more complicated way, we shouldn't. Now this is sort of a design principle in general, that you want to make your code as simple as possible to get the job done effectively. Now we want extensibility, we want all these things in, but we only want them when we absolutely need them. So there is a principle that you hear sometimes called, you ain't going to need it or you aren't going to need it, YAGNI. This certainly applies in security. Don't build something that you don't absolutely need, because once you build it, you have to protect it. And not just protect it right now, but protect it over the entire life of your app. So whenever we're building something, we want to think about what is the simplest way that we can build it in order to get the job done. And this will pay off for us, from a security perspective. The more complex this thing is, the more chance there is that we've made a mistake. And the harder it is for us to look at it and know that the right thing is happening. And this can apply to all kind of design decisions. It can mean having more classes, more lines of code. That can certainly be an example where were are doing more than we need to. But it also can come down to adding extensibility in places where it isn't really needed or helpful. And that extensibility makes it hard for us to reason about what's going to happen. So for example, if we can change things at runtime, change the execution very easily of our application at runtime, it becomes harder to say, yes, this is safe. This is an okay way to do it or no, it's not. Because if we can change this at runtime, what may seem okay may not actually be okay depending on the input that our application gets. So we want to try to make our application as simple as possible for the job that we are trying to perform. And sure, we want to incorporate best practices of design, extensibility, modularity, all of these things. But we only want to add those capabilities where we absolutely need them or when we need them. So if we don't need modularity right now today, but we can design it in so it's easy to add later, or it isn't going to be hard to add later, then we should wait. So from a security perspective we're not defending that modularity from now until the end of time. So, economy of mechanism is about making things as simple as possible to get the job done. In order to make it easier to reason about the security of the application, and also, less likely that we've made mistakes.