A blog on software development (with occasional bouts of Australia and sailing).

herding cats

2012.07.27

According to the GAO, US Federal Agencies spend $76 Billion bucks annually on IT so to reduce the risk of budget overruns and delivery delays Agile is now recommened by the OMB as the preferred development methodology. They've just released a freely available report on what practices have been effective, and what the challenges have been. These challenges tend to not get talked about so much so it's great to see this commentary.

Some of the biggest challenges identified were:

"Teams having difficulty collaborating closely": Getting the mix right with pair programming, as well as personality clashes when everyone is working so closely together, spring to mind as examples of where this comes up

"Self directed work" and "difficulty managing iterative requirements": Particularly when transitioning from a traditional project manager led approach. The Scrum Master is critical in fostering and shepherding this cultural change. Guidance around roles and responsibilities was also called out in this area.

Setting up technical environments.

Status and reporting tracking.

Bringing along the rest of the organization - e.g. procurement and compliance checking.

Very consistent with what I've experienced in both small and large organizations.

For any given project, it is cheaper to staff it with a smaller team of more expensive resources than a larger team of middle of the road resources.

It scales better - you get more productivity per head count, although Martin figures it as not being linear as I did, but more square root n due to greater communication overhead (I'd argue this impacts the larger teams more adversely, so the net effect still ends up being linear). He also choose a "betterness" factor of 2 as opposed to my 3, or Brooks' 5-10.

An additional advantage that Martin points out is that the smaller team, being more productive, can get to market more expediently:

They'll complete the
project in half of the time of the average team, which means that
the customer will start yielding value from the delivered software
earlier. This earlier value, compounded by the time value of
money, represents a financial gain for picking the talented team,
even thought their cost per output is the same.

The other point Martin makes that I really agree with is code base quality:

Faster cycle time leads to a better external product, but perhaps
the greatest contribution a talented team can make is to produce
software with greater internal quality. It strikes to me that the
productivity difference between a talented programmer and an average
programmer is probably less than the productivity difference
between a good code-base and an average code-base. Since talented
programmer tend to produce good code-bases, this implies that the
productivity advantages compound over time due to internal quality too.

There are a few problems to overcome before any of this becomes mainstream:

It is hard to find and attract really good performers. There is a very good chance they are already gainfully employed and probably being treated quite well, thank you very much. Unless your name is Google, it is hard to convince people to jump on board with a lesser known and smaller outfit.

Telling HR and your CFO that you want to pay your developers more than management can be a hard sell.

And finally, how do you assess an individual's productivity at interview time? A big salary expectation does not necessarily correlate with rock star level performance. Martin mentions that peer assessment is used at ThoughtWorks, consistent with what Joel says in his Guerrilla guide to interviewing.

The issues listed above make implementing something like this is very difficult. As a senior manager, you pretty much have to put your career on the line to get past item 2, and you can bet there will be a lot of eyeballs on your "high performance" team, making #3 critical to get right.

2007.11.30

The Caffeinated Coder posted an interesting item today about a psychology study that shows that less competent people are generally over confident about their abilities by around 50%. Giggles about management aside, I've seen this bear out in my experiences. The study showed that the only way to make incompetent people understand that they didn't know what they were talking about was to educate them about the domain. Only then, did they truly understand how foolish they sounded.

This reminds me of something I look out for when interviewing Java developers. I have made it my business to get down deep and dirty on the nuances of the Singleton. I believe it is important for developers to do some sort of coding during the interview process. Typically I will stub out a class for candidates and ask them to fill in the rest:

public class SingletonTest { // ... code goes here ...

public static void main(String[] args) { // Your task, should you choose to accept it, is to make this line of code work SingletonTest st = SingletonTest.getInstance(); }}

Most folks know the Singleton. If they don't then I will explain it, but will probably not hire them because not knowing the GoF Design Patterns is a candidate smell to me.

After they have filled it in, I will ask questions along the lines of:

Why is the constructor private, and not package or protected level access?

What are some of the alternative ways of initializing the single instance?

Is this class threadsafe?

For a static class variable with an initializer (private static SingletonTest instance = new SingletonTest()), when does the object get created?

If we make the constructor protected and extend the class with a new class SingletonTestPlusPlus and then call SingletonTestPlusPlus.getInstance(), what is the type of variable st in main - SingletonTest or SingletonTestPlusPlus?

Trace the call stack with me at initialization time. Would SingletonTestPlusPlus'sconstructor be called before or after SingletonTest's?

Most people ace the code, and easily answer #1. I'm amazed how difficult #2 seems to be, but eventually people will figure out there is more than one way to initialize a class variable. By the time we get to #3 and #4 it starts thinning out pretty dramatically. I rarely get to #5 or #6.

The point of this exercise is not for the candidate to get everything right, but to see how they operate when they don't know an answer. My observation is that the more competent you are, the more intelligent a conversation you can have, and that is really what I'm looking for here. I like to see candidates who are on a voyage of discovery, buoyed by a passion for knowledge and personal improvement.

I certainly don't mind push back either - I think that is a good sign. You should not simply accept what anyone is telling you if it goes against everything you know and hold true. At the same time, you need to have an open mind and be willing to learn - that is the sign of a competent person.

[1] I once worked with a project manager who got into a fight with a candidate during an interview and punches were thrown. Perhaps the fact that he was a pompous, self righteous, git had something to do with it.