Dan North - Agile Troublemaker, Developer, Originator of BDD
<p>
ABSTRACT
<p>
Software gets complicated fast.
Most of good architecture and design practise is about trying to slow the rate at which software gets complicated.
You can't stop it, it's a form of entropy. 
You can only slow it down and do your level best to stay on top.
<p>
<ul>
   <li><q>Goal of Software development: sustainably minimise lead time to business impact</q></li>
   <li><q>Productive is not the same as effective</q></li>
   <li><q>Code is not the asset. Code is cost</q></li>
   <li><q>What does it mean "understanding code"?</q></li>
   <li><q>Code should be stabilised or killed off.</q></li>
</ul>

Two complementary patterns:

<h3>Short Software Half-Life</h3>

<ul>
   <li><q>How long till half of the code-base changes in an unrecognisable way?</q></li>
   <li><q>Good code can tell what it does, but not why?</q></li>
   <li><q>Good code can tell what it does, but not the 3-4 failed attempts.</q></li>
   <li><q></q></li>
   <li>architecture decision record <a href="http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions">Documenting Architecture Decisions</a></li>
   <li>Keep a journal of decision made during development</li>
</ul>

<h3>Fits In My Head</h3>

<ul>
   <li><q>Little computers passing messages.</q></li>
   <li>What would James say?</li>
</ul>