This week’s release blog is brought to you by my colleague Cailie, who kindly agreed to be syndicated on my blog:

Thanks for inviting me to your blog, Owen. I love your choice of wallpaper…. it’s groovy man.

Before I begin – let me send a big congratulations to your Gramma on her 90th Birthday!!! :)

The big news on Monday was that we welcomed two new dev team members: an excellent Computer Science/Physics student on her first professional work experience, and a seasoned senior software architect hailing from the world of heavy traffic, high-profile web portals.

The last time new developers joined the team, we were in the midst of a crunch. We had to let them fend for themselves, and support each other, because we were all too busy getting the feature-set out on time. They ended up coping very well, and even managed to contribute significantly to the release. After the crunch, the team had a bit of a retrospective chat, and we all acknowledged that the new joinees were given relatively little support during their first few weeks. The two new developers shared their views on whether there had been a productivity gain or cost in handling their introduction this way.

One commented that in his efforts not to impede important development, he had gotten unnecessarily “stuck” on gotchas. He felt that a little more investment of knowledge transfer would have increased his productivity. However, he felt that it would have been inappropriate for a fully productive team member to spend time training when there were impending high-priority development targets. The other said that he had liked “getting thrown into the fire” because it had presented an opportunity to quickly get a sense of the big picture, and to learn how the team worked in a state of rapid development. We could see that there was no clear-cut answer to the question “how do we effectively introduce new developers”? So we conceded that new developers should pair with an experienced team member, to whatever extent possible, without affecting the path of critical development. There was a bit of shoulder shrugging as well, as if to say “it’s a tradeoff/balance.”

This week, however, the Product Manager suggested that our development theme be “JIRA Cleanup”. That is, bug fixes and small-magnitude features/tasks. In a startup, all development is important… but it was not a “crunch” week. So I paired with the co-op, and Owen paired with the senior guy.

Jeremy and I had talked before about the fact that the best task for a new team member is a vertical slice. That is, a task that spans across all software layers — from user interface, to business/domain layer, to data access layer, to database — but that involves as narrow a topical focus as possible. On Monday, I browsed through the “Unassigned” JIRA tasks scheduled for the week, and found a few issues that fit those criteria. I also noticed a critical-priority, and quick-to-fix, bug that would provide a rewarding introduction to the development process. I suggested these issues to her as appropriate starting points. In our team, we usually choose what tasks we want to do; the closest thing to assignment we have is nomination. So I explained to the co-op that I was just helping her select tasks for the first little bit; ultimately she would be choosing her own.

In Weekly Release Blog #5, he mentions the policy at IMVU that strives to have new joinees promote code that they wrote to production on their first day. This is not part of our policy, but I think it’s worth mentioning that the co-op’s first bug fix (the critical-priority quick-fix) was promoted to production on her second day! This was a JSP change that opened up some functionality that had become necessary for one of our customers. How gratifying, for one’s first check-in at a new job to truly matter – to provide immediate and tangible benefit to the customer.

As for senior guy, he and Owen flexed their fault-tolerant computing muscles this week. They troubleshot and corrected problems in the handling of data feed failures that had been exposed by outages occurring over the weekend and intermittently throughout the week. The experiences this week underscored the importance of ensuring completeness in the exception handling functionality and failure state test cases.

During the ramp up period this week, we seized the opportunity to audit and update our Wiki documentation. We are now firmly rooted in our Wiki habit — as with any healthy routine, it’s annoying at first, but now, we are reaping the benefits of our Wiki’s geometric growth. Taking time to keep those development environment setup pages fresh and accurate pays for itself again and again. The new team members this week played along and updated any discrepances they found as they worked through the steps.

Two recent process improvements helped reduce development environment configuration overhead — a script to create a development database (the script downloads a suitable subset of the production data), and a script to automatically configure the application server (Glassfish). The Glassfish configuration script not only saved time spent in configuration, but also time that would have been spent troubleshooting magical errors resulting from an accidental configuration mistep. The new guy added another improvement to the development environment configuration process. He thoughtfully committed the development environment SSH settings (tunnels, server names, etc.) to the SVN repository. It’s a sensible thing to do, but for some reason, we had been passing our settings from person to person. Now that it’s in subversion, changes to the network can be easily applied to all the development machines. Developers merely need to do an SVN update before starting their SSH session. Well, except for those of us connecting via putty.exe (ahem).