Search This Blog

Thursday, July 23, 2009

Unsubscribing made easy

link -> Unsubscribing made easy
Posted by Brad Taylor, Gmail Spam Czar

We believe you should only get the mail you want to get. Some of you already use the "Report Spam" button on all kinds of unwanted email, and for that we're very thankful: the more spam you mark, the better our system gets at weeding out junk mail.

Unsubscribing from mailing lists and newsletters you subscribed to a while back but no longer want to receive should be just as easy. Searching through individual messages for little unsubscribe links is too big a pain —you should be able to unsubscribe with a single click.

So we just launched something that makes this all work better, both for Gmail users and big email senders. Now, when you report spam on a legitimate newsletter or mailing list, we'll help you unsubscribe. After clicking report spam, you'll see a little dialog like this:


Clicking "Unsubscribe" will automatically send a request back to the sender so they'll stop emailing you.

This only works for some senders right now. We're actively encouraging senders to support auto-unsubscribe — we think 100% should. We won't provide the unsubscribe option on messages from spammers: we can't trust that they'll actually unsubscribe you, and they might even send you more spam. So you'll only see the unsubscribe option for senders that we're pretty sure are not spammers and will actually honor your unsubscribe request. We're being pretty conservative about which senders to trust in the beginning; over time, we hope to offer the ability to unsubscribe from more email.

For those of you senders who are inte

Teams should be improved, not enlarged

Cockburn writes:

Here is a common problem: A manager has a 10-person team that sits close together and achieves high communication rates with little energy.

The manager needs to increase the team's output. He has two choices: add people or keep the team the same size and do something different within the team.

If he increases the team size from 10 to 15, the communications load, communications distances, training, meeting, and documentation needs go up. Most of the money spent on this new group will get spent on communications overhead, without producing more output.

This group is likely to grow again, to 20 people (which will add a heavier communications burden but will at least show improvement in output).

The second strategy, which seems less obvious, is to lock the team size at 10 people (the maximum that can be coordinated through casual coordination) and improve the people on the team.

To improve the individuals on the team, the manager can do any or all of the following:

* Send them to courses to improve their skills.
* Seat them closer together to reduce communications cost.
* Improve their amicability and teamwork.
* Replace some of the people on the team with more talented (and more highly paid) people.

Repeating the strategy over time, the manager will keep finding better and better people who work better and better together.

Notice that in the second scenario, the communications load stays the same, while the team becomes more productive. The organization can afford to pay the people more for their increased contribution. It can, in fact, afford to double their salaries, considering that these 10 are replacing 20! This makes sense. If the pay is good, bureaucratic burden is low, and team members are proud of their output, they will enjoy the place and stay, which is exactly what the organization wants them to do.


As a programmer and not the manager how can I help our team improve? Hopefully reading this book is a start, but I am going to keep looking for ways to do more.

Monday, July 20, 2009

Speechless: Dilbert Creator's Struggle to Regain His Voice

link -> Speechless: Dilbert Creator's Struggle to Regain His Voice

Designing a methodology

Cockburn writes:
Designing a methodology is not at all like designing software, hardware, bridges, or factories. Four things, in particular, get in the way:

* Variations in people. People are not the reliable components that designers count on when designing the other systems.
* Variations across projects. The appropriate methodology varies by project, nationality, and local culture.
* Long debug cycles. The test and debug cycle for a methodology is on the order of months and years.
* Changing technologies. By the time the methodology designer debugs one methodology design, the technologies, techniques, and cultures have changed and the design needs updating.


No wonder it is so hard to get this stuff right. It keeps things interesting though.

Tuesday, July 14, 2009

Extreme Hour

Cockburn writes
More recently, Peter Merel invented a one-hour process miniature for Extreme Programming, giving it the nickname Extreme Hour. The purpose of the Extreme Hour is to give people a visceral encounter with XP so that they can discuss its concepts from a base of almost-real experience.

In the Extreme Hour, some people are designated "customers." Within the first 10 minutes of the hour, they present their requests with developers and work through the XP planning session.

In the next 20 minutes, the developers sketch and test their design on overhead transparencies. The total length of time for the first iteration is 30 minutes.

In the next 30 minutes, the entire cycle is repeated so that two cycles of XP are experienced in just 60 minutes.

Usually, the hosts of the Extreme Hour choose a fun assignment, such as designing a fish-catching device that keeps the fish alive until delivering them to the cooking area at the end of the day and also keeps the beer cold during the day. (Yes, they do have to cut scope during the iterations!)


This sounds awesome. I wish we had done an extreme hour on my team before we started XP. I wonder if I could convince people to do one now.

There are so many different pieces to XP. It is hard to see how they fit together by reading a book. I think the Extreme Hour could show people how each part of the process is important without making them invest more than an hour.

Friday, July 3, 2009

Daily Commute started on July 1, 2009

link -> Daily Commute started on July 1, 2009
Starting yesterday, I am doing my daily work commute via the Twike. The missing piece was getting a second battery pack working well. I drove yesterday and today to and from work which for me is just under 8 miles. I don't yet have a good feeling for how much power it is taking to do my commute but today it only took 1.2Kw to charge it when I got to work (and that was after it ran the fans for a while to cool the batteries). The NiCads can deliver lots of power but they do heat up in doing so and right now we are having a heat wave in Portland which does not help. I got lots of thumbs up and waves today. One guy was keeping next to me and yelling out his open windows. "hey! really cool. Where did you get it? Did you build it?" that kind of stuff. Kind of hard to drive and answer questions in traffic. Work is cool about letting me charge there (used 12 cents of power today). I'm not sure, but I might have enough charge to go roundtrip without charging at work. Tomorrow I'm going to try a trip to someone's house that is 13 miles away so we will start to test the range a little more. Currently, my longest single trip is the 8 miles to work. Since I brought it home, I bought 3 new tires, had them mounted and balanced, and I installed them on the vehicle. I also did a lot of cleaning up in the battery compartment and on all the removeable panels (bottom and sides). With two reasonable battery packs, the car is pretty snappy on acceleration. I can keep up with traffic no problem and can even hill climb at a reasonable rate (not as fast as a car but at least I *can* accelerate uphill now). I have been taking a less direct route home to minimize the hill climb t

Thursday, July 2, 2009

Coordination is important

Cockburn writes:
Coordination is important. The same average people who produce average designs when working alone often produce good designs in collaboration.

Conversely, all the smartest people together still won't produce group success without coordination, cooperation, and communication. Most of us have witnessed or heard of such groups. Team success hinges on cooperation, communication, and coordination.


I like this quote. This is the reason why I am reading this book. I want to learn how to help myself and my team cooperate, communicate, and coordinate better.

Wednesday, July 1, 2009

Boatman’s bags

link -> Boatman’s bags

Amicability and Conflict

Cockburn writes:
Amicability is the willingness of people to hear the thoughts of another person with goodwill and to speak without malice.

Amicability is the weaker cousin to trust. Trust is wonderful and should be nurtured, but amicability is easier to achieve within a group and still confers advantages. I always watch the amicability level in an organization to learn to what extent information is being revealed versus concealed in conversations.

When people conceal information from their colleagues, they lower the rate of information discovery, which raises the lost-opportunity cost as well as the overall cost per idea developed.

Amicability permits successful conflict to occur when the project goes through a stressful period. The people, knowing that the others are not intending to be hurtful, can look past the current disagreement toward resolving the issues.

One might think that removing all conflict from a project team would be the best, but that turns out not to be the case. People need to be able to disagree, in order to identify design problems!


I think being able to listen and without an agenda is really important but really hard for me to do. I start thinking about how to word my response before the other person is even finished talking. I want to be more patient and not be in such a hurry to steer the conversation in one way or another. I need to trust that eventually both people working together will come to the best conclusion.