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
  youre 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 disasteras 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.
• Simplicitythe art of maximizing the amount of
  work not doneremains 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 isnt used.
• Out of date documentation
• Obsolescence

10
HCP Values

• Communicationwritten.
• Simplicityalways do the right thing.
• Feedbackon a controlled basis from the customer.
• Couragewillingness to stand your ground.

11
CommunicationWritten

• Reduces the chance of misunderstanding.
• Creates risks, however
• Too much paperwork.
• Youre vulnerable to demoralization.
• YMMV.

12
SimplicityAlways do the Right Thing.

• You Aint Gonna Need It (YAGNI).
• Absolute simplicity isnt always the best
  solution, so be as simple as possible but not too
  simple.
• Nonfunctional requirements will affect
  simplicity.
• Maintain standards.

13
Feedbackon 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 its right.
• A little bit of analysis can replace a lot of
  being jerked around by feedback.

14
CourageWillingness 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 youre still OK.

15
HCP Activities

• Coding
• Testing
• Listening
• Designing
• Thinking

16
HCP Roles

• Programmer/Analyst
• Specialist
• Tester
• Tracker/Checker
• Coach
• Consultant
• Big boss

17
HCP Practices

• 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)

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
  didnt know about.
• Sufficient detail to support estimation.
• If you dont know where youre going, dont
  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 arent going to need it.
• Once and only onceno code duplication.

25
Refactor Mercilessly

• Weve discussed this.
• Dont 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 singlevery
  competentindividual.

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.
• Youll 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 dont know where youre going, are not
  suitable for HCP, so be prepared to use a
  light-weight process when necessary.