rc3.org

Strong opinions, weakly held

Month: June 2009 (page 3 of 3)

Quotable: Tyler Cowen

Tyler Cowen on bloggers:

I have never once met a person whose blog I like and then been disappointed. Never.

I wonder if the converse is true as well. Would you like a person if you don’t like their blog?

Links from June 3rd

Pivotal Tracker versus bug tracking

I am a long-time fan of bug tracking applications. One day I’ll post my basic toolkit for setting up a new development team, but suffice it to say, a good bug tracking application is a key part of the picture. Obviously this isn’t revolutionary — most software development teams use a bug tracking tool of some kind or another.

Lately, though, I’ve been using Pivotal Tracker, a project planning tool that resides somewhere between Microsoft Project and your favorite bug tracking application. The idea behind it is that it allows you to enter all of the tasks associated with a project, put them in order, chunk them into iterations, and then track your progress toward milestones.

Bug tracking tools are great for dealing with tasks, and are usually OK when it comes to grouping those tasks into releases, but what Pivotal Tracker provides beyond that is the ability to easily keep track of how quickly you’re completing tasks and how that pace affects the project calendar.

To set up a project in Pivotal Tracker, you tell it how long your iterations are (one week, two weeks, or longer), enter your tasks, and then add estimates for each of those tasks. Pivotal Tracker’s idea of estimates is very simple — you give tasks one to three points. It keeps track of how many points you’re finishing per iteration, and then estimates how long it will take to finish your project based on your historical performance. So if you have an 80 points left on your project and you’re finishing 20 points a week, it calculates that you’ll be done in a month. If your progress slows to 10 points a week, it’ll spread the remaining tasks out over two months. This sounds really simple but the fact that it all works without requiring the administrator to manually move tasks from one release to the next is a huge convenience. In fact, it’s the key convenience that sets Pivotal Tracker apart.

This addresses the largest difficulty I’ve run into in building software — catching schedule problems early in the process. All too often, projects get behind early but the impact of being behind isn’t felt until it’s too late to do much about it other than push back the delivery date. This is what processes like Scrum are really about — shrinking the feedback loop to catch problems early. Pivotal Tracker is the tool that makes those kinds of processes easier to implement.

I have a lot more to say about Pivotal Tracker that I’ll be writing up soon, but I wanted to just introduce it first. If you’re managing software development projects, I strongly encourage you to check it out.

America’s changing demographics

Nate Silver at fivethirtyeight.com unearthed this amazing statistic:

In 1980, 32 percent of the electorate consisted of white Democrats (or at least white Carter voters) — likewise, in 2008, 32 percent of the electorate consisted of white Obama voters. But whereas, in 1980, just 9 percent of the electorate were nonwhite Carter voters, 21 percent of the electorate were nonwhite Obama voters last year. Thus, Carter went down to a landslide defeat, whereas Obama defeated John McCain by a healthy margin.

Strategies: “best” strategies versus “better” strategies

In a long, wide-ranging dialog with Bill Simmons, Malcolm Gladwell makes the following observation:

After my piece ran in The New Yorker, one of the most common responses I got was people saying, well, the reason more people don’t use the press is that it can be beaten with a well-coached team and a good point guard. That is (A) absolutely true and (B) beside the point. The press doesn’t guarantee victory. It simply represents the underdog’s best chance of victory. It raises their odds from zero to maybe 50-50. I think, in fact, that you can argue that a pressing team is always going to have real difficulty against a truly elite team. But so what? Everyone, regardless of how they play, is going to have real difficulty against truly elite teams. It’s not a strategy for being the best. It’s a strategy for being better. I never thought Louisville — or, for that matter, Missouri — had a realistic shot at winning it all in the NCAAs this year. But if neither of those teams pressed, they wouldn’t have been there in the first place. I wonder if there isn’t something particularly American in the preference for “best” over “better” strategies. I might be pushing things here. But both the U.S. health-care system and the U.S. educational system are exclusively “best” strategies: They excel at furthering the opportunities of those at the very top end. But they aren’t nearly as interested in moving people from the middle of the pack to somewhere nearer the front.

This is a really powerful observation. I often think of it when I think about all of the interviewing tips you see from people who work at places like Google. When what you are offering is a job at Google, you can take a different approach to hiring than you can most other places.

People are always encouraged to emulate the biggest and best, but the most effective strategies are tailored to suit the specific position of the organization adopting them. Telling a startup to be like Google (or General Electric) is like telling a sardine to imitate a shark or a blue whale. It’s not going to work.

Newer posts

© 2024 rc3.org

Theme by Anders NorenUp ↑