We agree to document our design and review the design with at least two people prior to implementation.

• The working agreement promoted inefficiency because it required too many people to engage.
• The working agreement permitted passive engagement--they asked someone to be a reviewer and that person indicted interest but did not actively engage.
• We need time to learn (or prototype) so their is something of substance to review.
• A difference of opinion on when to start applying the working agreement.

• I am happy if the conversation on how to approach the design occurs and all three people actively engage in the decision.
• Passivity is a form of passive aggressiveness that I won't tolerate--engage or choose not to engage but make a decision.
• Absolutely, take the time to learn but ensure that the interaction of all three people acknowledges and understands the objective and intended outcome of this learning.
• Start the interaction at the same time we start working on the story.

The team put together a working agreement for design. It requires two design reviewers and the author to engage and determine the extent of the design.

I see design as an important component of implementation. It promotes knowledge transfer and better solutions.

I think this agreement should be applied to every implementation undertaken by the team. A single line of code qualifies as an implementation. It’s my perspective on the line of code that ruffles feathers.

Why is a line of code important? Because the intent of the working agreement is to ensure a few team members think about the implementation before any code is written.

I value the opportunity for people to engage on an idea and develop it. The agreement doesn’t dictate a requirement for the design. It requires agreement on the extent of the design.

The team used examples from Leslie Lamport’s talk Thinking for Programmers to develop the working agreement.

Thinking for Programmers says the degree of specification of a program should reflect the complexity and subtlety of what you are trying to achieve. A design might be a couple of lines of prose.

One argument put forth by a team member opposed this approach is that it’s too heavy. It will slow things down. That’s right–their argument was that a discussion whose duration should reflect the complexity of the thing being programmed is too expensive to undertake so we shouldn’t do it.

The argument isn’t against design or the design output. It can’t be. It’s against the required interaction. Since it’s against the required interaction either the interaction is unhealthy or the people making the argument don’t want to interact.

Is there any other way to see this?

In Working Agreements for Agile Teams (Part 3), I discuss how working agreements should be principles. Good working agreements are principles and that reasonable people can construct arguments on when and when not to apply them. I’ve run into a couple of problems with this approach.

In each case, experienced people asserted their experience by choosing not to perform a design. And they got into trouble. What’s interesting is that our working agreement on design is focused on an interaction between the author and two reviewers. The intent is to ensure knowledge sharing and to build some level of consensus that the right problem is being solved.

In the cases where these people got it wrong they failed to consider alternative designs or they failed to consider what other team members considered a valuable opportunity for knowledge transfer. It wasn’t a question of whether a design was created it. It was about the communication that would have resulted had they carried out the agreement.

The interesting part is the failure to understand the importance of the interaction and the communication element. This confounds me.

Using a git submodule produces this message from within the submodule repository.

The Jekyll repository has new commits.

Using git status from within the parent repository.

Remedy: from within the parent repository execute.

git add jekyll
git commit -m "jekyll update"

Tool Chain:

• git version 2.9.3

References

• Git Submodules: Adding, Using, Removing, Updating
• Git submodules: Specify a branch/tag

In Review Board RBTools Example I developed a simple client using RBTools. Here I explore another approach using the URI templates provided by Review Board’s Web API.

The Review Board Web API embeds a lot of functionality. It enables client development, the documentation describes how to ensure forward compatibility and legacy APIs are managed. It’s a nice piece of documentation for a rich API.

The entire API can be obtained using the Root Resource List. This resource insulates clients from URI changes. The URI Templates identify how to obtain specific resources. To obtain a resource published by the API use the URI template for that resource and fill in the variables.

For example, to obtain a diff in a review request use the URI template for a diff 1.

https://reviews.reviewboard.org/api/review-requests/{review_request_id}/diffs/{diff_revision}/

Obtain the URI, review_request_id and diff_revision as follows:

Although crude, this client uses the Web API in a forward compatible manner. It also provides insight on the relationship between the URI templates and the values to populate to access a resource. A good next step might be to develop a discovery mechanism using the URI templates and the linked resources so that tools can be created using the Web API.