High Ceremony Programming (HCP)

1. High Ceremony Programming (HCP) CSE301 University of Sunderland Harry R. Erwin, PhD

2. Where do High Ceremony Methods Fit? • Projects where the risk is low. • Projects where you and your customer know where you’re going. • Projects where the technology is evolving slowly. • Projects where you have to get it right the first time.

3. Seven Kinds of High Ceremony Projects • Technical risk must be controlled (no surprises) • Schedule must be controlled • Cost must be controlled. • Security requirements • Life or mission-critical requirements • Performance requirements • Customer requirements Schedule and cost co-vary for optimally managed programmes. You can usually control just one of cost, schedule, and technical risk!

4. Why High-Ceremony? • For low-technical-risk projects, waterfall is fastest and cheapest. • Ensures you get a known product on time. (The demonstration project for XP was a failure.) • Keeps the customer from interfering. (Amateur systems engineers with approval authority are a recipe for disaster—as the UK Government demonstrates over and over.) • Ensures critical requirements are met.

5. High Ceremony Programming Defined • Is defined by the following: • Values • Practices • Activities • Roles • Vulnerable to the cost of change curve.

6. High Ceremony Principles • Our highest priority is to satisfy the customer through on-time delivery of software that meets a known requirement. • Do not welcome changing requirements, especially late in development. • Deliver working systems periodically and predictably.

7. Principles (II) • You still build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most reliable method of conveying information to and within a development team is in the form of documentation. • Regular delivery of working systems is the primary measure of progress. • High ceremony processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

8. Principles (III) • Continuous attention to technical excellence and good design enhances quality and reliability. • Simplicity—the art of maximizing the amount of work not done—remains essential. • The best architectures, requirements, and designs emerge from well-organized teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

9. Problems Targeted by HCP • Lack of communication • Requirements volatility • Software development that isn’t used. • Out of date documentation • Obsolescence

10. HCP Values • Communication—written. • Simplicity—always do the right thing. • Feedback—on a controlled basis from the customer. • Courage—willingness to stand your ground.

11. Communication—Written • Reduces the chance of misunderstanding. • Creates risks, however: • Too much paperwork. • You’re vulnerable to demoralization. • YMMV.

12. Simplicity—Always do the Right Thing. • You Ain’t Gonna Need It (YAGNI). • Absolute simplicity isn’t always the best solution, so be as simple as possible but not too simple. • Nonfunctional requirements will affect simplicity. • Maintain standards.

13. Feedback—on a Controlled Basis from the Customer. • Go ask the customer, but be careful what you ask. • Can be used in design: • Build a first-order prototype • Test it • Adjust it until it’s right. • A little bit of analysis can replace a lot of being jerked around by feedback.

14. Courage—Willingness to Stand Your Ground. • But be willing to make design changes when they are right. • It helps a lot to have an automatic test suite to tell you that you’re still OK.

15. HCP Activities • Coding • Testing • Listening • Designing • Thinking

16. HCP Roles • Programmer/Analyst • Specialist • Tester • Tracker/Checker • Coach • Consultant • Big boss

17. Test-driven development Requirements analysis Management to plan Whole team Right-sized cycles Metaphor Simple design Refactor mercilessly Collective ownership Pair programming Continuous integration Sustainable pace Coding standards Acceptance tests (Elegant design) HCP Practices

18. Test-Driven Development • ‘The test-driven development is the method of software development where tests specify interfaces of implementation and all code must have passed the tests.’ (Wikipedia) • Martin (2003): ‘programmers work in very short cycles, adding a failing test, then making it work.’

19. Requirements Analysis • Documents what the user needs. • Describes how the system is supposed to work. You stop when you know how to build the system. • Carefully and completely done. The most dangerous kind of requirements error is the requirement you didn’t know about. • Sufficient detail to support estimation. • “If you don’t know where you’re going, don’t start walking.” (Barry Boehm)

20. Management to Plan • Plan realistically, based on your experience with the project team. • Keep a 25% contingency reserve. • Manage to the plan • Update the plan to reflect what you learn.

21. HCP Life Cycle • Waterfall or spiral model (terminating in a waterfall) • Feedback from later phases • Plan for maintenance

22. Metaphor • The system architect leads the team to a shared vision of how the program works.

23. Simple Design • Keep the design exactly suited for the planned functionality of the system. It passes all the tests, contains no duplication, expresses everything the authors want expressed, and contains as little code as possible.

24. Simple Design • The simplest design that can meet the user needs. • “You aren’t going to need it.” • Once and only once—no code duplication.

25. Refactor Mercilessly • We’ve discussed this. • Don’t churn the code. • Keep it clean to support extension.

26. Collective Ownership • Any pair of programmers can improve any code under development at any time.

27. Pair Programming • Martin (2003): “All production software is built by two programmers, sitting side by side, at the same machine.” • Boehm (2004) indicates that pair programming is about 10% slower, but the software fault rate of the resulting code is about 60% less. This is a ‘silver bullet’.

28. Pair Programming • Pair Programming (ExtremeProgrammingPractice) requires two engineers to participate in one development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example. Studies have shown that, after training for the "PeopleSkills" involved two programmers are more than twice as productive as one for a given task. (Wikipedia)

29. Continuous Integration • Martin (2003): “The team keeps the system fully integrated at all times.”

30. Sustainable Pace • Martin (2003): “The team is in it for the long term. They work hard, at a pace that can be sustained indefinitely. They conserve their energy, treating the project as a marathon rather that a sprint.”

31. Coding Standards • Martin (2003): “All the code in the system looks as if it was written by a single—very competent—individual.”

32. Acceptance Tests • As part of selecting each desired feature, the customers define acceptance tests to show that the feature is working.

33. Elegant Design • The initial design and architecture is as right as possible. • You’ll have to live with it for 10-20 years. • Help it emerge through refactoring so it is right.

34. Conclusions • If HCP is the answer, what is the question? • Certain kinds of problems, especially those where you don’t know where you’re going, are not suitable for HCP, so be prepared to use a light-weight process when necessary.