July 25, 2015

Bottleneck, Where Art Thou?

  —Tools can create process bottlenecks in unexpected ways.

I've been reviewing the tools we use to help us develop software. Tools affect process and shape workflow. They colour how we view the work we do.  Some examples: Review Board provides support for identifying the reviewers of a patch. Bugzilla provides support for prioritizing tasks.

I identified our use of Bugzilla as an problem almost immediately. We use the priority field of a task to create a workflow. The highest priority tasks are tackled first. Unfortunately, Bugzilla doesn't manage priority as a list. It forces you to group tasks into a small number of priorities. As a result, multiple tasks can have the same priority.

The problem with multiple tasks having the same priority is that the software team, not the business ends up determining what to work on first. This is fine if the team is capable of arriving at the same decision as the business. If the team makes a mistake they produce less business value than they could have.

It took longer to identify Review Board as a tool that undermined our work flow. Peer review is a new process. To the team's credit, they embraced it and created a working agreement to ensure its use. Our agreement calls for a review of all code prior to committing it to production and for at least two people to participate in the review.

About six months after we deployed Review Board reviews began to bottleneck. The authors said they couldn't commit to production because the patches hadn't been reviewed. The reviewers said they were too busy to complete the reviews. The drop in commits to production occurred because code reviews stopped. The team was committed to reviews but a bottleneck developed.

In effect, the reviewers had been asked to review the patch, had agreed to do so, but didn't have the time to follow through. The authors identified the reviewers in Review Board and accepted that they would eventually get the promised review. I ultimately concluded that the team's commitment to performing reviews coupled with the working agreement created the problem.

We treated the decision to review a patch as final and never went back to revisit it. This was eye opening. Two positive behaviours: commitment and peer review conspired against us because we accepted that identifying reviewers ahead of the review as sufficient.

What I learned about Bugzilla is that it's a poor task management system. Using Bugzilla the way we use it encourages a form of lazy prioritization--no one in the decision process was forced to decide what task to do first and so the grouping of tasks is what became important. Bugzilla appears designed to encourage this. This loss of advantage manifests itself whenever there are multiple high priority tasks.

With Review Board I discovered that the act of identifying the reviewers before the review created a form of paralysis within the team. Our focus on commitment and delivery made us blind to the fact that we needed to be more agile in our decision making.

Bugzilla made me want a product and sprint backlog. [1] It's great for tracking issues but not in the manner we use it. Review Board reminded me that agility can come in many different forms and a lack of agility can create bottlenecks whose root causes can be surprising.

[1] I am aware of ScrumBugz and the Mozilla hosted version at ScrumBu.gs. I haven't investigated it.

2018-06-06:

The scrumbu.gs website is offline. The link to this site has been removed.

July 19, 2015

The Cost of a Cup of Coffee

  —A negative remark on promotions involving credit card applications.

I walked into my local coffee shop the other day. I was greeted by someone offering me two free cups of coffee (or tea) if I was willing to sign up for their credit card promotion. I was surprised how this made me feel.

I can respect the desire to extend a business through the use of an in-store promotion. It’s not exploitation. It’s just good business. My local supermarket does the same thing. They have a different credit card and coupled their promotion with chocolate chip cookies.

Coffee, tea or chocolate chip cookies in exchange for filling out a credit application and the privilege of being able to carry a credit card with that merchant’s branding embossed on it. Who benefits from this? More importantly, what’s in this for me?

This is an excellent deal for the institution holding the credit card contract and likely a good deal for the merchant. Credit card interest rates have a 18-20% annual percentage rate. At 18%, $100 translates into $18 per year for the financial institution holding the credit card contract, assuming there aren’t any fees associated with the credit card.

At my local coffee shop, $100 allows me to purchase over 52 cups of coffee annually—54 if you include the two free cups for filling in the application. At one cup of coffee each day interest payments would exceed $100 annually.

What benefit does this bring me? For consumers, debt is a means of using anticipated income and future purchasing power in the present before earning it. Of course, this credit card is usable with other merchants, so my local coffee shop or grocery store benefits whenever this credit card is used. And that is brilliant business.

So how did this make me feel? It disappointed me. I was at my local coffee shop to purchase a cup of coffee. Not to entertain the opportunity to become part of another revenue stream in their business. I was disappointed because I foolishly thought this business and I already had beneficial relationship and now they were asking if I was interested in taking a bet on my anticipated income to help grow their business model.

You’d think the additional revenue available through my credit card is worth more than two cups of coffee. Apparently not. That brought new perspective to the relationship.

This brilliant idea for creating a new revenue stream effectively made me rethink my relationship with this merchant. All of their consumer marketing went to waste the moment they asked me if I was interested in filling in their credit card application. That request put all of their previous marketing into perspective for me. It's really about the bottom line.

My local coffee shop isn’t what it wants me to believe it is. It wants me to believe that it's a familiar place where I can meet friends. In fact, it’s a business in a competitive environment and I am just participant in an income stream. That is disappointing. It’s a testament to the effectiveness of their marketing.

Their risk in developing this new income stream? Virtually nil.

Their risk in using their existing customer base? Again, virtually nil. Ok, at least one blog entry.

June 26, 2015

Finally, Something Sensible On Testing

  —A look at the fundamentals of testing.

A friend provided a link to a Kode Vicious article from ACM Queue (April 2015) by George Neville-Neil. If you haven't read anything by George you should.

The second comment in April's column covers testing. In a few sentences (ok, two pages) the fundamentals of testing are covered. It's an excellent summary including a strategy and requirements that every test regime needs.

Every test regime must have relevance and repeatability. To be relevant, tests must confirm the software works and attempt to break it. For repeatability, you must maintain complete control over the environment in which the tests are run.

To ensure repeatability in a complex system the control interface and test interface must be distinct. I liken the notion of control to a scientific control in an experiment. Scientific experiments are are carefully constructed events that seek new information. The same attention to detail and results is needed to construct a test and its environment. An example in the column shows how to do this.

I like the article because of its directness. George's explanations are short, concise and simple enough to share with your colleagues if improving your tests are on your mind.

June 20, 2015

Royalty Wazer!

  —I am royalty.

A testament to how much driving I do...

Wazer Scoreboard

June 6, 2015

Wifi MAC address of my Sonos Connect?

  —Making my Sonos work because of MAC address changes in the Play:1 and Play:5 devices.

It looks like Sonos has two sets of rules for determining the wireless MAC address of their devices. I own a Play:1 and Play:5.

My Play:5 has a wired MAC address beginning with B8:E9. Wifi MAC address of my Sonos Connect?" describes how to obtain the wireless MAC address for the Connect. It works for the Play:5 as well.

These instructions say the wireless MAC address = wired MAC address + 1. The wired MAC address is on the label affixed to the bottom of this device.

My Play:1 has a MAC address beginning with 5C:AA. The wireless MAC address is the same MAC address on the label on this device. (No +1 required.)

Sonos customer support indicated that 5C:AA is a new set of MAC addresses for their devices and the wireless MAC address for my Play:1 as reported through my diagnostic submission to them conforms to the description in "Wifi MAC address of my Sonos Connect?".

Sonos customer support was very helpful throughout this. 

I was able to establish the correct wireless MAC address for my new device through some experimentation with my wireless network.  I wanted to point out that "Wifi MAC address of my Sonos Connect? worked for my older device but not the new device.


Note:

Link to "Wifi MAC address of my Sonos Connect?" was updated to reflect its new location on the Sonos Community website.