But What About the Actual University?

It's hard to believe, but we're already halfway done with our adventure to India, and through 27 updates I've yet to say much at all about what we're doing.

Note TWU is split between [roughly] 25 developers (devs), 10 quality analysts (QAs), and one business analyst (BA). Our trainers are from these backgrounds and more.

Week 1: All Together

We had a fairly normal 40-hour week to start things off. From 9-5 each day we had four sessions covering things that were common to all of our roles -- such as company history, diversity, software delivery model, and a micro-project with a simulated customer. Our customer needed an exotic animal built from LEGO^®. It was one of several sessions designed to get the devs, QAs, and BAs working together in a project-like setting. My biased opinion is our team came up with a pretty great animal, baby, and gated-enclosure.

We do a thing with sessions here called Open Spaces. Open Spaces are basically a blank timeslot where the sessions are proposed and led by the participants. Any number of concurrent sessions can be going, and there are four guiding principles that most every event would be better off to adhere to.

1. Whoever comes is the right people
2. Whenever it starts is the right time
3. Whatever happens is the only thing that could have
4. When it's over, it's over

One of our assignments before arriving in Bangalore was to take an existing project and make it better. I was curious to see the variety in solutions, so I proposed a session on walking through how we solved it. We had four presenters, including myself, who had approaches varying from elegantly simple to enterprise-caliber extensibility.

Week 2: Split

For the second week we split the teams in half. The developers were off to learn things about coding, whilst the analysts presumably had sessions tailored to analysis.

There was much debate before we got here over which language to use: Java or the powerful, syntactically beautiful and lovable Ruby. Ruby really is great. I'd highly encourage everyone, especially non-programmers, to give it a try at tryruby.org.

Eventually the call was made for Java. We had sessions ranging from setting up IntelliJ, a development environment that makes working with Java easier, to pair programming and practicing test-driven development.

The Open Space session I proposed for this week had far less traffic. In fact, only one trainer and I were interested in the topic of Behavior-Driven Development (BDD). BDD is essentially a way to describe tests for programs in plain English. That's really the beauty of this flexible time -- everyone can find something they're interested in. We went over examples of the BDD tool Cucumber for about an hour. I've just begun introducing this style of testing in the project I'm doing for my last semester of school. Certainly more on that project in the future.

Example Cucumber Test

Feature: Manage Stores
  In order to associate receipts with stores
  As a user
  I want to create and manage stores

  Scenario: Register new store
    Given I am on the new store page
    When I fill in "Name" with "Chipotle"
    And I press "Create"
    Then I should see "Chipotle"

Poorly-hidden subtext: I miss Chipotle a little bit.

Week 3: Project Begins

The most exciting part of University has definitely begun: we're going to spend four weeks working on an actual internal project for the company!

This is where we get to code actual functionality into a system. We're also getting to familiarize ourselves with all the cool tools ThoughtWorks Studios has released in the past few years. We use Go for Continuous Integration and Mingle for Project Management. Both of these tools, and the concepts behind them, have evolved out of the pain points of the old way of engineering software.

Integrating code is always a pain, but it's an absolute nightmare if you wait until the end of a project to start integrating the pieces that every developer has been working on. With continuous integration, we integrate dozens of times a day and our automated tests ensure everything is working correctly. The end result is a better product with more consistent and predictable delivery.

Mingle is tailored for agile projects. In agile development, we break up functionality into stories. We estimate the stories for difficulty with points and use those estimations to plan how much we will get done in an iteration. In our case, an iteration is one week -- this is quite important; we're never planning too far in advance because requirements tend to change. The number of points we actually complete in an iteration is called our velocity. Mingle makes it super easy to track velocity, deal with ever-changing requirements, and support an agile team.

Most of this week has been familiarizing ourselves with the existing codebase, tools, and getting more and more experience pairing with our peers.

Sushmitha and I after pairing on the first day of the project.

bonus Word on the street is I'm a pretty fun pair.