Pragmatic Projects

1. Pragmatic Projects Prepared by Doug Glidden

2. Pragmatic Projects • Pragmatic Teams • Ubiquitous Automation • Ruthless Testing • It’s All Writing • Great Expectations • Pride and Prejudice

3. Pragmatic Teams • No Broken Windows • Quality is the responsibility of the whole team • No “team quality officers”

4. Pragmatic Teams • No Broken Windows • Boiled Frogs • Don’t assume someone else is handling it • Don’t assume changes have been okayed by leadership • Appoint a “chief water tester” to constantly keep track of scope changes

5. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Communicate within the team, of course • Don’t forget the outside world! • Generate a brand • Crazy team name • Funny team logo

6. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Communicate • Appoint a “team librarian” • Coordinates documentation and repositories • Knows who knows • Can spot duplication • Appoint “focal point” persons, each with a complete understanding of one component or aspect

7. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Orthogonality • Project activities can’t happen in isolation • Organize around functionality, not job functions. • Organize teams like code: use contracts, decoupling, and orthogonality • Select technical and administrative heads over all teams on a project

8. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Orthogonality • Automation • Code formatting • Test runs • Appoint “tool builders” to create automation tools

9. Pragmatic Teams • No Broken Windows • Boiled Frogs • Communicate • Don’t Repeat Yourself • Orthogonality • Automation • Know When to Stop Adding Paint • Allow individual innovation • Provide supportive, but not overpowering, structure

10. Ubiquitous Automation • All on Automatic • Don’t use manual procedures. • Use scripts or batches • Schedule nightly unattended tasks

11. Ubiquitous Automation • All on Automatic • Compiling the Project • Use makefiles • Generate code • Use regression tests • Automate builds • Run full build process nightly to ensure all steps continue to operate correctly • Run all tests after each build is complete to identify problems as soon as possible • Automate final build • Automate parameter changes • Rerun all tests

12. Ubiquitous Automation • All on Automatic • Compiling the Project • Automatic Administrivia • Use content-driven automation for administrative tasks • Automate web site generation by pulling information from the repository nightly • Automate approval procedure notifications using markers within the source

13. Ubiquitous Automation • All on Automatic • Compiling the Project • Automatic Administrivia • The Cobbler’s Children • Use the tools available to you!

14. Ruthless Testing • Test early. Test often. Test automatically. • Coding ain’t done ’til all the tests run.

15. Ruthless Testing • What to Test • Unit testing • Integration testing • Validation and verification • Resource exhaustion, errors, and recovery • Check normal things like memory and disk space • Check unusual things like video modes and bandwidth restrictions • Ensure graceful failures • Performance testing • Usability testing

16. Ruthless Testing • What to Test • How to Test • Regression testing compares test output with previous tests • Types of test data • Real-world data • Synthetic data • Large quantities of data • Boundary conditions • Statistical properties • Exercising GUI systems often requires specialized tools • Testing tests • Cause bugs to ensure they are caught • Use “saboteurs” to test your testing. • Testing thoroughly • Use coverage analysis tools, but don’t expect 100% coverage • Test state coverage, not code coverage.

17. Ruthless Testing • What to Test • How to Test • When to Test • Test as soon as any production code exists • Test automatically • Running tests • Interpreting results • If a test cannot be run automatically, test regularly on a specified schedule

18. Ruthless Testing • What to Test • How to Test • When to Test • Tightening the Net • Find bugs once.

19. It’s All Writing • Treat English as just another programming language. • Build documentation in, don’t bolt it on.

20. It’s All Writing • Comments in Code • Comments should explain why something is done, not how • Use meaningful variable names • Don’t include unnecessary information • Lists of functions exported • Revision history • Lists of other files used • Filename

21. It’s All Writing • Comments in Code • Executable Documents • Develop a single authoritative document for specifications that require multiple implementations • Automatically extract data from the controlling document when it is needed

22. It’s All Writing • Comments in Code • Executable Documents • Technical Writers • Follow pragmatic principles even if someone else is writing the documentation

23. It’s All Writing • Comments in Code • Executable Documents • Technical Writers • Print It or Weave It • Web-based documentation that can be kept up-to-date is preferable to printed documentation • Automatically generate different versions needed from a base document

24. It’s All Writing • Comments in Code • Executable Documents • Technical Writers • Print It or Weave It • Markup Languages • Rich markup languages make production of different documentation forms simple

25. Great Expectations • Gently exceed your users’ expectations.

26. Great Expectations • Communicating Expectations • Don’t ignore unreasonable expectations • Ensure users understand necessary changes • Impossible expectations • Unnecessarily conservative expectations

27. Great Expectations • Communicating Expectations • The Extra Mile • Surprise users with extra features, such as tool tips and keyboard shortcuts

28. Pride and Prejudice • Sign your work.