Code Reviews 3 - As an Author, When am I ready for review?

This checklist for the author calling the review. The checklist helps avoid code reviews that just talk about the trivial stuff.

As an author, I should respect the time that my reviewers are putting into my submission. In that case, I wish to have my work as complete as possible and have a clear list of inputs ready for the reviewer, so as to get the most effective code review possible and not waste any ones time.

Authors's Code Review Checklist

1. Tests complete and passing
2. Code style adhered to
3. Code complete
4. Programmer documentation is complete
5. Code, Test and Developer Documentation is committed
6. All static analysis run and passing

Exploration

1. Tests complete and passing. All legacy unit and integration tests are running and passing. Prove that our changes have no undesired side-effects on existing functionality. Any new tests that are relevant are written, running and passing. We apply the same source control standards to test code.
2. Code style adhered to. I'm not saying that you have to use the same IDE as everyone else, but you should match the style that the majority of the code is written in as this enhances readability. So configure your IDE or run Checkstyle to ensure compliance.
3. Code complete. A no brainer, obvious? Well the code should be complete enough to make sense, run and do something useful. It might not be the complete solution. The author should be pragmatic.
4. Programmer documentation is complete. If you are writing a library, the API, javadoc and sample usages in the SDK are all complete.
5. Code, Test and Developer Documentation is committed. Change management 101. Programmers share via source control. Typically it should be committed on a side branch, to be merged into main or master once the review is complete. The use of source control helps enforce discipline. It's obvious if the author changes the contents of the code up for review and helps prevent confusion for the reviewer.
6. All static analysis run and passing. The reviewer shouldn't be looking for stuff that static analysers should be finding. You should have run PMD, findbugs and/or sonarqube with all pre-agreed rule sets.

Once I have completed all six parts, I am ready to submit my code review to reviewers.

Supporting resources

Clean Code, Robert C. Martin
The art of readable code, Boswell and Foucher
Pragmatic Programmer, Hunt and Thomas
A Guide for Code Reviews
Code Review Matters and Manners
Peer Reviews in software, Karl Wiegers
What to look for in a code review, Trisha Gee

What makes a good check in?

Updated 04/01/2016

Updated 13/04/2017

Updated 23/09/2017

Happy new year 2017

Welcome to 2017! 2016 was a busy year. I spoke a little on programming, code review and a fair bit on teams, agile and communication.

2017 will continue the theme. I'll focus on production of software and more on pairing and code reviews. Looking forward to it!

Evil Two, Three and Four Letter Acronyms

I propose the following three rules for Three Letter Acronyms (TLA)

• Platinum rule: Don't use Three Letter Acronyms. Ever.


• Golden rule 1: Only use Three Letter Acronym's if they are well-known¹.


• Golden rule 2: Don't create new a Three Letter Acronym.

One of the things we must continue to do in software development is to promote understanding. Every 5 years the number of developers doubles, so half the software developers out there have less than 5 years experience.

In our industry², we have a huge love of Three Letter Acronyms. In fact we nearly have our own flavour of English in TLA's. And this is not surprising given the lack of typing skills during the early days of computing (that continues today!). It's a lot easier to repeatedly type TCP instead of Transmission Control Protocol. So we gain efficiency on the writing side of the communication equation.

However TLA's are a barrier for understanding for the reader. Especially for novice and intermediate reader. They are particularly evil when one needs context to understand them or when we create new ones that are local to the document being read. For example: in a telecommunications domain does IP stand for Internet Protocol or Implementation Proposal or Intellectual Property? If I load a module into a CD; is a CD a Control Device or Compact Disk?

Now consider that the reader may not be a fluent English speaker. Consider that the artefacts are written once, but read many times. Shouldn't we favour efficiency of understanding for the reader, instead of the writer?

So to promote better communication I propose the above three rules for software development teams to follow. Let me repeat that first one again. Never use Three Letter Acronyms! Use regular words.

---

1. Definition of "well known": If I pop the Three Letter Acronym into google and it comes up in the first 5 results.
2. We are not the only industry guilty of this.

---

Edited 20th February, 2017

Code Reviews 2 - Dysfunctional Code Reviews

We've all had them; code reviews that just aren't effective. Here are a few scenarios.

I would love to hear your feedback about other types of reviews you have encountered.

As a submitter:

The '0' feedback code review

You eagerly prepare your code, a few methods and a few new tests. Submit it to the guild. Appoint the master code reviewers. The reviewers give it a +2 a minute later, with no feedback what so ever. WFT... surely there has to be something wrong with it?

The "Trivial" details code review

You submit your code to the review board. After a wait, the results come in. The reviewer wants the variables and methods in alphabetic order. They insist on putting in all the full stops on the comments. They are making it a blocker that you don't know the difference between "it's" and "its". They point out you are missing capitalisation in your javadocs. You haven't expanded three letter acronyms on their first use…

The "goes on forever" code review

We submit out code for review. A few days later, the first set of reviewers find numerous "serious" issues. We address all the comments. It goes out for review again. The following week, the next set of reviewers find another set of serious issues. We address all those and our code goes out again. Another week goes by and next set of comments back highlight another, different set of "serious" issues. We address those and the code goes out to the reviewers again. The next set of comments back and highlighting some of the same stuff as the first review, that the third code review made you put in…

The "Self" review

You are using a code review tool because the organisation process requires you to use one. However your team has no real interest in each others work. When you make changes, you put them up for review. But you always push through your own code anyway.

As a reviewer:

The "token" code review

It's 16:40 on Friday. The sprint ends in 15 mins. Bam! Into your mail box, comes a review for a critical feature for this sprint. The change set is long, several classes with a few hundred lines of code. Just remember it has to be in the main branch by 16:45… and that includes any re-work! It only takes a fraction of a second to hit that +1 button and the weekend is yours!

The guy who is always right review

The author is never wrong. How can you criticise this guy? Their code is flawless. Always. Even when you spot a real issue, they won't listen to you. They'll justify the unnecessary, out of scope code in the solution with fancy subjective words like "extensible" and "future-proofing". Some sections of the code might be unreadable to you, but that’s only because you are a lesser programmer and we'll save several nano-seconds during execution because he used an obscure construct. Basically this code is right. You are wrong.

The guy who is always wrong review

This guy just doesn't get it. The solution proposed isn't just a little bit wrong, it's completely wrong. There are no tests whatsoever. There is no concept of the agreed style guide, he just copied a large chunk of code from anther part of the system - changed a few strings and it's the proposed solution?

The death by a 1000 updates' review

So you get the call for a code review into your inbox. You gallantly volunteer to take it on and you fire up the tool. You spend 40 minutes reviewing the problem statement, then the tests and pick your way through the solution adding your comments as you go. Next thing you check the tool and there is an update to the commit. Many of your comments are now null and void due to the changes submitted. No panic. You start picking your way through the new solution again. Thirty minutes later, in pops another set of significant changes, rendering many of your comments null and void... again! So you start the review... again!

The "rutting" code review

A senior developer has submitted their code for review. Another senior developer has taken up the challenge. These two never see eye to eye. The comments come thick and fast with slightly confrontational and inappropriate language. It's a thinly veiled "you are an idiot"! The gauntlet has been thrown down. The submitter is not going to take that sort of "threat" lying down and they respond in kind, in the tool. The insults and accusations go back and forth for all to see in plain text. The tension rises. Other reviewers fall away, afraid of getting caught in the cross fire. Sooner or later either one declares the other one is wrong or Godwins' law will apply! At this point someone else will step in, merge the code and promises to keep these two apart in future!

---

Updated 23rd September, 2016 Updated 3rd July, 2017

Cycle time and Delivery frequency

Delivery Frequency

Delivery Frequency is the count of the number of times we ship the product out of the team to a receiving organisation. That could be a test group or a "friendly" customer or another interested stakeholder.

Generally we favour higher delivery frequencies. The optimum number depends on our delivery infrastructure. This can vary greatly across products. But at a guideline, we are looking to ship more than once per day. On products with long build and test cycles, this can be a challenge. Why this is important:

1. It's easier to integrate smaller changes, more frequently.
2. We get earlier regression feedback on our changes.
3. It can help reduce "traffic jams" at the end of sprint.

Cycle Time

Cycle time is defined as the length of time a story is actually being worked on. The clock starts once the story leaves status "open" and it stops once the story is marked "closed". Usually this is when the story is delivered out of the team. Why lower cycle time is important:

1. We get an earlier demo to the product owner.
2. Better chance of delivering something in the sprint.
3. There is the possibility of more agility from the team. We can change new work planned before the stories are started.
4. Small stories are easier to implement, are easier to integrate into the system and they are easier to regression test.

Relationship of Cycle time to Delivery Frequency

There is a coupling of Cycle Time to Delivery Frequency that is interesting, and observing the trends in both can be indicators on how the team is performing.

Cycle Time	Delivery Frequency	What it means
Low or trending down	High or trending up	Team is heading towards high performing
Low or trending down	Low or trending down	Team not delivering despite closing stories. Need to investigate why?
High or trending up	High or trending up	Team is frequently delivering "undone" work - need to investigate why? Are stories correctly split?
High or trending up	Low or trending down	Team might be struggling. We need to engage the team to discover the difficulties and challenges they are facing.

Code Reviews 1 - Why?

I'd like this to be part of a series of articles on code reviews. Comments and suggestions welcome. There are as many views and opinions about code reviews, as there are developers. These are my views. I hope they make logical sense. They have been formed through my own experience.

Why do we do code reviews?

There are primarily two reasons why we engage in code reviews. Both are equally important.

Code Quality Checkpoint

For any "product", a review should be part of the production process - this goes from a set of accounts to a presentation. Reviewing one's work is a great practice for any craftsman to part-take in. There are two quality aspects that code reviews can help with.

Code Quality

How can I know that the software I have written is "good"?

Code is written once. Code is read many times. Frequent code reviews help me to write great code.

Code reviews help to have a good code base in the product. A "good" code base is one that is readable by a majority of programmers, without too much intervention by the Author. This has been expressed as the number of WTF per minute. We can ensure any style standards are consistently met.

Product/Component Quality

Code reviews are the also important for finding any possible bugs or errors in the solution we have put together. Since code reviews occur early in the production lifecycle, they are one of the cheapest ways of detecting and preventing issues.

Knowledge Transfer

Code reviews are a medium of communication between developers.

When we start out, we share our work with our more experienced peers so that we can learn. As we get wiser, we share our work with our peers to get their validation that we are doing the right thing. When we are at the top of our game, so to speak, with many years of experience we also take an active part in reviews to help pass on our experience and to get exposure to possible newer ways to do things that more recently trained developers will have learned.

Risks, Assumptions, Issues and Dependencies (RAID)

This post is about a tool that is useful to have when doing Release Planning.

During Sprint or Release Planning it is useful to capture any Risks, Assumptions, Issues and Dependencies that we identify during the planning, that might impact the successful execution of the plan. A RAID diagram is useful for this.

Setup 4 flipcharts on the wall, where the team can capture Risks, Assumptions, Issues and Dependencies.

Risk

A risk is something that might happen. Should it happen it will have an adverse impact on the success of our project. Risks should be discussed openly by the team. We need to evaluate how likely they are to happen and what mitigation actions should we put in place to avoid or to counter them.

Here is some good advice for managing risk

Examples: There is a transport strike looming for the next number of weeks, so it will be difficult for people to get to the office. Peter is doing maintenance on an other high priority project; he might get pulled on a regular basis from this project if there are issues for the customer.

Assumption

An assumption is something that we think is true or likely to be true and we rely on it being true to successfully delivery our project. Assumptions should be tested as early as possible during the execution of the plan.

Examples: To cause least disruption, 21:30 is when we think we have least number of users on line so it's the best time to upgrade our system daily.

Issue

An issue is something that is causing us a significant problem today and prevents us from succeeding in our project. The main difference between Issues and Risks, is that Issues are a certainty today. Issues need to be dealt with all the time. It's important that an owner is identified and a strategy for dealing with the issue is agreed. Can we resolve the issue ourselves? Do we need outside help? Can we avoid the issue altogether?

Examples Issues: We have scalability problem after 10, 000 connections to the database. Mary, the principle tester, is going on 2 months extended leave for July and August.

Dependency

Something that must be delivered before we deliver our project. Dependencies must be managed and monitored. How are we going to make progress while we wait for this dependency? If dependencies run late, how will that effect our delivery? Can we minimise that impact?

For example: We are using a beta version of our platform for development, and it's due to be officially released 6 weeks before we go live.

Team Building Exercise: Tennis darts game

This game is a fun game to promote team communication. Good introduction to new team mates.

This is one of a series of simple and fun team games to help team forming.

Team:

4-8 people

Aim:

to score the hightest number of points by landing the bean bag inside the scoring zone.

Equipment:

1. Spray paint
2. Tennis racket
3. 6-8 mini Bean bags ( or a balls that won't bounce)

Course:

1. Draw out a large circular target on a large area. 4m-10m in diameter.
2. Draw some smaller circles inside the large one. At least 5.
3. Mark out a base approx 15m from the target zone.

Scoring:

1. Smallest circle in the middle gets 200 points
2. Next circle gets 15
3. Next circle gets 12
4. Next circle gets 9
5. next circle gets 5
6. Outside that the score is 0.

alternative scoring: Use hula hoops placed on the ground, further away hoops get more points

Instructions:

1. Allow one practice bat per team member.
2. Each person takes the racket with one bean bag.
3. They stand inside the base.
4. They launch the bean bag towards the target on the ground, using the tennis racket.
5. Repeat for the next 5 bean bags.
6. Add up the scores of where the 6 bean bags landed to give the team score.

Team Building Exercise: Risky Bowling

A great game for team building, it promotes communication around risk. Do team members keep it safe and score for every roll. Or do they go for broke and try and maximise their scores, at the risk of scoring nothing.

This is one of a series of simple and fun team games to help team forming.

Aim of game:

To score the highest points score by rolling a ball to a stop between the lines on a lane. The highest scoring zone is furthest away & the smallest zone. Be careful not to over judge the distance, as this score will be 0!

Team:

2-6

Equipment:

• Level flat surface
• Coloured tape
• 10m+ roll of carpet, 1m wide
• Bowling balls or large tennis balls
• Measuring tape

Course:

• Lay out the carpet.
• Mark off an area after 3m, 5m, 7.5m, 8.5m, 9.25m, 10m

Scoring:

1. 0-3m Zone 1 - 1 points
2. 3-5m Zone 2 - 3 points
3. 5-7.5m Zone 3 - 5 points
4. 8.5-9.25m Zone 4 - 8 points
5. 9.25 - 10m Zone 5 - 30 points
6. 10m+ Zone 6 - 0 points

Instructions:

1. Allow one or more practice rolls per team member.
2. From behind the start line, roll the ball along the carpet.
3. Where the ball rests is the individual score.
4. Repeat & add up all the scores for the team score.

Team Building Exercise: Gutter Ball Challenge

A great game for whole team interaction. Promotes teamwork, communication and lateral thinking to achieve the goal as fast as possible

This is one of a series of simple and fun team games to help team forming.

Aim: To transport as many balls from one bucket to another using gutters

Team: 4-6 people

Equipment:

1. 2 buckets
2. 5 x 1 - 1.5 meter lengths of PVC guttering. To make game harder, use down pipes
3. 100 tennis balls (bucket of tennis balls)
4. Stopwatch

Scoring:

• 3 minutes after the clock starts.
• 1 point per ball.
• 200 points if all 50 balls are transported successfully

Course:

Place the bucket of balls in a space.
Place the empty bucket approx 5-20m away. (Further away, game more difficult). (10M)

Instructions:

1. Allow one or more practice runs per team member.
2. Start the clock.
3. One person stands at the bucket of balls. They cannot leave the bucket and are the only one who can handle tennis balls.
4. The remaining players take a gutter each and line up between the two empty buckets. They should stand so that end of each gutter touches in a line.
5. Persons who hold a gutter can only move or walk when there is no ball(s) in their gutter.
6. Person at the bucket, places one ball on the first gutter.
7. The first person passes the ball, via tilting the gutter towards the next gutter.
8. Once the ball is passed the first gutter, the first person runs to the end of the line.
9. Once you reach the destination bucket, deposit the ball into the bucket using the gutter. All return to the start.
10. Continue until time is up or all balls are transferred.
11. Count the number of balls transferred.

Penalty

Should the person with a ball(s) in their gutter walk or run, the ball is deducted from the total.
If a ball falls, it is lost and cannot be picked up again.

Hint:

You can try to transfer more than one ball at a time. You may have more than one line at a time. However let the teams figure this out themselves.

---

Updated 13/12/2018; spelling mistakes corrected