This talk had the great contradictory title of "Laws of Agile Development". The talk had several great points:

-Seating was short in the room. JP asks to share a seat with me. I told him no kissing though (Sorry to dissapoint you Justice).
-Do one thing at a time
-Minimize wasted motion
-Maximize Feedback. (the faster you get feedback if something works the better i.e. TDD is great for that)
-Enable Changes (make it easy to change)
-Do the simplest thing that could possible work
-"It is easy to add complexity and hard to remove it"
-Simple is different for everyone and will very between technical levels
-Don't build what you don't need. Its a waste of time usually and things always change in projects so it turns out to be a wasted effort most of the time
-Design vertically as in slices of functionality not horizontally (i.e. trying to build the whole data access layer then business etc.)
-Integrating early with other systems/components minimizes the amount of rework that needs to be done later
-The Last Possible Moment: put off a decision until the last possible moment until you have to make a decission. This allows you to gather the most information. i.e. dont act on speculative info, keep your options open!
-"I want to be able to understand a peice of code by looking at its name"
-JP leaves... I hope he is getting some popcorn
-Bellware shouts out "Microsoft Sucks!" when Jeremy could not change the font size in visual studio for some reason.
-JP comes back... he does not bring popcorn.
-Single Responsibility is key (If you don't do this... you should.... no rebuttles to this are allowed)
-We debated that a system having too many classes becomes hard to work with (my feeling is that namespacing allows you to divy any complexity into more logical grouping if necessary)
-Open Closed Principle - Software should be open for extension, but closed for modification"
-OCP: Be able to add new functionality to an existing codebase without having to modify (or do minimal modifications) to existing code
-Avoid leaky interfaces (i.e. should not have to check the type of a variable and function different based on type)
-Eliminate duplication (everyone should be... not many are)
-Jeremey feels that TDD is the most important design tool (I agree... but flame his blog if you don't... not mine)

Jeremys Laws
-Zeroeth Law: If code is hard to test, change it
-First Law: Isolate the ugly stuff (be able to test ugly stuff in isolation like databases, ad, web services, messaging, etc.)
 a good example of this is using MVP to make testing the UI easy
-The slide changed... I am lost.. he had them on his blog he said

-Value proposition of TDD: save more time in debugging than you spend in unit testing

-Low blood sugar: I tune out (sorry)

-Socialize the design (its a community designed app)
-Collectively challenge the design of the code