Public version of original 2002 internal presentation at the Institute for Learning and Research Technology (ILRT), University of Bristol, about improving software quality through semi-formal code inspections and reviews. Made public as a result of discussions at the April 2016 Alan Turing Institute Symposium on Reproducibility for Data-Intensive Research, Oxford University.

1. Code Club
An internal presentation from 2002
Dr Simon Price
Academic Research IT Manager
1

2. Developers, welcome to Code Club.
• First rule of Code Club is you do
not talk about Code Club.
• Second rule of Code Club is YOU DO
NOT TALK ABOUT CODE CLUB!
"Doh!"

3. Initial idea: a "coding clinic " for our techies
• Objectives:
• meet regularly to review code
• produce some ID coding standards
• share experiences and expertise

4. Getting Started
Kick-off meeting (15 Oct 2002)
• "Real" rather than "virtual" meeting.
• The name Code Clinic - suggestive of some embarrassing
compliant that you don't want to mention in public.
• We have a Kieren Pitts in the team and edit distance
distedit (“K. Pitts”, “B. Pitt”) is small, so...
• …Code Club was born.

5. Kick-off Decisions
• Start fairly informally and build up structures/documents as
required.
• Meet every 2 weeks. (Decide if this is the right frequency once
we've run for a few meetings).
• Each meeting, someone will present code for review (emailing
out beforehand with an explanation if needed).
• Review from various perspectives – eg. efficiency, standards,
readability, design, reuse, documentation.

6. Rule #3
Third rule of Code Club, someone yells stop,
goes limp, taps out, the review is over.
• It's not managerial
• It's not personal*
• It's about code
* unless you forget the donuts!!!

7. Kick-off Ideas
• Standards for coding
• where possible across languages
• sometimes language-specific (eg. perl conventions for capitals
being reserved for specific purpose)
• will emerge from review meetings and grow over time
• defining standards will have an impact on the amount of code
we can review in a given time (ie. reducing it);
• written standards will make it easier for new dev. staff to get
up to speed and learn how we work

8. More Ideas
• Code Repository
• We all keep snippets of code for reuse (or know where to find
them in our old projects).
• One of the useful things the code club could do is identify
potential reuse...
• building up a shared repository. (A simple version would just
be a searchable list of what to find where!)

9. Ahead of First Meeting
• Reviewee emailed CC members
• code for review
• explanation
• reminder of meeting details

10. First CC Meeting (29 Oct 2002)
Present: IMS, ETC, SNP, KP, PS
Summary: Reviewed the main path VTS3/Calnet the code looking
for ways of improving the efficiency (particularly - reducing
execution time). Also looked at style, design, readability, mistakes,
areas for re-use etc.
Files reviewed: gen.pl, constants.pl, util.pl, ...

11. Rule #4
Forth rule only two guys to a review.
Well, about 5-6 is a manageable number.

12. More Decisions
• This was a worthwhile exercise!
• Use Bugzilla as way of recording/tracking issues raised in reviews.
• Person whose code will be reviewed responsible for:
• booking room
• taking notes at the meeting
• entering issues into Bugzilla
• circulating brief note of meeting by email
• and...

13. Rule #5
Fifth rule: one review at a time, fellas.
Yes, but we do start with a report back on the previous
review from the reviewee.

14. Rule #6
Sixth rule: no shirts no shoes.
Worrying, huh?

15. Rule #7
Seventh rule: Reviews will go on as long as
they have to.
Well, we book the room for 2 hours.

16. Rule #8
And the eighth and final rule: If this is your
first day at Code Club, you have to review.
• Actually, we each take a turn to provide the code for review.
• Reviewee books room, circulates code (& notes) and
provides donuts.
• Reviewee leads through the code and takes notes of issues
raised.

17. Where Next?
• Walk before running, but...
• ... CC is producing standards and guidelines documents
• initially, internal facing
• but eventually, external facing
• ... CC might also experiment with a formalised process
called Software Inspections

18. Software Inspections
Design and code inspections to reduce errors in program development,
Michael E. Fagan, IBM Systems Journal, Vol. 15(3), pp 182-211, 1976.
• Substantial net improvements in programming quality and productivity.
• Formal inspections of design and code.
• Systematic and efficient design and code verification process.
• Well-defined roles for inspection participants.
• Inspection data is categorized and made suitable for process analysis.
• By using inspection results, a mechanism for initial error reduction
followed by ever-improving error rates can be achieved.

19. Recommended Reading
Software Inspection, Tom Gilb and Dorothy
Graham, Addison-Wesley, 1993.
• historical background
• benefits and cost
• individual phases of inspection
• inspection leader
• installation and training
• case studies

20. Summary
• Early days, but...
• enjoyable
• going well so far
• but yet to tackle issue of bug resolution