 parts of the Agile ecosystem or the engineering practices around agility. I think we've solved a lot of problems in the Agile space around project and process and estimation, but there's still a lot of area for improvement and sophistication on the engineering practices and this is probably the most advanced of the engineering practices is how do you do emergent design for real on projects. Now some of you may have come to my talk a couple of days ago on rampant emergence, the long-term effects of this and these talks are kind of backwards because this one is basically how to do these techniques and that talk was kind of the implications that but Nourish wanted that as part of the management conference and one of this is part of the technical conference and so that's why they ended up the way they did. So I'll be talking about emergent design this morning. There is an article series that I've written under the heading of evolutionary architecture and emergent design on IBM Developer Works. These are free articles. You can go down and read them to your heart's content. There are 19 installments here. There's a link there that gives you the baby's table of contents of all those. That's hideous and awful and so I've improved that with technology. There's a bitly link that you can follow and that's basically the things I talk about here and a few other things in more detail. My agenda for this morning is to first kind of tease out what is software design and do a proper comparison between software engineering and other kinds of engineering. I'm going to talk about the distinctions between architecture and design. Then I want to talk about things that make emergent design hard, things that make it easier, and then some details about how to take advantage of these things once you've found them. But I'm going to start with the poetry of Donald Rumsfeld, who's a famous defense secretary in the U.S. for a while and he very famously said at one point, there are known unknowns. That is to say there are things we now know we don't know, but there are also unknown unknowns. There are things we do not know that we don't know. It turns out he was talking about software here and this is the really deadly thing in software. It's not the known unknowns because you can plan for those. We got to have security and I don't know the details. We can do some planning for that. It's the unknown unknowns that always nab you in software. It's the things you didn't even know that you had to plan for up front and this is the thing that really poisoned the idea of big design up front in software. It always fails because of these unknown unknowns that you cannot possibly anticipate. It turns out that this is really just a reflection of a much broader principle and that is that the future is very, very hard to predict and that's exactly what you're doing if you embark on a gigantic architecture exercise before you've tried to start solving any part of the problem, you're trying to predict the future in all these myriad details that you've got no chance.