1. MESDA Conference 2002 MESDA Annual Conference 2002 Software Development Track Best Practices

2. MESDA Conference 2002 Presenters DeLorme Christian Ratliff, DeLorme cratliff@delorme.com Standard IO Jesse Chunn, Standard IO jchunn@standardio.com

3. MESDA Conference 2002 Three Tips for Better Software document enforce review

4. MESDA Conference 2002 First Principles At its very birth, in our brains, software contains errors. The moment you type it in, software contains yet more errors. Conventional testing, no matter how thorough, fails to find many errors in software. Software, according to its nature is brittle, changes create yet more errors. This mantra is definitively true: “Many eyes make good software”

5. MESDA Conference 2002 Step #1: Document Documentation can serve two purposes: – Guides the implementation. – Describes the implementation for a third party. Documentation for each function or method: – Causes us to read the code again. – Forces us to use an editor’s eye. Describing a class or module – Shows us a systemic vision of it!

6. MESDA Conference 2002 Step #2: Enforce A class or module contains implicit contracts: – The arguments may have ranges. – The container is in a consistent state. – A dependency on some container member. These contracts should be explicit, not implicit. There are many explicit contract systems: – Design by Contract makes contracts completely visible to developers. Writing contracts forces us to read our own code.

7. MESDA Conference 2002 Step #3: Review How many times… Only compilation finds more errors than code reviews. We learn during a code review. We teach during a code review. A house is cleanest just before a guest arrives. The big secret: A house is cleanest just before a guest arrives.

8. MESDA Conference 2002 The Great Cycle of Software Enforce Review Document

9. MESDA Conference 2002 Summary Anything which forces us to read our own code reduces errors: – Documentation makes us read our own code. – Explicit contracts make us read our own code. – Code reviews make us read our own code. Fewer errors means less time spent: – tracking down errors – fixing errors – re-releasing because of errors Letting us focus on what we want to spend time on.

10. MESDA Conference 2002 Post Mortem Review Process Send in the clowns

11. MESDA Conference 2002 Jesse Chunn President of Standard I-O 11 years as a programmer Primary project lead on hundreds of projects Experience with both successful and unsuccessful projects

12. MESDA Conference 2002 What is the “Post Mortem Review” Process? Review performance Expose bad practices Discover best practices Understand the difference between compromises and mistakes Understand the difference between innovation and showmanship Operate as a “Learning Organization” Project post mortem is an opportunity to:

13. MESDA Conference 2002 Why Do They Call It That? Post mortem suggests the project is “Dead” Has negative connotations Should be called “Post Project Review” or something like that…

14. MESDA Conference 2002 Anatomy of a Successful Post Mortem Review Part of original project schedule Dialog vs. Discussion Constructive vs. Destructive Criticism Open sharing of Lessons Learned Provide for application of knowledge to future projects Record of “session”

15. MESDA Conference 2002 The difference between “Discussion” and “Dialog” Discussion implies debate – He said: “You should have done it this way…” – She said: “I did it like that because…” Dialog implies insightful consideration – He said: “What if you had done it this way…” – She said: “That could have worked if…” Dialog promotes open and honest communication without the fear of reprisal or the concern of accepting blame or admitting mistakes

16. MESDA Conference 2002 The difference between “Discussion” and “Dialog” (cont.) In a discussion, we assume someone is responsible for everything, good or bad. In a dialog, we assume everyone did the best job they could, given what they knew at the time. A positive result will come not from judgment, but from learning and growing from our collective experience.

17. MESDA Conference 2002 Goals of Post Mortem Review Personal growth Organizational growth Team building Knowledge sharing Documented results Enhance “Big Picture” view of future projects Shared vision

18. MESDA Conference 2002 Personal Growth The Post Mortem Review is ALL about personal growth Without personal growth as a key consideration, organizational growth is impossible Organizational growth IS the personal growth of a large number of long term contributors

19. MESDA Conference 2002 What Are NOT the goals of Post Mortem Review? Finger pointing / blame placement Checking “PMR” off of the schedule Comparison against previous PMR’s Software development training Celebration Recognition

20. MESDA Conference 2002 Who Should Attend the PMR? ALL Contributors – Yes, that includes testing staff – Yes, that includes documentation staff – MAY include client reps, depending on involvement and other factors – No, that does not include anyone that was not involved, like the boss* (especially the boss?) * Unless the boss was involved in the project, of course

21. MESDA Conference 2002 How to Conduct a Post Mortem Review Project Overview (carefully…) Acknowledge mid-term changes, if any (ha ha) Compare expected results to actual results Identify new discoveries / mistakes Identify adherence, non-adherence to “Best Practices”, and why or why not Dialog Document

22. MESDA Conference 2002 Document, Document, Document What went wrong What went right What is known What is unknown What should be tried or experimented with What should be adopted as “Best Practice” What should be avoided as “Worst Practice”

23. MESDA Conference 2002 What Should Be Covered? Project priorities (in the beginning and in the end) Initial expectations Results (how did things turn out) Excluded requirements (why?) Lessons learned (ongoing list from all projects) Success or failure of risk management PERSONAL goals for improvement Organizational goals for improvement (?)

24. MESDA Conference 2002 What Should You Be Focused On During the PMR Process? At all times, all participants must be consciously aware of the purpose of the Post Mortem Process: To become a more effective individual as part of a larger team, to become a more effective team as part of a larger organization, and to become a more effective organization as part of a larger universe

25. MESDA Conference 2002 Questions?