Category: Uncategorized

[This article was originally posted on Global Nerdy.]

Yesterday, TSOT engaged in a company-wide exercise which was supposed to teach us about teamwork and blitz planning. In the process, we got a couple of lessons that could be applied to the process of building software.

The Assignment

The people participating in the exercise were divided into three teams of four people. The assignment was to build a bridge across which a ball about the size and weight of a plum could be rolled.

The specs for the bridge were:

• It had to be free-standing; we were not allowed to secure it to anything
• It had to have a minimum span of 4 feet (about 1.2 metres)
• While travelling across the bridge, the ball’s minimum height off the ground cannot be less than 2 feet (about .6 metres)

The items with which each team was allowed to construct the bridge were:

• 8 sheets of easel pad paper (each sheet is about 36″ by 24″)
• 4 plastic beer cups
• 4 thick paper plates
• 1 roll of masking tape

We were given ten minutes to come up with a construction plan and twenty minutes to construct the bridge. We were given a stack of 3″ by 5″ index cards for writing out our plan. Each team had to pick a team leader, who would direct the activities and make notes of the plan on the card.

The Outcome

I’ll cut to the chase: the team I was on, Team 2, won.

Not only did we build a bridge that met all the criteria, but we finished its construction in 10 minutes and had enough time to hang out in the lounge while the other teams kept working. Here’s the bridge that our team built:

Our team’s bridge.

Another team, Team 1, took all the allotted time. Their bridge met the “freestanding” and “4 foot span” criteria, but didn’t meet the “ball must be 2 feet off the ground throughout its travel across the bridge” criterion. Here’s the bridge they built:

Team 1’s bridge.

The last team, Team 3, weren’t able to complete their bridge in time.

The Design

The bridge we built, viewed from another angle.

The span of the bridge was made with 4 sheets of easel paper: 2 rolls, each one a 2-ply roll of paper, which were then joined together with a one-foot overlap in the middle for extra strength. The design was unconventional, but there wasn’t any rule that the bridge couldn’t be a covered bridge.

The pillars of the bridge were each made with a 2-ply roll of easel paper, with a plastic beer cup at the top and base. For extra stability, we attached one paper plate to the bottom of one pillar and two paper plates to the bottom of the other pillar. This gave the span a slight slope to ensure that the ball would travel from one end of the bridge to the other (there was no requirement that it had to be a two-way bridge).

The span design was my idea, so I was assigned to build it with the assistance of the team leader. The other two members designed and built the pillars. The pillars were mostly identical, so the guys building them consulted with each other throughout the building process.

Although we were given scissors, our design didn’t require any cutting. I’m certain that this cut down on the construction time significantly.

The Lessons

Our bridge, viewed from one end.

The exercise demonstrated the expected points about teamwork (a good leader, clear communication between team members and cooperation) and blitz planning (a simple plan, an iterative approach and adapting to real-world feedback). It also yielded some unexpected lessons about design:

• Build the simplest thing that could possibly work. It’s an oft-repeated mantra in Agile Development, but it’s something that programmers sometimes forget — probably because we often erroneously equate “simple” with “stupid”.
• Go with the strengths of the material you’re given. The other teams built structures that took their inspiration from real-world bridges. This might be a good approach if the materials we were given were popsicle sticks, but since we were working with mostly paper and specific height and span requirements, we decided that a tubular design would be the best approach. It offered the advantages of strength and ease of construction.
• The corollary from the previous point is that the solution may look different from what you might expect. With the two previous points and the time constraints in mind, explore the possibilities.

Although the exercise is now over, we’re keeping our bridge around as a little reminder of the design lessons we learned — we plan to use them in building our software.

The toy companies Hasbro (who own the rights to Scrabble in the U.S. and Canada) and Mattel (who own the rights to Scrabble for everywhere else in the world) have asked Facebook to remove the “Scrabulous” application as it infringes on their copyright for the game.

Mathew Ingram has already said this but I’ll say it again: Mattel and Hasbro are making a mistake by giving in to the knee-jerk impulse to think “infringement!” and calling in the legal team. All that will do is generate ill will towards them. A far more profitable approach would be for them to simply buy the application from its creators — which they could easily do for a few hundred thousand dollars, mere pin money to them — and use it as a marketing tool for Scrabble as well as other games in their stable.

[This article was cross-posted to Global Nerdy.]

Here’s a photo that recent appeared in the blog Consumerist. I had to borrow the title as well; it was perfect and couldn’t be improved upon:

Click the photo to see the original article.

According to Consumerist, the photo was taken on January 10th at a Wal-Mart in Albany, New York.

I guess the moral of the story here is to choose your weapons carefully.

Animation courtesy of Miss Fipi Lele.

In the Simpsons episode titled The Canine Mutiny, Bart uses his newly-acquired credit card to buy presents for his family. One of the presents he gives to Marge is a frying pan with a radio built into the handle.

The problem with being a satirist in this day and age is that reality often leapfrogs you. Case in point: this “MP3 Ready” George Foreman Grill, with integrated amplifier and speakers:

[This article was cross-posted to Global Nerdy.]

We had a few too many chairs at the TSOT developer office. I’m not sure how something like that happens; in every other place where I’ve worked, the problem has been too few chairs. So we moved the chairs out of the office and into a U-Haul truck (and eventually into storage). A photo op ensued…

That’s Justin doing the “Tokyo Drift” thing, and Alex in the background.
Click the photo to see it on its Flickr page.

Justin and Alex, running the chairs to the U-Haul truck.
Click the photo to see it on its Flickr page.

Out little gentlemen’s club: Me, Nelson, Donovan and Jeff.
Click the photo to see it on its Flickr page.

It’s been exactly one week since we moved from TSOT’s temporary office to the permanent one on the 11th floor at 151 Bloor Street West. The new digs are pretty sweet, and I thought I’d post some photos showing the evolution of the space.

Here’s what the place looked like on December 7th. You can click the photo below to see the whole photoset on Flickr:

Click this photo to see the “TSOT December 7” photoset.

Here’s how things looked on December 20th and 21st. Once again, click the photo to see the whole photoset on Flickr:

Click this photo to see the “TSOT December 20 – 21” photoset.

And finally, here’s how things looked on “Moving-In Day”, January 3rd. Click the photo to see the whole photoset:

Click this photo to see the “TSOT January 3” photoset.

[This article was cross-posted to Global Nerdy.]