plugins/org.eclipse.osee.support.dev/process/basis.html

Beginnings:  The code debt was so high that we declared bankruptcy.

<ul><h4>Pay attention to</h4>
<li>Emergent Design</li>
<li>refactoring</li>
<li>testability</li>
<li>thesis, antithesis, synthesis</li>
<li>contained polymorphism (Gang of Four)</li>
<li></li>
</ul>

<ul><h4>Process Inputs</h4>
<li>bright, highly motivated engineers</li>
</ul>



<ul><h4>Process Steps</h4>
<li>re-plan weekly</li>
<li>review all design</li>
<li>develop user stories + plus what could go wrong</li>
<li>prototype high risk storeis</li>
<li>pair-wise developement</li>
<li>metrics to manage a project: position and velocity</li>
</ul>



<ul><h4>Philosophy</h4>
<li>embrace change</li>
<li>on teaching: my goal is not to tell you something truely new, rather to suggest what to pay attention to and what you can ignore</li>
<li>The apparent increase in uncertainty provided by the agile approach is actually greater reality not greater risk.</li>
<li>You can only teach someone something that he almost already knows.</li>
<li>Hope is not a plan, but it is essential to success.</li>
<li>Don't give up quickly.  You are smart enough.</li>
<li>Only degrade your code consciously.</li>
<li>Unquestioned assumptions are treated as facts until you are smacked in the face by reality</li>
<li>The main benefit of OO is not reuse, rather it facilitates cleanly separating usage from construction from definition.</li>
<li>Identify differences and invent a concept that allows you to ignore them.</li>
<li>Use intension-revealing names</li>
<li>Don't think of objects as data with methods, rather as entities with well defined responsibilities.</li>
<li>Use private access by policy and reveal reluctantly</li>
<li>Typing is not the bottle-neck</li>
<li>Abstraction is more than just data abstraction - it includes behavior abstraction</li>
<li>Patterns as recipes are limited but patterns as ideas are very powerful.</li>
<li>The trap: change is painful, thus my mission in life is to prevent change.  The alternative: develop high quality code and localize change so you are empowered to embrace change.</li>
<li>Do not be risk adverse, instead spike a solution</li>
<li>Shift your thinking from procedural to asserting that an object fulfill its responsibilities</li>
<li>Don't have an implementation that inherits from another implementation - only inherit from concepts.</li>
<li>How do you eat an elephant?  One bite at a time.</li>
<li>I'll see it when I believe it.</li>
<li>Patterns aren't merely recipes, but patterns are about "What are the forces?", what should we pay attention to?</li></ul>
<li>just being aware of an issue helps solve it. Often we are far more capable but we just fial to pay attention</li>

<ul><h4>Code Quality</h4>
<li>simplicity</li>
<li>readability</li>
<li>driven by testability of interfaces</li>
<li>strong cohesion: object is focused</li>
<li>loose coupling: objects are not interdependent</li>
<li>minimize redudancy</li>
<li>encapsulation</li>
<li></li>
</ul>


<ul><h4>Core Competencies</h4>
<li>effectively applies design patterns</li>
<li>understands and pays attension to code quality</li>
<li>facilities team cohesion and effectily uses pair-wise development</li>
<li></li>
<li></li>
<li></li>
</ul>





<ul><h4>References</h4>
<li>Effective Java™ Programming Language Guide
Joshua Bloch
Publisher: Addison Wesley Professional 
ISBN: 0-201-31005-8</li>
<li>Concurrent Programming in Java™: Design Principles and Pattern
Douglas Lea
Publisher: Addison Wesley Professional 
ISBN: 0-201-31009-0
</li>
<li>Inside Java 2 Platform Security: Architecture, API Design, and Implementation (2nd Edition)
Li Gong
ISBN: 0201787911
</li>
<li>The Portland Pattern Repository was the first wiki, established by Ward Cunningham in 1995 [1] (http://c2.com/cgi/wiki?WikiHistory). He invented the wiki name and concept, and implemented the first wiki engine.</li>
</ul>