Archive

Author Archive

Agile 2009 Wrap-up

August 27, 2009 Comments off

The conference is pretty much wrapped up. The banquet and keynote put the finishing touches on a wonderful week of learning, collaboration, and meeting people who share the same passion for how to create awesome software.

In the coming weeks I’ll be posting about the things I’ve learned and how we can make our company better. I need some time to absorb how all of the different sessions tie into each other. It didn’t seem to matter if the session was about UI, project management, distributed teams, or coaching – everything kept coming back in some subtle way to the Agile Manifesto.

Once my subconscious has some time to mull this over and make sense of it, I’ll post. I’m going to do it just in time because as they say in Lean, JIT happens.

By: Ryan Shuya

Advertisements

Google Calendar Timezone Widget

August 5, 2009 1 comment

I like to keep organized and make sure everyone is on the same page. With Agile 2009 just around the corner, I decided to put my flights into Google Calendar so my wife would know when I’m arriving and leaving. This will be handy for getting a ride home upon my return.

As I started putting the times in the calendar, I realized that the itinerary probably showed times local to the airports, not to my current location. I confirmed this with Dustin (who is also attending Agile 2009), and we both decided that a timezone calculation gizmo would be awesome. We checked out Labs, and there was a World Clock feature. We enabled it and it showed the current time for the timezones we were interested in.

Current Time

“That’s nice”, thought Dustin and I, “but wouldn’t it be great if that widget showed the times for an event…” We clicked on an event, and the widget did the calculations and showed us the times for each timezone for that event.

Event Time

Using this tool it was pretty easy to figure out the times to enter in my local timezone and make sure that I wasn’t an hour too late or too early.

By: Ryan Shuya

Logic and Emotion

April 8, 2009 1 comment

Star TrekOver the last year I’ve learned a lot about people and business. I’ve observed that there are two basic types of interaction – those that involve logic and those that involve emotion. These interactions are applied to people and business on a daily basis, but they are generally applied in the wrong ways.

Logic can be described as a system of reasoning. When asking questions such as “which server platform should we choose, Windows or Linux”, you can weigh data points against other data points and use reason to come to a conclusion about which platform is best for you.

Emotion can be described as a mental or physiological state associated with a variety of feelings or thoughts. In essence, our moods. Emotion does not follow any system of reasoning – it just exists. There is no reason for me to be annoyed by people walking by my desk. Sometimes it just rubs me the wrong way. (I’m not really annoyed; it’s just an example.)

Now that we have defined logic and emotion, let’s look at how they are applied incorrectly.

HR managers sometimes need to tell people that they are not performing adequately. Imagine how you would feel if you were hauled into your boss’ office and told that you needed to pull up your socks. Your boss presents the logical side of your performance problems (being late, introducing bugs, etc). Your boss then logically presents a plan, metrics, and alternatives for this behaviour. Everything is cold and calculated because the boss thinks that you are logical and you can not possibly disagree with the facts.

But people are emotional. Maybe you’re late because your spouse is sick and you had to take the kids to school. Maybe you ran out of jam for your toast. Maybe your kid keeps turning off your alarm clock. On top of your home/commute/extracurricular frustrations you’re nervous about being called into the boss’s office, and now you’re angry and defensive that you don’t get to explain.

But imagine the difference if you have a great boss and emotion is applied to this situation. The boss tries to understand why you are late. The boss empathizes with your situation and realizes that the kids will grow out of the turn-off-the-alarm-clock phase. You both have a shared understanding and there is actually no problem. You say “I’ll check the clock before I go to bed”. The boss doesn’t need to prescribe a solution.

Now let’s look at the business portion of … business. People can have strong emotional attachments to things like product lines or brands. An example –  there is a need for servers, but do you choose Windows or Linux? Ideally you would identify required features, the pros and cons of each platform, and come up with a formula of some sort to weigh the options. In reality you get people who are emotionally attached to one or the other and they debate based on their attachment. “Windows sucks because the kernel isn’t separated from the UI.” “Linux sucks because it has no drivers.” Or whatever. This is not the situation to make a decision based on emotion. You need to analyze the facts because you can’t properly make decisions any other way. What you end up with is one party capitulating –  “Whatever, use Linux” just so you can move on and get something done.

Have you noticed this? Do you agree or not?

By: Ryan Shuya

Why Pairing is Better

April 4, 2009 Comments off

My wife and I plan our finances each month. We look at how much we spent in the previous month and why, and we project what we will spend in the upcoming month. It’s pretty lo-fi: A 20 column ledger and a spreadsheet. The ledger is always lying out and open so we can write in it as soon as we get home.

The spreadsheet is for calculations and planning. At regular intervals we sit down together, Wendy and I armed with our favorite tools. She relays the numbers from the ledger and I enter them into the spreadsheet. Wendy is focused on reading and relaying the numbers while I am focused on data entry. Once the numbers are in we quickly double-check just to be sure. The process takes less than 5 minutes for 40 – 60 entries.

This time Wendy did the data entry on her own. I asked how last month looked and she said “We spent a lot on groceries”. I happen to like eating so it’s not a big deal that we overspent, but it’s still nice to know why it happened. There is always a reasonable explanation. Meat is a major portion of the bill, and maybe we bought too many bags of frozen peas. Or maybe there is a mistake in the data.

Had we paired during the data entry we would have been assured that the entry was in fact correct and we could begin a meaningful analysis of our overspend. I am now forced to look back through the data in the ledger and ensure that it has been entered correctly. This will take more time because I will be switching tasks many times:

  1. Find the entry in the ledger
  2. Remember the value of the entry
  3. Move eyes from paper to spreadsheet
  4. Scan to find the corresponding entry in the spreadsheet
  5. Recall the value of the entry
  6. Verify the values

Compare these steps with those that I would do when pairing:

  1. Translate what Wendy said
  2. Verify that the value she relayed is correct in the spreadsheet

Yep, only 2 steps. I don’t have to keep switching focus from paper to monitor, nor must I remember any values. I just verify that the value she gave me is the value in the spreadsheet.

When I sat down to verify our numbers, the realization that pairing is much more effective (and arguably more efficient) hit me like a ton of spaghetti code. When you are working on complex tasks you are forced to make switches between contexts – the problem and the solution details. In my example the problem is incorrectly entered data, and the details are moving my eyes from paper to screen, then remembering and verifying values. When writing code the problem is the bug/story you are playing, and the details are language syntax, editor shortcuts, etc.

Now to the point. Imagine that you could offload one of the contexts and fully focus on the other. Wendy can focus on the problem (relaying the numbers) and I can focus on the details (data entry). When writing code the navigator is focused on the problem (satisfying acceptance criteria and design) while the driver is focused on technical details (syntax, shortcuts, stubs, tests…). It stands to reason that pairing prevents mistakes due to context switching, thus solving problems more thoroughly and with fewer mistakes.

P.S. – I asked Wendy to pair with me on the verification. Next time I won’t be so lazy and I’ll help her do the data entry in the first place 🙂

By: Ryan Shuya

Categories: Point2 - Technical Tags: , , ,