But get this, in the many teams and projects I’ve been on, the progression of realization always goes like this:

Standup is at 9.00am –> People can’t seem to get here on time for standup. It’s important, let’s all be more responsible –> (People still roll in right before standup) Why can’t people make it to standup on time? (And by on time we don’t mean running in right when it is happening) Should we change the time? What can we do? –> Standup is now at 9.30am –> (People still roll in right before standup) –> Standup is taking too long. We should keep our updates to only things that are relevant to the larger audience –> Now that we have the team split into functional teams, why don’t we have separate standups? –> (What people say at standup is still useless and irrelevant even in a smaller setting) –> Back to Square One.

The original manifesto of standups has been to follow 3 questions:

1. What did I accomplish yesterday?
2. What will I do today?
3. What obstacles are impeding my progress?

This might seem like reasonable and fairly relevant things to say. But as smart as we think we humans are, we really aren’t. And we trick ourselves into think that although this process has done good things for us thus far, it will continue doing the same. The main goal of standup is to disseminate important information amongst team members so they they know what the goals of each day should be. If we spend the first 15-30 minutes of the day rambling, what is the point of it?

Here’s a radical thought? What if we didn’t have standups? That would require people to talk to each other frequently, maybe also sit next to each other, and be more collaborative. It’s definitely harder in a larger team setting (i.e. > 10-15 people) but we should always reevaluate process when it ceases to benefit us and requires a lot of time and effort to upkeep.

– Edited Mar 10th 2013, 10.52pm

Please don’t get me wrong, I’m not saying that standups are entirely useless, but that if utilized in the right way it could be useful, but if it isn’t working out we should think about what other things we can do instead of following process for the sake of it.

If we were to simplify things considerably, there are 2 types of programmers; the ones who are really smart and the ones who aren’t. And unfortunately for the rest the world, there is more of the latter than the former. Though being smart is mostly innate, there are certain skills and habits that programmers can and should develop to make themselves more effective.

1. Keeping the big picture in mind, be it the architecture of the product that you’re building and how the different pieces fit together to form a holistic ecosystem. Knowing and understanding this can help you make decisions however small they might be, i.e. fixing one bug while causing a regression failure is NOT ok.
   
2. Stop and read your code.
3. Always be thorough. Do what you have to do to make sure you’ve covered all your bases. Sure QAs are much better at exploratory testing, but that does not excuse you from writing enough tests to cover as many scenarios as you can manage. Though of course, writing tests for the sake of coverage is a no-no. Think real hard before you add more code (See #2 above).
4. Be aware of trade-offs. One solution might not be clearly better than the other, and one person isn’t right all the time.
5. Above all, listen. The best software comes from well-oiled teams where two-way communication happens between developer and QA and product owner and project manager and customer.

I may not be the world’s greatest expert in Android development, or Rails, or the JVM etc, but I have excellent discipline in getting things done and learning from my mistakes.

The main difference is that a tech lead needs to spend time writing code. We can’t have them setting the technical direction of a project without knowing the code. If you find your tech lead being in more meetings than in front of a computer coding, run the other way.

<expanded version/>

I have a big problem when people appoint someone a Tech Lead but pile on Team Lead type responsibilities on them and leave no room for Tech Lead work. For example, sitting in meetings to come up with acceptance criteria for features, or communicating decisions from one team member to another, or better yet having meetings about “why have the resources underperformed, shit this is LATE”. (And I’m not saying that these responsibilities solely belong to one person, that is another topic of discussion altogether)

If you want to pile on those responsibilities on someone, please don’t call that person a Tech Lead because they are NOT providing technical leadership. A technical leader does exactly that, provide technical leadership. They keep the big picture of a project in mind, integration points, architecture, future maintainability and performance, how the code needs to evolve, mentor new members, and most importantly WRITE CODE. If they do not have time for that, then cease all peripheral activities until they do.

XmppConnectionListener connectionListener = new XmppConnectionListener(listener, this);
xmppConnection.addConnectionListener(connectionListener);

You have to remember to remove them manually. You would think that when you call the leave method in the MultiUserChat class, it would remove all listeners for you. Nope. It does however remove all participant listeners but seem to leave the connection listeners hanging.

Save a handle on the listeners that you create, and then remove them:

xmppConnection.removeConnectionListener(connectionListener);

Here’s a list of things you can do so that everything will go as smoothly wrong as possible:

1. Limit communication between teams to the ‘leads’. Don’t encourage each team member to learn how to collaborate with other teams without depending on their ‘lead’.
2. Allow each person to go off into a silo and develop something and declare that it is done without confirming that it is consumable by other teams.
3. Collaborate on API design? That’s absurd.
4. Make sure your team members don’t learn the domain and understand what they are building. This includes not talking to the business people (Refer to #1).
5. When actual communication is needed between teams and their leads aren’t around to facilitate the discussion, use a ticketing system as a starting point and direct all future communication there. Face-to-face conversations should be kept to a minimum because everything needs to be tracked and we can’t track real conversations.

I think teamwork has just been redefined. Sigh.

I made a rookie mistake a few days ago but thanks to a colleague of mine who smacked me on the hand, I had a chance to correct it. Consider the following model:

class Order < ActiveRecord::Base
  belongs_to :account
end

class Account < ActiveRecord::Base
  has_many :orders
end

If you are retrieving a group of accounts and accessing each of its orders, you would be encountering an N + 1 query problem. Meaning you would be firing 1 query to retrieve 1 account, and if that account has N orders, N + 1 queries would be executed.

accounts = Account.find(:all, :limit => 10)
 
accounts.each do |a|
  puts a.orders
end

ActiveRecord uses default_scope to avoid the N + 1 situation.

class Account < ActiveRecord::Base
  default_scope :include => :order
  has_many :orders
end

This will execute just 2 queries:

SELECT "accounts".* FROM "accounts" LIMIT 10
SELECT "orders".* FROM "orders" WHERE "orders"."account_id" IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

The :include option can be used in a named scope as well. Long running queries are bad (of course), especially when you are dealing with tens of thousands of records.

Lesson well learnt (and remembered). Thanks Blake.

I also want to be useful. I want to use my skills (whatever they might be) for the benefit of a life or two, and no, corporations don’t count.

In most cases, those two sides of me don’t mix very well because doing one might cause the neglect of the other. So in the last few months I’ve been searching for ideas on how to be pragmatic and useful at the same time. I haven’t thought of anything yet (not surprising) but I know that I should stretch the practical side of me this coming year.

As much as I prefer being comfortable, curve balls, come get me!

As a trainer, one of my responsibilities is to pair with the grads on my team as I would’ve done on any other project. However, things are not as straightforward as just pairing because it involves other sub-responsibilities as well, e.g. assessing their technical skill levels, figuring out their problem solving techniques, understanding how best they learn and adjusting my coaching responses to them accordingly. Of the two terms of TWU that I worked with, we had an average of 5 grad developers to a trainer. Ideally, I would like to have at least 3-4 days of pairing time per grad, broken into 2-day slots where the former would be a chance for me to assess where they are at and how to form a customized coaching plan for them and the latter for them to have a chance for them to work on the feedback they received from the first pairing session (if any) or get more out of pairing with someone with more experience since that really is one of the main goals in the first place.

At 4 days per grad and 5 grads per trainer, that works out to be 20 days in total. With only 6 weeks per term, that doesn’t allow room for edge cases or other work that will take away time from pairing (surprisingly enough, there are lots of it).

What I think would be preferable is to have a 3-1 grad/trainer ratio and a smaller number of grads per group. I don’t think piling on more trainers to the mix will improve the situation as more people means more overhead. I would like to hear other TWU trainers’ experiences related to this (apologies for this being very TW-specific) because circumstance seemed to have dictated that my 2 terms were (somewhat abnormally) large ones and I wished that things had been different.

    dependencies {
        test "org.codehaus.geb:geb-core:latest.release"
        test "org.codehaus.geb:geb-spock:latest.release"
        test "org.seleniumhq.selenium:selenium-chrome-driver:latest.release"
        test "org.seleniumhq.selenium:selenium-firefox-driver:latest.release"
        test "org.seleniumhq.selenium:selenium-ie-driver:latest.release"
        test "org.spockframework:spock-core:0.5-groovy-1.7"
    }

Every script we ran took about 30-45 secs to resolve dependencies before it did anything, which was quite ridiculous. So after some digging around, Ben and I found out that if we specified the version of the plugins we wanted, that would drastically reduce the time spent resolving those dependencies.

This configuration shaved off about 20-35 seconds from our build:

    dependencies {
        test "org.codehaus.geb:geb-core:0.6.0"
        test "org.codehaus.geb:geb-spock:0.6.0"
        test "org.seleniumhq.selenium:selenium-chrome-driver:2.4.0"
        test "org.seleniumhq.selenium:selenium-firefox-driver:2.4.0"
        test "org.seleniumhq.selenium:selenium-ie-driver:2.4.0"
        test "org.spockframework:spock-core:0.5-groovy-1.7"
    }

One way that Ben and I tried was to use Groovy’s metaClass to essentially mock out those methods that were called within the domain class events. For example, given the Contact domain class:

public class Contact {
    def beforeUpdate = {
        someLocalMethod()
    }
}

And the ContactControllerSpec:

public class ContactControllerSpec extends ControllerSpec {
    def "should update contact"() {
        given:
        def contacts = [new Contact(name: "John Smith", phone: "123456789")]
        mockDomain(Contact, contacts)
 
        when:
        controller.update()
 
        then:
        ...
    }
}

This test will throw an exception saying that it doesn’t recognize the call to

someLocalMethod

So we had to mock it out:

registerMetaClass(Contact)
Contact.metaClass.someLocalMethod = {}

The call to

registerMetaClass

ensures that any modifications you’ve made to the class gets cleaned up at the end of every test.

If someone else knows of a better way to do this, I’d would much appreciate some tips.