In Bottleneck, Where Art Thou, I discuss how our use of Review Board and Bugzilla conspired to produce bottlenecks. Blindly accepting the workflow imposed by tools can create poor outcomes. To improve our workflow the team moved to JIRA and Confluence with goal of abandoning Bugzilla. We evaluated Crucible but remained with Review Board.

Two months following the introduction of JIRA code reviews remain a bottleneck. Team members often position code reviews as something to do in addition to everything else they need to complete. Reviews piled up on individual to do lists just as before.

Well, almost like before. JIRA provides tools to manage workflow. We use the JIRA Agile simplified workflow: "To Do" progresses to "In Progress" then "Done". We use stories and tasks, so a bottleneck means that tasks stay "In Progress" longer.

A student suggested changing our workflow to address the code reviews. They suggested placing "In Review" between "In Progress" and "Done" much like in Every team needs kick-ass code reviews. Seems simple enough. [1]

Except workflows seldom get simpler as they age. They get bigger and complex.

Adding a state tells the team and I what we already know. It identifies tasks in the bottleneck. A state doesn't bring us closer to the solution. It may even deflect from a solution.  A better solution improves the timeliness of code reviews. A state doesn't improve timeliness. It draws attention to deficient time management.

A better solution enables better time management for tasks requiring code reviews. Our code reviews require that at least two people review a change. This means tasks involve three people: the author and two reviewers.

The default implementation of a JIRA task and the JIRA Agile simplified workflow has the potential to shape our workflow in a disadvantageous manner. A task in JIRA has a single owner. JIRA makes is very easy to add new states. There is a conflict between our workflow and the defaults provided by JIRA.

If you assume the team is committed to code reviews but struggles with execution ask why. Does a single task owner mean they are solely responsible for it? Does this place team members in competition for completing tasks? If competition exists, does this imply that team members are likely to complete their tasks before they help their peers?

If there is any truth to competition then a better solution is to change a JIRA task to include reviewers. Or introduce tasks for code review.

We went with multiple owners for tasks in the hope that this provided a greater sense commitment to tasks and allows team members to better coordinate their work. If not, we can always add a new state and watch the reviews pile up there.

[1] Another student had a similar idea. Their rationale for "In Review" was management might be interested in task status. Management isn't asking and we didn't have a compelling reason for adding "In Review" that helped the team.

In RBTLIB v0.3 Update (Part 1) I discussed some plans for posting review requests to a Review Board instance using RBTLIB. During the development I added a complexity measure to the project.  I was intrigued by how complexity measures were used in a talk by Sandi Metz.  Sandi's talk is on Ruby.  I'm using Python.

I found two Python modules: radon and xenon that compute cyclomatic complexity. Radon computes several measures and xenon provides a way to add complexity measures to a continuous integration.

To measure the entire project, including test code from the project's root directory:

radon cc -e "ven/*" -as .

The core abstraction in RBTLIB at this point is still the Composite design pattern.
This component has the highest complexity:

rbtlib/resource/composite.py
    M 41:4 Composite.href_component - B (6)
    M 63:4 Composite.component - B (6)
    C 31:0 Composite - A (4)
    M 53:4 Composite.list_component - A (4)
    M 34:4 Composite.__init__ - A (1)

From the radon documents:

M - Module
C - Class

A - low - simple block
B - low - well structured and stable block

Overall complexity of the project thus far:

72 blocks (classes, functions, methods) analyzed.
Average complexity: A (1.88888888889)

So far, complexity doesn't appear to be a problem.

In Code Matters, Bertrand Meyer discusses several flaws introduced as a result of poor language design. He cites examples from an Apple and OpenSSL security vulnerability announced in 2014. It’s a nice discussion on the importance of language design and how it affects implementation.

I found Meyer’s discussion on root cause analysis informative, particularly the example on how a combination of factors create situations that are difficult to detect. What makes Meyer’s discussion really valuable is his reference to Nancy Leveson.

Leveson’s home page contains a good collection of papers on safety in engineering. One paper investigates the Therac-25. The Therac-25 is a medical device containing software issues that massively overdosed six patients. The section on “Causal Factors” is informative.

One conclusion from Leveson’s paper is that focusing on particular bugs does not lead to safe design. The mistakes attributed to the Therac-25 involve poor software engineering practices and using software to ensure safe operation. You can’t patch your way out of a poor implementation and you shouldn’t involve software in safety critical functions.

Meyer’s point in his example is how combinations of factors can be difficult to detect and can result in catastrophic failure is made real in Leveson’s discussion of “Unrealistic Risk Assessment” in the Therac-25.

It also looks like a good lesson in probabilities. A probability of greater than zero means that the event can occur (however unlikely).

A look at race conditions in the Therac-25.

In RBTLIB - A Client-Side Library for Review Board, I introduced RBTLIB v0.1. I'm working on RBTLIB v0.3. A big change between the first and third revision is the introduction of classes for Review Board resources.

Why this change? RBTLIB v0.3 introduces support for operations using HTTP POST. These require the client to authenticate. This means managing user credentials and the introduction of session support for POST requests.

After some experimentation I discovered that it's possible to query a Review Board instance using the simple implementation up to RBTLIB v0.2. If your Review Board instance supports anonymous access you can write a simple client to query it.

That's important as the original use case for my project was a client to report on reviews entered during a fixed time period -- something that RBTLIB v0.2 does easily. RBTLIB v0.3 exceeds my original requirement and the implementation is more complex as a result.

One more note about RBTLIB v0.2: the resource links getter is set up so that you can't provide URL parameters to the Root resource. This prevents providing parameters to the Root resource in the event that the Review Board Web API is changed to support this.

How To Keep Your Best Programmers provides an interesting perspective on why talent stays (or leaves) an organization. It's worth a read, simply because of the wide perspective provided with the references.