 It's probably the most technical talk of the four I'm giving this week. I start out by sort of apologizing, because this is actually probably more about me and actually some of the pain I've gone through since about 2005. But the reason I tell the story this way is I'm trying to make sure that the pain you go through getting to services is not as severe as the pain I went through. So hopefully as I go through some of the things I did and didn't decide it weren't actually bad things, maybe you'll avoid those same mistakes yourself. So this story kind of starts in the beginning before services and basically a layered architecture. As you can see, we have some functional towers, we have some cross functional services. Of course, this is a picture of Stonehenge. And before you ask, no, I'm not old enough to be the architect of Stonehenge. But I find the analogy to quite powerful, because this is how I describe building big applications. It's like trying to build another Stonehenge. It's not necessarily a good idea anymore. So this story starts with actually me living here in Bangalore, working on a million line of code application. The application was actually quite well established at the time. In fact, at one point in time, this application was the largest Sun certified J2 application in the world. And it started out its life very nicely. It's some very elegant design associated with this application. In fact, Martin Fowler came as a consultant to this particular project. He looked at the architecture, a lot of influence, the architecture heavily, even to the point where he actually joined ThoughtWorks after this, because he liked the company. So a lot of the patterns in this book come from this application. So in the history of computer science and evolution of computer science, this application was actually quite important. So what did I find when I got here to Bangalore in 2004 to work on this project? Well, we kind of found a million lines of code. It had a couple thousand tests, which sounds like a lot, but really wasn't. They had a 70% success rate on running the acceptance test. And that was considered okay. And it was kind of a different 70% every day. It was still okay. And I was a little bit terrified of that. We had a bug database that had over a thousand entries in it. So these are a thousand things we found wrong with it that we hadn't yet fixed over the previous five, six, eight years. It was still being changed, in fact, very actively changed, and almost no new tests were being written for all the changed code. So this was a bit scary, especially when myself was kind of an agile leaning and thinking TDD and all these other things. And here was this monster that just almost didn't want to be tamed. And to some degree, one of the things I tracked very carefully was unit test counts. I like to sit down and write code with colleagues.