A bit late, I know, but here it is the second part of the summary (1st and 2nd day):

“Modifiability: Or is there Design in Agility?“: Martin Fowler lead some ThoughtWorks architects through a discussion of design in an agile context. He started talking about a misconception: “Agility means to start coding directly, without designing”. So he remarked that it’s very important to start designing at the beginning of the project, although it can be modified during the rest of the project. He also stated that simple doesn’t mean stupid, simple means that it’s simple to use and it has sense.

“Operational Manageability“: Dan Pritchett (eBay Technical Fellow) talked about designing for operations and how operational scalability is a software problem. He point out some recommendations about managing configuration in a large enterprise, deploying without taking down the site and avoiding SPOF. He also presented a fact: “Power and cooling are now the primary constraint to growth”, a fallacy: “Hardware will provide the performance improvements needed to keep pace with transaction growth”, and a reality: Inefficient software has driven datacenters to the brink of municipal power delivery capabilities”. He recommends trying to measure power efficiency using (and improving) metrics as for example page views per second / Watts. Dan has also a great post about scaling where he mentions all of the vectors you must consider.

“Test Driven Development: How do we know we’re done?“: Steve Freeman presented this introductory session about TDD. He started with some basic cyclical examples: implementing a test just enough to pass and then Refactor! He said TDD is a design technique and we must test the features not the methods. He also said that unit test code could be half of the source code.

“Agile Project Management: Lessons learned at Google“: Jeff Sutherland started comparing The Toyota way and the Agile Principles, and then the Google way. After that, he described how the Adwords project leader introduced Scrum into Google (an environment that does not have an affinity to processes in general). He talked about some problems that they have found (resistance, late deliveries, …) and how Google reinvented some Lean practices (work in progress). He concluded saying that “[Google] teams embraced the process enough to continue it even without any reinforcement”. At this Google Tech Talk, you will find Jeff explaining the same presentation that he showed at Qcon.

And finally, infoQ has posted a great article where they present the main takeway points and lessons learned by attendees who blogged about QCon.