Tuesday, November 23, 2010

Project 1 Lessons [Retrospective Lead]

Progress on our project hasn't quite been at the pace we would have preferred, though time has certainly flown by. In fact, our speed of feature development was one of the hot topics at this retrospective — the first retrospective lead by the fearless team of Chris and myself.


Briefly, a retrospective is a look back at the previous cycle of work. There are several methods to go about it, but we're always trying to answer certain questions:

  1. What went well?
  2. What didn't go well?
  3. What's puzzling?

We started our retro in the same fashion as any other: a thorough reading of the prime directive.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Concrete Implementation

After covering our progress on action items from the last retro, it was time to jump into reflecting on our newly-completed iteration. We chose the rather standard format of placing stickies on a whiteboard. Everyone had roughly seven minutes to put as many thoughts as they could capture into their respective categories.

Our retrospective process is fairly democratic. We first want to make sure all the thoughts are captured on the board. Second, we group those thoughts into broader topics. Finally, we give everyone three votes to spend anywhere they like.

  • one cannot vote against a topic
  • one may spend all three votes in the same place

Discussion generally revolves around the things we can improve. Our retrospective was no different. We dutifully captured input and action items for next time, as well as recording owners for those action items (with group consensus, of course!). Oh David Allen, where would we be without you?

Velocity Check

Sometimes it's necessary to devote time to specific areas of concern before they become problems. The final piece of our retrospective was a section devoted to velocity, or the pace our team is completing features.

On the suggestion of a teammate, the visual we chose for this was a boat. Very similar to the exercise that preceded it, thoughts of things that made us go faster were near the engine of the boat. Ideas for what exactly has been slowing us down were placed near the anchor.

Perhaps unsurprisingly, virtually all of what we discovered here was covered in some form or another during the previous portion of the retrospective.


All in all, it was a pretty successful retro for the team, as well as for Chris and I. We did a many things well and received some helpful feedback on areas to improve, namely:

  • Timebox discussions and activities
  • Minimize open-ended questions
Both points lead to the overall goal of having concise and effective retrospectives.

Project Fact Our iterations are two weeks long

Comedy Quote "No no, my vote was voting against!"

Sunday, November 21, 2010

Recycled Air: Episode 3 [Options]

The aircraft is often listed along with the flight when booking trips; this information meant almost nothing to me early on. Now that I've picked up a fair amount of aircraft knowledge, I've learned its importance -- each plane has benefits and drawbacks. Fear not, blogosphere, that knowledge transfer is about to begin (in alphabetical order!).

United Airlines Boeing 767-300United Airlines Boeing 767-300 by Deanster1983, on Flickr

Airbus A320

The only Airbus I've been on, and it just so happens I take it about 50% of the time between Chicago and LA. The A320 is a narrow-body, featuring three seats on each side of the aisle in the economy classes (3-3).

Exciting because the television monitors are flat screens that automatically open and close

Worrysome because overhead storage is lacking. Slowing down after landing has significantly more interior rattling than a 757 or 767.

Boeing 757

The 757 is a common plane along my standard 1,800 mile route. Like it's Airbus competitor above, this jet is also a 3-3 narrow-body.

Exciting because the overhead storage compartments fit a relatively large number of bags. I don't have to worry about checking a bag at the gate when this aircraft is sitting at the terminal.

Worrysome because the tube-television monitors are positioned in the middle of the aisle often, providing several reasons to duck while walking through the plane for taller folks.

Boeing 767

My favorite vehicle for medium-long distances. This wide-body aircraft is arranged with two aisles in 2-3-2 fashion.

Exciting because there are four aisle seats and two window seats -- six of the seven seats in a row are actually desirable.

Worrysome because the overhead bins sized a bit weird; they only fit a standard carry-on if placed sideways, cutting down on room. The seats between both aisles require standing up to turn off the blasting air vents.

CRJ 700

Exciting because the first time is a novel experience? If you're flying from Detroit with premier status (25,000 miles), getting upgraded is easy. The one time I took this regional jet we had 21 seats open, though that's more of an airport feature.

Worrysome because overhead storage is almost non-existent. I have a smaller-than-average carry-on that scraped on all sides when going into the overhead bin. This plane also seems easily thrown around in the wind.

Fun Fact My favorite way to get around is high-speed rail.

Wednesday, November 17, 2010

Hooray! TWU-Developed [Internal] Application Launches!

It feels like just last week I was headed to India for TWU XVIII. I remember being nervous for the flight and eager to start our internal project. The previous batch began development on our web application, which was built for chronicling the experiences of ThoughtWorkers all over the planet.

My batch took over in August and headed up another four weeks of development. The initial goal was to launch just before our departure. Ultimately the launch was pushed back and development work was handed off to the members of TWU XIX.

Today saw that application go live.

I'm extremely impressed with the work by the last batch. I'm extremely proud of these three new classes of ThoughtWorkers, and feel honored to have been a part of this project. To see something you've worked on go live is incredibly satisfying, to say the least.


I learned more than I can count on this internal project. To be effective, we had to dive in deep to the following technologies.

My favorite technical accomplishment on this project was implementing flash scope (as in Rails) in the Spring MVC framework. Prior to this implementation, we were passing around query strings for absolutely everything; that simply didn't feel appropriate.

It took a lot of learning on my part along the way to flash scope -- including how to implement a listener, filter, and Java annotation. The end result was a far better solution for the application and one that was reused several times in places where query strings just didn't make sense. I'm so very happy to have had the opportunity to push my knowledge and contribute to a delivered product.


So many people are to thank for this moment of accomplishment. Sumeet Moghe has put together a truly world-class training program. The real-world experience has helped me in immeasurable ways on my current project and is a far more effective way of learning than solving small problems from textbooks. Our trainers were wonderful as well, bringing their global experience into the classroom and project setting. I had the opportunity to work with young developers like myself from Australia, China, India, and the US.

Fun Fact query strings are attached to the address of a webpage. If an error were to appear on this blog with a query string, it would be shown in the address bar. e.g. -


Clarification The app is not public facing, which is why a link doesn't appear in the post.

Monday, November 15, 2010

Project 1 Lessons [Coding Katas]

A few weeks ago a colleague and I took to center stage as we launched another lunchtime activity for our project's crew.

There were a few differences from the lunch and learn initiative, not the least of which was the voluntary nature of attendance. We also wanted to engage the audience with a bit more than a presentation. Perhaps worth noting, each of these goals came after the superb interest generated from casual mentioning of coding katas by friend of the blog and resident Bearsharktopus fan Chris.

Bearsharktopus Projection

The Task

CodingKata.org is a great resource for programming problems that build skills. In our case, we were using the simplest suggested problem as a way to teach Test-Driven Design (TDD). FizzBuzz was proven to be a great way to illustrate this very important concept; certainly much easier than a 10-year-old codebase.

The FizzBuzz problem is apparently adapted from a drinking game and is a frequent cast member of programming interviews. There are just five requirements:

  1. Run through the numbers 1-100
  2. If the number is divisible by three, print "fizz"
  3. If the number is divisible by five, print "buzz"
  4. If the number is divisible by three and five, print "fizzbuzz"
  5. Otherwise print the number itself

The Demonstration

Our plan going in was to switch out pairs of programmers every five minutes. Being the truly agile adopters we are, we went with another approach that seemed to flow naturally with the event -- keyboard passing.

Chris and I began with the way all good programs begin: writing a test that fails. He first asserted that our result, given a number, would return a string. Then I made it pass and wrote another test.

Soon we had almost all of our client developers writing tests and making them pass. The approach won praise and has since been requested again by those involved. Katas will definitely be on the docket for any of my projects.

Fun Fact Bearsharktopus is an Internet meme

Fun Fact There is no right answer to FizzBuzz. An "enterprise" solution is hosted on Google Code.

Yikes! Moment FizzBuzz is apparently an easy way of weeding out 99.5% of those who apply for programming jobs. Source: Coding Horror

Wednesday, November 3, 2010

Project 1 Lessons: Part 1

It's amazing how fast weeks go by on a project.

It feels like just yesterday I found out I was headed to California for my first project. Suddenly a month has passed and we've cruised through one-and-a-half iterations. A few general lessons have been learned along the way that I'll surely be applying in the future.

Be Uniquely Identifiable

I made an attempt early on in the project to go by SG Hill. This was a new venture in person that didn't quite pan out for a number of reasons. The need for a name other than Steve was obvious and pressing. As is so often the case, I have a teammate named Steve. Ultimately the problem has been solved with the kind of class and style only software developers could pull off.

I'm now new Steve(); whilst my elder teammate has become known as Steve.Instance();

Learn Over Lunch

One of the great things about bringing together so many people of different backgrounds and experience levels is the knowledge transfer that could potentially happen. Getting it to actually happen requires some effort. Three weeks ago we made the effort to have lunch in the office one day a week for a little thing we're calling Lunch & Learn.

The response to L&L has been better than anticipated, and we've covered some varying topics so far over pizza and sandwiches.

  1. ASP.NET MVC - Testable software designs
  2. Feature Toggling (nToggle) - turning features of software on and off from a switch in the codebase
  3. Automated Functional Testing - Automated testing of web applications through a browser with Selenium

Perhaps the biggest benefit to giving these presentations over lunch is not the new ideas being shown, but the discussions generated around them from the questions being asked.

Quote of the Day as said in a Russian accent "Pizza without beer? This is...crime"