Tuesday, September 18, 2012

I want it all, but don't change my connectors

People just don't like change.  Case in point, all the hubbub over the new iPhone 5 lightening adapter plug.  So many people are upset that the connector is changing from the 9 year old iPod 30 pin adaptor to the new lightning adaptor.  Yet at the same time the iPhone 5 pre-orders have record sells (2 million in first 24 hrs).

Why did Apple force this change on it's loyal customer base?  Dont they know we humans don't adapt well to changes.  Oh yes, we want the new shinny iPhone but we want it to stay the same AND get better.

Maybe this picture will give you a clue as to why Apple changed the connector. It shows a typical iPhone and it's 30 pin connector, with a Raspberry Pi.  The Raspberry Pi is a full fledged computer on a board.  Take a look at the board and the most obvious thing is all the connectors.  The interface connections are the largest things.  They occupy the most space.

Raspberry Pi & iPhone compared
The reason for the change?  So that Apple could pack more techy goodness into the same volume, and have a platform for future techno stuff.  They miniaturized almost every internal component of the iPhone (the complete redesign).  Hey - that is innovation.  And I have to believe there will be room for new components (like the Near Field Communication radio) when that eco-system is ready for consumer devices.

Saturday, September 8, 2012

Best T-shirt at Agile 2012

What was your favorite T-shirt seen at the Agile 2012 conference?

One awesome t-shirt was seen on Adam Yuret @AdamYuret.

Ninja + Rockstar != Teamwork.
Ninja + Rockstar != Teamwork tshirt
In his article the Myth of the Rockstar Programmer, Scott Hanselman lays out these definitions:
  • Junior Engineer - Creates complex solutions to simple problems.
  • Engineer - Creates simple solutions to simple problems.
  • Senior Engineer - Creates simple solutions to complex problems.
  • Rockstar Engineer - Makes complex problems disappear.
Speaking of t-shirts; his graphic would go very well on a t-shirt wouldn't it?  Well, I created one very similar a few months ago.   Obviously there is an I in TEAM! t-shirt - buy one now on Zazzle.
Buy it on Zazzle - NOW!

This is the best t-shirt give away I received, the Tasty Cupcakes Got Game? t-shirt.





Tuesday, September 4, 2012

Exercise:: Pair Chess Game


Some years ago I designed this exercise for a Pair Programming simulation using the media of the game of chess.  The idea was to have a pair on each side of the board, they would work together to finish a famous game against their opponents (a pair also).

I never used the exercise because the developers I was working with didn't know the game of chess, and didn't seem interested in the simulation.   If you use this please let me know how it works out.




Garry Kasparov (White) vs X3D Fritz Computer (Black)
Man-Machine World Chess Championship 2003
Game 1 (after 31 ... Bxa2)
White to move





Instructor material for Chess Game Pairing Exercise

Required Materials

Chess board and pieces (one per 4 students)
Timers (optional)
Diagram of an in-progress chess game(s) (attached)

Introduce the Exercise

Pair programming is generally thought of as an XP (extreme programming) practice.  In true Agile form we are borrowing a practice that has value to use in our process.  Pair programming is when two (or sometimes more) developers work on a task simultaneously at the same computer.

This exercise is designed to give you the feel of pair programming. You will pair up with another person and become a chess playing savant team!  Each team will be pitted against another team to solve a world class chess problem.  Setup the chess board in the exact position described on the problem sheet.  Then playing as a pair (perhaps with limitations – see variations below).

The Exercise – Part One: Setup the board 

Instruct the students to retrieve a chess set and the sheet describing the chess problem.

Their task is to setup the chess board as diagrammed.  

Exercise – Part Two:  Let the games begin!

The instructor can give limitations or not, constraints, rules, etc.
Then they are to begin – White moves first! 

Variations
  • Only allow the pair that is in play to talk, the pair not moving must stay silent.
  • No talking and strict turn taking for first 5 moves, then instructor announces that communication and cooperation may take place for the rest of the moves.
  • One minute time limit per move.
  • Pair beginners with experts – have the group self rate from 1 – 10.
Debrief the Exercise

The only reason to do an exercise is to get to the debrief stage.  This is where students will apply the simulation to the “real world” and learning will happen. Please give at least 20 minutes for the debriefing phase.

Facilitator will start the debriefing – ask open-ended questions such as:
  • What happened during the exercise?
  • What did you notice about the act of pairing in a traditionally solo activity?
  • Which activity was harder, more fun, required more concentration, stimulated creativity, produced more interesting results?
  • What do you like/dislike about pairing?
  • How did you decide to what moves to make – did you talk? Did you test out move?
  • Did you find that one partner lead and the other followed, did the lead change?
  • How does this simulation compare to the task of programming?
  • What lessons can you learn?
The debrief should take 10 – 30 minutes (if the students don’t have anything to discuss, then it was not very instructive).

Major points of the exercise:  

Pairing can be more fun, more creative.  Problem solving is creative and one person’s idea can spark better ideas in another person.  To effectively pair one must take turns, and communicate their ideas and intentions, they must actively involve the partner.




Bobby Fischer (white) vs Greenblatt Computer (black)
1977 Computer Match
White to move














See Also:

Globe Chess Board