I started a very small open-source project called View Protect on Google Code

The project wiki and description page are nonexistent now, but the code is at least mostly commented. :)

So check out the View Protect Project Web Site and check out the Mecurial repository using:

hg clone https://viewprotect.googlecode.com/hg/ viewprotect  

I recommend downloading the new Eclipse Helios release, adding the plugin site for Hg Eclipse (http://cbes.javaforge.com/update), and, if you have nothing better to do, perform a code review of View Protect. :)

Team Work Pattern: Command-and-Control Chat Session

Trivial, but surprisingly uncommon in the "business world":

Instead of a bunch of emails and phone calls, start a big group chat with all of the relevant team members - PMs, managers, lead developers, etc. Using IM will force people to be brief and to get to the point. Grammar and word choice won't matter as much as IMs are felt to be much less permanent than emails. You won't have to type everyone's name in the "To" and "CC" fields of an email (and mistakenly leave someone out) because all the relevant people will have been added to the "Command-and-Control Chat" already. You will be able to collaborate at a speed approaching that of light and you will get your job done faster and more efficiently.

Why Formal Requirements Documents Are Useless

... because they contain requirements like:

The system shall display a count of occurrences returned from the search.

instead of:

The system shall display the number of search results found.

I mean, seriously, WTH does the former mean? In my opinion, "wire frames" are way more useful than tons of requirement statements thrown into an an RTM (requirements traceability matrix), especially when the latter uses prose reminiscent of IRC spam bots.

Brainstorming a killer Gmail feature: Distributed Version Control System for Contacts and Contact Groups (I want a job, Google, if you implement this!)

First of all, Gmail probably almost certainly does what I shall presently suggest. Neverthemore, I don't know how to use it. Assuming Gmail doesn't do it, I will resist the urge to form a start up around the idea, and instead publish it on the Internets for all to see. This is especially rational since I probably can't fork Gmail. And now the awesome idea for Gmail.

(Keep in mind, the following is being written as it comes to me. I might clean it up and remove this caveat. If I do, then you won't see this paragraph.)

In a few words, the feature is "shareable contacts and contact groups". The feature should enable the following use cases:

• My cousin is planning a family function at his home in Wilmington, NC. He needs my list of family emails. I go to contacts, select the "Family" group and click "Share list with ...". Advanced options are available for "Allow user to add to list", "Allow user to edit contacts in list" along with an option to "Require approval" (for edits / additions).
  
• Family members constantly need access to my family contact group, which is the canonical list of family email addresses. Instead of composing an email, setting the "To" field to "Family" and then copy-pasting the entire list into the body of the email, I ... go to contacts, select the Family group, and choose "Share with ...". In the dialog that appears, I choose "members of this group." This is awesome. Now all members of the Family group have access to the Family group. The same sharing options described above are available.
  

Okay. So it sounds like what I'm proposing is a "Distributed Version Control System for Contacts and Contact Groups". Oh, my. Think Mercurial, Git, Bzr, for your contacts! A DVCS for your email groups! I can "clone" the original list. When people edit their clones and "push" those changes to my repository, I get the option to "merge" those changes. Changes to both the individual contact (someone updated a phone number) and the list (someone added a member to the list) are tracked in the repository.

So, my cousin throwing the big party in Wilmington clones my family list and then realizes that I spelled his name wrong. He updates his contact entry to his liking and commits and pushes the change. I see that there are updates available to the family list from my cousin and I review the changes - "Contact name changed from 'Jon' to 'John'" - and I decide to pull that update into my repository. A different cousin notices that her young son's email is on the list and doesn't want him on there because some of the emails are not age appropriate. So she deletes his email address from her clone and pushes the change. Her email program gave her the option of entering a comment about what she was doing. I see the update as "Deleted littleboy@foo.com from list: I don't want Little Boy to receive emails without going through me first. Please remove from your lists. Thanks, Mommy.", and I accept that update, too.

Later, I notice that my ten year old niece is doing a bunch of pointless updates to her list, and I decide to ignore all updates from her family list without prompting me about it.

The final version of our feature looks like:
A distributed version control system for contact repositories:

• Share contact repository consisting of contacts and contact groups
• Fine-grained control over what is shared, down to the individual contact level ("private" contacts and even "private" fields, e.g., a person might keep her cell phone number private or only share her office number with co-workers).
• Push updates to the contact repository to interested parties.
• Merge edits to the contact repository from various members.
• ...

This could possibly be implemented in an interoperable way, viz., some sort of contact repository standard. There are many details that need to be worked out, but I will not pursue them now. The idea is out there and such difficulties would likely be resolved in any successful implementation of the feature. In the end, the usefulness of the feature depends on the ease of use for everyone. I've used DVCS terminology to describe the feature since this is a programming blog and my audience will probably find such terms familiar. Those terms would not be appropriate for the Gmail implementation of the feature. Keep it high-level: "Share this group", "Share this contact", "Allow others to share this group", "Automatically synchronize updates made by friends to this group", etc.

P.S. I didn't google this before I wrote it, therefore it is likely that someone already suggested this. :(