h1

Day 0 and a new team

January 9, 2008

Next week is planning week. It’s fun because you get to hang out with people you haven’t had a chance to talk to, you get a good overview of the quarter that’s just gone by, and the high-level view of the quarter coming up. It is also fun for two other reasons.

Day 0 is like attending a technical conference for one day. You get to attend technical sessions conducted by your peers on stuff you probably don’t know, and if you do, you can still learn something new or help someone else out. This time around, there are enough sessions to use up 2 rooms in parallel for an entire day, and a third room for a good portion of the day. For the first time, I am involved in driving two of the sessions, one on Java Concurrency and the other on Scalability. They are both subjects on which I have actively worked on in the past few months.

Working with concurrent code is something that truly excites me. It is devilishly hard to write concurrent code and harder still to test reliably. Race conditions occur perennially and are often impossible to reproduce on demand. Detailed logs are the name of the game and one has to sift through them with a magnifying glass to identify and fix problems. Though I struggle just as much as the next dev, it really is one of the few times I feel at home. The session itself won’t (or at least shouldn’t) be focussing on the difficulty of debugging concurrent code. It should be a short presentation on some of the new tools available for concurrency in Java since Java 5, followed by a hands-on session where participants will solve a couple of simple exercises by using these new features.

Scalability is another beast altogether. On numerous occasions, it has left me a broken, defeated man by the time I finish working on a story or fixing a particular problem. Interestingly, while it is a problem solved everyday and everywhere (or how can enterprise and web applications flourish everywhere?) and most people spout all the buzzwords and theory related to scaling, I am yet to meet a developer who didn’t cave in to the enormity of the task during implementation. The problems start with getting a test-bed similar to the eventual production environment, scaling the application successfully and then testing out the deployment to reach meaningful numbers. If debugging a concurrent application is hard, debugging a scaled-out application is darn-near impossible. There are tools out there to help you scale, but finding the appropriate ones and making them work for you isn’t easy. I am happy that I acquired a lot more practical knowledge in a field where I only knew theory (and not a lot of it!). This session will therefore be a presentation on some tools and processes that we researched and/or used in scaling out our Java application. I expect a lot of discussion and debate from the attendees, or we may be in for a very short session.

Another fun part of planning week is finding out your new team for the next quarter. Regardless of how well your previous team gelled, it is exciting to know that one or more of your team can change and you get to learn from people you haven’t worked with before. One of the last discussions that usually happens at planning with the new team is the coding conventions that we agree to follow as a team. My personal preferences are:

  • Not to break up one line of code into multiple lines: makes it less readable to me
  • To include a space after every comma in the parameter list
  • To put the { character on the same line, eg. for {
  • To put a space in front of the {
  • To not put a space in front of the ( when declaring or invoking a method
  • To not use {} when its not needed:
             for (int i=0; i<20; i++)
                 if (i%2 == 0)
                     return i;
                 else
                     return i*-1;
  • To have spaces after the semicolons in the for-statement, but nowhere else inside the parentheses.
  • To have spaces either side of the comparison operator and any logical operators in the if-statement, but nowhere else inside the parentheses.

I am sure I could think of a few more, but these will suffice for now. They are always a bone for contention because everyone has their pet peeves. There are also quite a few people who have told me that we could have Subversion format the code to an agreed-on template while checking in and then have Eclipse format it to our tastes when we update the code. This way, all the checked-in code is in a uniform format but the developers can read it in the format they are most comfortable. Should probably try it some day.

Advertisements

5 comments

  1. Hm, I’m not sure about getting Subversion to format the code to one template and then have Eclipse re-format it when you update. Don’t get me wrong, my geek side likes it as a cool trinket to have working. But, given that a lot of the time is spent pairing, you’re almost guaranteed to always have one person complaining about formatting when they’re looking at someone else’s screen. I think everyone agreeing to a convention as you’re doing now, is more productive, and standards (e.g. Sun’s standard and Eclipse’s built-in default) tend to be less disputed and more accepted in my experience.

    As for changing teams, it is indeed an exciting change, and one of the biggest differences with new team members for me is how to estimate stories and tasks and calculate velocity – I’ve had holy-war debates about it as fearsome as code-convention debates! Which is why there’s a discussion about it on Day 0. 😉


  2. Bosh! Always use {} on if/else statements! Now I need a beer. See you in Glasgow and will harass you during at least the scalability session…maybe the concurrency session as well, now that I have my sanity back!


  3. Ha! And here I was, expecting you to shut anyone up who dared harass me 🙂


  4. Yannis, for some reason, your comment had gone into my spam!
    You are probably right about people complaining one way or the other while pairing. Hmm, for some reason, I am a lot more flexible on the estimation and calculation of velocity – I am willing to try out suggestions others might have.
    I definitely plan to be at that discussion, should make for good fireworks.


  5. does anyone want to be on team with me?



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: