Stone Age Productivity Improvement

Sometimes we spend more effort on presentation than on content, even when the real value is in the content, not in the presentation.

Some examples:

• Why spend time creating a PowerPoint slide deck for an informal discussion? Why not scribble notes on a page, scan the page to PDF, then annotate the hand-written PDF notes during the meeting?
  
• Why spend time transcribing a white board to a computer when a digital photo of the white board captures the arcs, arrows, angles, and phrases on the board, without wasting the effort to form those into a digital document?
  
• Why enter requirements into a computer system when the team is local? Use scraps of paper (3x5 cards work for me) and move them around on a table to prioritize and understand them
  
• Why not perform bug triage by rapidly moving pieces of paper around on a table instead of forcing everyone in the room to focus their attention on a screen where one and only one person can make progress?
  
• Why not have a face to face discussion or a phone call instead of composing an e-mail message?
  
• Why not talk about an issue instead of spending time to document it?
  

I listened to a programmer this morning noting that he was unable to find documentation on something. The thought that kept rolling around in my head while he said that was, "what you need documented does not exist, and the waste of creating documentation for all the things in order to not be missing that one thing was just not worth it".

Expressing My Priorities

We've had a set of tests failing on our continuous integration server for a week or more. That's a bad thing, since we tend to ignore continuous integration jobs which are not clean almost all the time. Continuous integration failures need to be infrequent and interspersed with extended periods of "clean", or at least need to be viewed as a trustworthy development information source. Otherwise, the team ignores the continuous integration server and it becomes another wasted and ignored feedback system.

The same tests work fine on the developer machine where we've run them (in a slightly different configuration). The "builder" attempts to diagnose the root cause of the failures have been unsuccessful.

I've scheduled a Monday brainstorming session with a larger group of people. We'll discuss what we know about the failures, what we know about matching successes, and then decide on a course of action.

A colleague asked why I was the one convening the meeting, instead of someone in the affected team. His logic was that several different people on the development team should have been intensely interesting in the root cause of the failure, and have "run it to ground".

I think there are several reasons why individual developers are not chasing this problem:

• The problem crosses boundaries (only visible from an installed version, only visible when other components installed, only visible from the continuous integration machine, etc.)
  
• There is no clear correlation between the first failure and a commit from a developer
  
• Installation related problems are more difficult and painful to diagnose. Setup and teardown time for the test is signficantly more than the setup and teardown time for most of our other automated tests
  
• Diagnosing this failure will reduce the energy available to work on other things, like new backlog items and new tests
  

I'm expressing my priorities by scheduling the meeting and bringing a group of people together to work on the problem. Since I'm a manager, my priorities have a little more weight, and I'm "throwing that weight around" a little for this case.

Eventually I'm confident others in the organization will recognize my focus on keeping the continuous integration servers "clean". Until then, I'll continue working with people to persuade them.

Microsoft Mesh - Synchronizing Files Between Computers

I work with many different computers between home and work and have found that Microsoft Live Mesh has been a nice addition to my computers. Mesh allows me to specify one or more directories which should be synchronized between all the various computers I'm using.

Thus far, I've used it to allow me to write performance reviews on any of my typical computers, knowing that the written results will be synchronized with my other computers so I can continue writing elsewhere.

I'm now attempting to use it to synchronize my "3x5" cards electronically. I usually carry a stack of 3x5 paper cards in my pocket for idea and task capture. When those cards need to live a little longer than they would normally sit in my pocket, I'm writing them to a file (in emacs "org mode") which let's me shuffle, stack and move them almost as easily as I can move them on a table. With that file synchronized between my various computers, I hope to lose fewer cards, and have a more clear idea of priorities at any computer I use.

Google Alerts - Monitoring Your Online Reputation

Google alerts delivers periodic search results to my e-mail box. I've been impressed at how it helps me detect new bloggers that might be worth reading, and helps me manage my own reputation.

I have several topical search terms that I use to watch for interesting new authors and sites. I currently have alerts set for "Association for Software Testing", "exploratory testing" and Debian Linux testing. I'll eventually add search terms for SharePoint 2010 and evidence based management.

I also have search terms which search for specific authors I've found interesting in the past. The search results on those authors have lead to other interesting writing on topics I follow.

I even search for my own name. I realize that is more than just a little vain, but it provides one way to monitor how others might perceive me. I use an exclusion term or two to avoid the writing of the journalist who shares my name and writes at a newspaper in Nevada. Someday I may add an exclusion term for the person who shares my name in Georgia.

Simplifying is Hard Work

One of our QA managers asked a very simple question yesterday that took me through a series of twists and turns trying to find a reasonable answer. It reminded me that seeking and finding solutions to problems is hard work, and finding a workable solution can be exhilarating.

The question was "How can a tester know if a specific fix is included in this build?"

The question hides contextual information like "source code is stored in git", "bug reports are stored in a customized Siebel database", "Siebel interface or API changes are not feasible", "testers are typically a long distance (geographically) from developers", "builds are accessible from a web page of hyperlinks" and "the recent builds page also has links to gitweb".

Challenges hidden in the question:

• No API connection between git and Siebel means we need to rely on people as the carriers of information, the "information transport"
  
• Time and space separation between developers and testers complicates communication, yet complicated forms or processes are more likely to be bypassed than simple ones
  
• Complicated user interfaces are more expensive to develop than simple ones, and complicated user interfaces tend to get less interest from users
  
• Persuading people to enter accurate data into forms, fields, or even free form text is difficult. It can be made much easier if they see immediate benefit from that entry, if the format is simple, and if the results of that data entry help them
  

My proposal to my colleagues (after an embarrassing amount of thought) was:

• When a developer fixes a bug, they paste the SHA1 hash of the fix into the bug report. The SHA1 hash is a unique identifier of that commit in git, so recording it in the bug report provides a "link" between the bug reporting system and git
  
• When a build runs, it records the short form of the "git log" for that build (the list of checkins which were in that build) with the identifiers (SHA1 hashes) of each checkin and the first line of the checkin comment
  
• When a tester verifies a bug, they first verify that the log file which came with the build contains the SHA1 hash from the bug report. If it does, then they perform the verification. If it doesn't, they don't waste time performing that verification
  

During the thought process before arriving at that idea, I wandered several different blind alleys, thinking of one complicated solution or another. For example, the early wrong or overly complicated ideas and questions included:

• Why do they need this data, don't the testers "trust" developers? The question is not about trust, it is about communicating intent, and preventing the wasted time associated with testing a specific fix, reporting it is not fixed, then being told "Oh, it wasn't in that build"
  
• How can we ask git to tell us which changes are in a build when there is no API connection between the build and the source repository? I envisioned complicated sequences trying to map a build date or time or version number or branch back to the git repository to generate the list of changes
  
• How do we connect the build (performed at some independent time) with the bug report (submitted at a different time on a different system) and the source master (yet another time and system)? Programs, links, pages, all came to mind as ways to make that connection, before I realized that the unique identifier of the commit is one of the few data items which might travel reliably between all those systems
  

Then again, looking at the idea now in the "cold light of a new day", maybe I was just too tired to think clearly.

Small Barriers == No Socialization

I was again reminded today that very small barriers can kill a conversation, or cause a contributor to stop contributing. I wanted to post a follow-up comment to David Chadwick's exploratory testing blog posting. I was on a different computer than I originally used to post the first comments.

Unfortunately, the IBM developerworks site is unfamiliar enough that I don't remember my password. I remember that it had a more restrictive password policy than other sites, so I was unable to apply my common password rules to their site. That made the site "unique" in a negative sense, something I had to remember outside my normal patterns of memorization.

The key point: I had a few minutes to contribute something to a conversation. I was not willing to spend more than a minute or two, including the time to login, post the comment, and verify the comment was posted. I abandoned the comment because:

• Restrictive password rules were outside my typical rule set
  
• Time was limited, I was unwilling to spend more time trying to login again
  
• Prior experience with the site made me distrust its use of my time
  

The relationship between a contributor and the forum to which they are contributing seems to be very fragile, at least for me. The newer I am to a forum, the more fragile the relationship. The less value I perceive from the forum, the more fragile the relationship. Even seemingly insignificant hurdles may be enough to stop a contribution and disengage a contributor.

Do Not Discard My Data

I just wasted 40 minutes trying to post a comment to an IBM developerworks blog posting from David Chadwick.

That wasted 40 minutes was a flawed attempt to describe the simple changes I think could be made to David's list of things which he believes exploratory testing is "not". I believe with relatively simple wording changes, I could modify each of his "not" descriptions to instead be descriptions of high value, useful exploratory tests. The wording changes are so small that I believe they hint David may not yet understand exploratory testing and how to apply it. However, this posting is not about exploratory testing, it is about a site that lost my data, twice.

My first comment was lost after 20 minutes of writing, thinking, and editing. The comment was lost because I clicked the "Add Comment" link, entered my comment, then pressed the "submit" button. The page which was returned politely informed me that my comment was rejected, and listed several possible reasons for the rejection. Unfortunately, IT DISCARDED MY DATA.

Don't discard my data! It frustrates me as a user and makes me unwilling to return to the site. If I must be logged in to submit a comment, force the login before accepting my input.

I registered on developerworks, logged in, and clicked the "add comment" link again. I added a short, dummy comment to assure that I was now able to add comments. I was able to add the comment.

I wrote a new response (I assume it was a little better than the first comment, since second drafts are commonly better than first drafts). After about 20 minutes of working on that response, I clicked the "submit" link. My comment was rejected again, with the same list of possible reasons for the rejection. Unfortunately, IT DISCARDED MY DATA AGAIN.

Don't discard my data! It makes me feel stupid, and then I need to remind myself that I'm not stupid, the software which should be working for me is instead making me do the work.

I assume the second failure was either due to my inserting URL's into the text, or due to the length of the text I was trying to post. I don't know which it is, and I'm frustrated enough with the developerworks site to not care which it is.

I gave up on trying to post a useful comment. I left a short note that my comments had been rejected twice, and if the author wanted my comments, he would need to send me e-mail.