March 13, 2016

Review Board RBTools Example

  —Experiments with the Review Board web API.

I was experimenting with Review Board in an effort to extend RBTools. I was surprised by the lack of examples using the RBTools API.

I can't say that I'm pleased with my implementation but it works.

Sample output:

https://reviews.reviewboard.org/r/7763/
Diff: 14884
rbtools/commands/post.py
rbtools/commands/publish.py
Diff: 14887
rbtools/commands/post.py
rbtools/commands/publish.py

Produced by this code:

On GitHub: bminard/experimental/reviewboard/review_requests

March 7, 2016

Successful Tests Find Bugs

  —Worth remembering: successful tests find bugs.

The software team I work with has been challenging my notion of testing. Fundamentally, I approach testing from the perspective of the constantly dissatisfied. I am dissatisfied whenever a test doesn't produce a failure. Comments have been made that I should be satisfied with a successful test result. I beg to differ.

In my view, the purpose of testing is to find bugs. Thus a successful test is one that identifies a product deficiency relative to its stated requirements. If a test produces a successful result, great. It may be a valuable component of our regression tests but it hardly means we've been successful.

If we run a series of tests and have a series of successful results we are no longer getting value from that testing. We should re-evaluate the requirement and make a decision on whether we have exceeded the requirement or need to alter our testing.

The contrary position is also important: tests which exceed requirements are not valuable either. Except perhaps to delineate a boundary on the product's operation.

February 13, 2016

Your Very Own Pytest Decorators

  —How to create your own PyTest decorators.

I was exploring Pytest to discover a way to add a decorator to my test cases. I went with a solution using pytest_namespace().

In conftest.py:

1
2
3
4
5
6
7
8
9
def decorator(func):
def _decorator():
func()
return _decorator

def pytest_namespace():
return {
'decorator': decorator
}

A source file:
1
2
3
@pytest.decorator
def test_decorator():
pass

Simple.

Gist

January 15, 2016

Working Agreements for Agile Teams (Part 2)

  —Working agreements should be unambiguous principles.

In "Working Agreements for Agile Teams", I discuss how I prefer a working agreement to be unambiguous and not use descriptive language. One example, I provide:
We agree to use topic branches for development and merge our patches to the main line after completing unit testing and code reviews.
I pointed out that the use of "topic branch" as too descriptive but didn't provide any reason why I thought this.

In "Agile! The Good, the Hype and the Ugly", Bertrand Meyers provides an explanation of a principle. His explanation has three parts:
  • abstractness requires that a principle to be general rule and not a specific practice
  • falsifiability makes it possible for reasonable people to disagree with a principle
  • descriptiveness means it does not prescribe a behaviour.
My notion of a good working agreement fits the definition of a principle. For example, "use branches" is preferable to "use topic branches" because of its generality.  I can disagree with this agreement--do I really want the expense of a branch if I'm updating comments?

In my view a good working agreement is a principle. A quick look at Scrum Alliance shows that my thinking is not in line with many others:
Work agreements are the set of rules/disciplines/processes the team agrees to follow without fail to make themselves more efficient and successful. 
So is a working agreement a principle that reasonable people can disagree with or is it something to follow without fail?

Here is another opinion from Scrum Alliance that begs the question about the appropriate balance of interaction over process.
Scrum teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. To become self-organized, a team has to go through various stages of team development.
This article then goes on to list agreements for every Scrum Event.  How much prescription is too much?

Mike Cohn has something reasonable to say: Choose your rules wisely. ... Choose carefully.

I agree.

January 9, 2016

Giving Up More Than You Realize with Twitter (Part 2)

  —Social media as an instrument of ignominy.

In "Giving Up More Than You Realize with Twitter", I discussed how using Twitter can lead to privacy leaks through location sharing. There are other hazards awaiting those who share carelessly, and depending upon the circumstances those hazards can lead to life altering events.

The think-before-you-Tweet message in "How One Stupid Tweet Blew Up Justine Sacco’s Life" shows how random comments can create unwanted attention. Regardless of where you land in your evaluation of Sacco's Tweets the circumstances that motivated the New York Times article depict events where multiple lapses of judgement come into play to create and situation where everyone involved lost.

In another case of think-before-you-Tweet, "Why You Should Think Twice Before Shaming Anyone on Social Media" shows how a lapse in judgement can have negative consequences. It's difficult to see how the outcome that motivated the Wired article is justifiable on any level.

The New York Times article links Sacco's situation with public shaming and comments on the effect of public shaming written in 1787 by Benjamin Rush:
“Ignominy is universally acknowledged to be a worse punishment than death,” he wrote. “It would seem strange that ignominy should ever have been adopted as a milder punishment than death, did we not know that the human mind seldom arrives at truth upon any subject till it has first reached the extremity of error.”
We have to make mistakes before we can truly understand the truth of an error.

The Wired article manages to pull out the fine line between shaming and bullying. It points out that the bully is the one punching down and that the power differential can be an important component on how Tweets can be perceived. In fact:
Online shaming is a door that swings only one way: You may have the power to open it, but you don’t have the power to close it. And sometimes what rushes through that door can engulf you too.
The amplifying effect of social media adds a new dimension to online posts. The lack of context and the low cost of retaliation to any real or perceived slight brings incredible power.

For example, on the day I wrote this post, a woman Tweeted a comment about a remark that a random stranger made on her appearance. She has 420 follows. Her Tweet made it to @EverydaySexism who has 193K follows. (@EverydaySexism is referenced in the Wired article.)

I have an interpretation of this Tweet. It's a response to an unappreciated comment by a man. I perceive her response as sarcastic, something I infer from her choice of words. If I accept her comment at face value that's all I get from it. The responses to her tweet are informative in terms of the inferences others were able to make. I may simply lack imagination.

It's unclear what the intent was behind the initial Tweet. Perhaps shaming the anonymous man who commented on her appearance. If so, the response wasn't entirely supportive.  If she felt threatened then it's difficult to conclude that the ensuing online discussion was a victory.

Whatever the intent the parallels between what happened in the Wired and New York Time's articles and this woman's Tweet are similar: a random comment, amplified through social media which garnered substantial attention. The amplification creates a new context for the comment by virtue of who amplifies it.

The loss of control over who picks up a tweet (or any social media)  combined with their social context changes everything. In this case, a Tweet expressing dissatisfaction about a comment on appearance prompts  more negativity on this woman's appearance and personality.  The people making these comments are likely complete strangers.

The lesson, if there is one, is that once you publish something be prepared to loose control over it.

Other points of view.


Notes:

Martin Fowler's post is offline.