2009-06-29

Nuke your phone

A Hoffman box is an important tool for testing mobile apps. Does your app behave properly when it loses its network connection? What about when the connection is restored? What if it loses the connection while downloading data during a screen transition? What if the user cancels a transmit/receive action during a period of intermittent connectivity? Enumerate all the ways your app could break because of network connection problems, and use a Hoffman box to test your app on an actual phone.

"A Hoffman Box is an enclosure used to secure electrical and/or network equipment."[Wikepedia: Hoffman Box] I have three Hoffman boxes in my home: one in the basement where the main electric line enters the house; another one in the basement for the main feed to my apartment; and one inside my apartment, with individual circuits for each room. Hoffman is a company that makes these boxes. "Hoffman box" has become a generic term for these boxes, like Kleenex is often used as a generic term for tissue.


A Hoffman box

In the mobile apps industry, we have repurposed the Hoffman box. We use Hoffman boxes "to temporarily shield mobile devices from their carrier signals"[Wikepedia], helping us test the our apps and devices under adverse conditions. We don't use actual Hoffman-brand boxes--we apply the term Hoffman Box to any metallic enclosure that limits the device's ability to connect to the network. "Most industry Hoffman Boxes are modified faraday cages, built without an opposing electrical field running through them and often not grounded in any form."[Wikepedia]

Most of us don't have a spare Hoffman box that we can use for testing, but we do have an excellent substitute: the microwave oven in your kitchen. Your microwave oven is a box. Five sides of the box are shielded with metal, and the sixth side is shielded with a metal grid. Microwave transmission is blocked by the oven box so the oven doesn't cook you while you watch it cook your food. Thus your microwave oven is a Hoffman box.

Is the microwave oven an acceptable Hoffman box for testing mobile apps? The oven blasts your food with energy in the 2.45 GHz frequency band, so the oven's box shields against that frequency band. This table shows common frequency bands for the microwave oven, cellular networks, and WiFi networks:

Cellular
WiFi
Oven
850 MHz == 0.85 GHz


900 MHz == 0.90 GHz


1700 MHz == 1.7 GHz


1800 MHz == 1.8 GHz


1900 MHz == 1.9 GHz


2100 MHz == 2.1 GHz



2.4 GHz



2.45 GHz

5.0 GHz


I conducted some tests to see what happens to my phone inside a microwave oven. The test device is a first generation iPhone running on T-Mobile at 1.9 GHz [Wireless Advisor] and connected to a local WiFi network at 2.4 GHz.

For Test 1, I set the phone to Airplane Mode and I turn on the WiFi radio. The phone connects to my local WiFi network. I run Mobile Terminal and type ping kasperowski.com. The pings return to my phone in a few hundredths of a second. I place the phone upright in a plastic bowl in the microwave oven and shut the door. After a few seconds, ping reports No route to host, and the WiFi indicator goes dark. I remove the phone from the microwave oven. A few seconds later, the phone reconnects to the WiFi network and pings again return to the phone in hundredths of a second.


My microwave oven


Test 1: outside the oven, inside the oven, and outside the oven

For Test 2a, I unset Airplane Mode, and the phone reconnects to T-Mobile with an EDGE data connection. I turn off the WiFi radio. I ping kasperowski.com again, and the pings return in tenths of a second. I place the phone in the microwave oven and shut the door. After a few seconds, ping reports No route to host, the carrier indicator displays No Service, and the data network indicator goes dark. I remove the phone from the microwave oven. About a minute later, the phone reconnects to T-Mobile with an EDGE data connection. The next ping reports that it took about 71 seconds, and subsequent pings take tenths of a second.


Test 2a: outside the oven, inside the oven, and outside the oven

Test 2b is like test 2a, but the result is slightly different. When I place the phone in the microwave oven and shut the door, ping reports No route to host and the data network indicator goes dark, but the phone retains its GSM connection to T-Mobile.


Test 2b: outside the oven, inside the oven, and outside the oven

In all three tests, the phone lost its data connection when I placed it inside the microwave oven, and restored its data connection when I removed it from the oven. The microwave oven's box is designed to limit transmissions in the 2.45 GHz band, and I tested the 1.9 GHz and 2.4 GHz bands. For these frequency bands, the microwave oven is an excellent Hoffman box for testing mobile device connectivity.

Sources

2009-06-19

Ken Schwaber's Flaccid Scrum

Ken Schwaber presented "Flaccid Scrum--A New Pandemic?" last night at the Agile Bazaar. Ken's talk was a one hour overview of Scrum, with the point that if it's ScrumBut, then it's not Scrum. Scrum works because it exposes organizational impediments to success, not despite exposing impediments. Don't adapt Scrum to your organizations dysfunctions; correct them!

2009-06-01

Krausen is your friend

If you are a brewer, then krausen is your friend. I keep my brewing simple, without quantitative specific gravity measurements to inform me whether the beer has completed its fermentation or how much alcohol it contains. Instead, I count bubbles and watch krausen. After a week in the primary carboy, my active krausen is telling me that it's not yet time to rack to the secondary. This simplicity is relaxing.

2009-05-29

Learning Agile via Agile Games

Michael de la Maza presented "Learning Agile via Agile Games" at Wednesday night's Agile Boston meeting. We played some fun games that would have been impossible to win if they weren't fun and if we didn't communicate with each other face to face.

One of the games was a brief Planning Poker exercise. Michael's point was that one of the valuable outcomes of Planning Poker is the discussion among team members, surfacing previously unknown requirements, enabling team members to understand and agree on product goals and requirements.

One of Michael's themes is that delivering a successful software product is 80% about the people and only 20% about the technology. He referenced some interesting sources, including The Psychology of Emotions, Fellings, and Thoughts, by Mark Pettinelli (affiliate link), and Paul Ekman's work on microexpressions. Michael mentioned the field of positive psychology and the Zappos core values as a way to inject positive psychology into a business:
  • Deliver WOW Through Service
  • Embrace and Drive Change
  • Create Fun and A Little Weirdness
  • Be Adventurous, Creative, and Open-Minded
  • Pursue Growth and Learning
  • Build Open and Honest Relationships With Communication
  • Build a Positive Team and Family Spirit
  • Do More With Less
  • Be Passionate and Determined
  • Be Humble

2009-05-25

Acceptance criteria template

When is it Done? How do you know? Does your Product Owner agree? Does your customer agree?

When we estimate user story size and sprint task effort, we ask ourselves how we will know when a task or a story is done. We make a list of doneness tests, and we call them acceptance criteria. In the spirit of Mike Cohn's user story template, we use a simple but effective template to define our acceptance criteria:
We'll agree it's done when [testable present tense active voice predicate].
Here is an example:
We'll agree it's done when ...
  • A team member can localize the app to Mexican Spanish.
  • The app displays all menu items in Mexican Spanish, as specified in the localization file.
  • The app displays all messages and dialogs in Mexican Spanish, as specified in the localization file.
We review the acceptance criteria with our Product Owner and customer, and we all agree ahead of time on what it means to be Done. We avoid a lot of rework by agreeing on acceptance criteria before we commit to sprint tasks. We know our customer will accept our delivery because we tested against the acceptance criteria--the same acceptance criteria he will use to agree that we are Done.

2009-05-18

This is push

Simon Judge writes about mobile push and wonders what technologies are available beyond IMAP, Microsoft DirectPush, iPhone's upcoming Push Notification Service, BlackBerry's push service, and SMS. Simon might not have been aware that Java ME solved this problem a few years ago in MIDP 2.0. If you are interested in push-enabled mobile apps on Java devices, read all about it here:

2009-05-11

Story point inflation

My teams have begun estimating the size of product backlog items in story points. We estimate individual user stories and tasks in story points, we sum the individual estimates to give us the total amount of product backlog left, and we track product burndown in story points on a sprint-by-sprint basis. Tracking product burndown yields our sprint-by-sprint velocity, which we use to forecast our project done dates. At the micro level of each sprint, we continue to re-estimate user stories and tasks in man-hours of team effort, and we burn down the man-hours as we complete each task. As we gain more experience and confidence with story points, we may drop man-hours estimation and work entirely in story points.

We usually can't estimate the size of all the user stories up front, all at once. We want our meetings to be short--we'd rather spend our time building useful product--so we don't have enough time to estimate all the stories in one estimation meeting. We want to get started implementing the high value stories even though we haven't yet thoroughly estimated the lower value stories, so we begin the first sprint without having estimated everything up front. The product backlog changes over time, so there are always new stories to estimate after we get started. The team's understanding of the backlog deepens with each sprint, and they want to re-estimate stories that they previously estimated. All of these factors contribute to the reality that backlog estimation continues throughout the life of the project.

An unintended consequence of ongoing backlog estimation is story point inflation. Estimates for new stories are larger than for similar previously estimated stories, and previously estimated stories are re-estimated larger. Story A and Story B might be similar, but, after having completed Story A and learning that it was more difficult than they thought, the team estimates (or re-estimates) Story B larger. Are they sandbagging? Are they being honest? Are they conflating size and complexity, measured in story points, with effort, measured in man-hours?

Story point inflation is a problem. If you have estimated all the user stories in the product backlog, and if you haven't added any new stories, then the aggregate size of the product backlog shouldn't change--it is a constant. If you know your team's sprint-by-sprint velocity, then you can forecast your project done date. But if the size of the product backlog keeps growing due to re-estimation, then you have no way to gauge your team's true velocity, and no way to forecast your project done date.

In the future, we'll try to mitigate the problem of story point inflation by standardizing our size estimates for user stories. We'll post a table showing benchmark user stories and their estimated sizes across various projects, and we'll review all estimates against the benchmarks. This should help us avoid story point inflation. We'll have better, more stable estimates, a more accurate gauge of team velocity, and more accurate forecasts of our project done dates.

Related reading:
  • http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points and the comment http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points#comment-21036
  • http://jamesshore.com/Blog/Estimate-Inflation-A-Cautionary-Tale.html