“Someone who was a lot smarter than me figured out that ‘blog’ stood for ‘Best Listings On Google’.” — Will Pate in his presentation, Guerrilla Marketing Tactics for Online Publishers.
The Invisible Computer Revolution
“If I had told you ten years ago that by the end of 2007 there would be an international network of wirelessly-connected computers throughout the developing world, you might well have said it wasn’t possible.
…it was created, and it continues to expand, not through Non-Governmental Organisations or charity or development grants but through the market, with much of it financed by some of the poorest people on the planet.
Lessons from a Paper Bridge
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:
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:
The last team, Team 3, weren’t able to complete their bridge in time.
The Design
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
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.
Steve Jobs Keynote Coverage
I wasn’t at the Steve Jobs keynote, but lots of other bloggers and journos were: see TechCrunch, Engadget, The Unofficial Apple Weblog, Tech Trader Daily, MacWorld, Big Tech and the TV-B-Gone guys.
This side-by-side comparison of Java and Python shows why I prefer working in languages like Python and Ruby: the “yak shaving” that Java requires drives me crazy.
I’ve been quite impressed by the “Addison-Wesley Professional Ruby” series of books (I’ve got The Ruby Way and RailsSpace) as well as the work of series editor Obie Fernandez, whom I had the pleasure of meeting at RailsConf 2006. That — along with glowing reviews for both books plus my serious immersion into Ruby and Rails at TSOT — is why I’ve got Design Patterns in Ruby and The Rails Way on order. I’m looking forward to getting my paws on these books, and I’ll post reviews shortly afterwards.
(I’m normally pretty conservative when it comes to spending on computer programming books for the past little while, but that’s because evangelism rather than programming has paid the rent. That situation has changed somewhat.)
Both Design Patterns in Ruby and The Rails Way are in Antonio Cangiano’s set of recommended Ruby and Rails books. If you’re looking to get into either Ruby or Rails (or if you’re already into either and just looking for related reading material), check out his list.