Playing a board game with my wife while at the hospital

Posted by steve | Board Games | Sunday 26 January 2014 5:59 pm

I had to take Melissa to the ER Thursday evening and she was admitted to the hospital later that same evening. She’s having pretty severe GI problems and we’ve been here since then and it’s currently Sunday evening.

However we had a pleasant break and managed to play a board game while here. Even though she’s heavily medicated she still won. I blogged about it on my board games blog site.


An iOS tutorial on writing unit tests with Xcode 5

Posted by steve | Apple Software and Hardware | Friday 24 January 2014 2:59 pm

I recently took a few moments and cobbled together a “workflow” tutorial that shows how to use Xcode 5 to write Unit Tests. Apple has done an excellent job in integrating Unit Testing into their iOS and Mac developer IDE. I wanted to write an introductory tutorial that walks through how you write these kinds of tests with this environment.

Here is the new tutorial.

I’ll probably push out updates with typo corrections and maybe some added goodies over the next few days.


Pair Programming Anecdote

Posted by steve | Management & Leadership | Wednesday 22 January 2014 8:41 am

Update: I just realized that Martin didn’t write the original Blog post I reference here. I found it because of tweet he posted. Sorry about that Martin.

This morning I read a Blog post from Martin Fowler, an individual I admire very much professionally. I don’t know much else about his non-professional life except that I know he also loves modern board game designs too. Anywhere here is a link to his post where he contrasts his experiences with Pair Programming teams and Code Review oriented teams.

As many who know me professionally, I’m also an advocate for what Pair Programming can do when it’s done well — having worked in a Pair Programming environment for a 10+ year stretch recently. Because of that experience I have also seen where it brought no value. Like anything else, there’s no simple pill or solution to what is required to be successful, and often you need to by dynamic about your processes because things change. And also vigilant. I’m reminded of Rebecca Wirfs-Brock‘s presentation at OOPSLA years ago where she posted a bumper sticker “Shift Happens”.

My reason for my own post this morning, after reading what Martin wrote, is that I was reminded of an anecdote from back when I used to manage a Frameworks Development team. The company was a substantial software development shop with maybe 500+ developers on site. This was back in the late ’90s. I was introducing the team to the concepts of eXtreme Programming and Agile development concepts such as code refactoring. In fact I purchased copies of Martin’s book on refactoring and had passed them out to all of my team members. We went through the book, reviewing a chapter per week. We also talked about Pair Programming. At the time the overall development shop was anything but agile. There were senior managers so focused on the tactical, seemingly “by-the-minute” costs, that discussion about putting two very expensive ($100K+) programmers together on a single development workstation was a daunting prospect. But I discussed it openly with my team and wanted us to try it out in small “doses” to see how it would work.

One of the senior developers, having been there for easily more than 20 years, totally surprised me by saying “Oh, we do Pair Programming here already sometimes. When the code HAS TO BE RIGHT.” He described a familiar scenario of a team finding a serious defect in the eleventh hour before a software freeze. It was not uncommon that two, often very senior, developers would look over each other’s shoulders as a code fix was made to ensure there was no risk of introducing other problems. When it had to be right, they paired on the code.

I get it. It addressed the problem by providing one of the benefits of Pair Programming: on-the-spot code review by a capable peer. And for that brief period of time no one questioned the cost because everyone implicitly understood the cost of failure was higher.

There’s a lot to think about from that experience.

I want to provide another reference link. This is to a Blog Post from another old friend and code-warrior, Blaine Buxton. He and I worked together several times in our careers, over a span of easily 15 years, and I’m sure the respect is mutual. He wrote an insightful post about the things that can go wrong when Pair Programming is not the answer. I know exactly what he’s talking about, having worked with him on the same team where he experienced the challenges described. Here’s Blaine’s post.