Microsoft Sues Former Employee and Google

ZDNet reports (as do many others) that Microsoft is suing a former employee, Kai-Fu Lee, for violating the non-competition clause of his employee agreement when he joined rival Google. The suit filed in Washington state court also names Google. According to Microsoft:

Google is fully aware of Lee's promises to Microsoft, but has chosen to ignore them, and has encouraged Lee to violate them.

I can understand Microsoft believes it has the grounds to prevent Mr. Lee from going to a competitor. I understand, but I hope the court ultimately finds Mr. Lee has not violated the spirit of his agreement and lets him work for Google.

What I don't understand is how Microsoft can sue Google for encouraging Mr. Lee to violate his agreement. I think Microsoft has stepped over the line there. Hopefully, this is not a sign of more anti-competitive litigation to come.
 

Fitness University Photos

Two months ago, I posted a notice about Fitness University -- a fun fitness program for kids. Here are some photos from Finals Day on Saturday, July 23. Click any photo to enlarge.

Hiring the Best Programmers

Joel explains why hiring the best programmers is the only way to produce great software. Others have made similar arguments, but Joel presents new data on the huge variations in programmer productivity. This is a great essay.
 

August - September Issue of Striding Along

There's a new issue of the Gate City Striders newsletter on the web. This issue includes an article called "Eating and Drinking Endurance" -- I mean "Eating and Drinking for Endurance". There are also articles on the recent Mt. Washington Road Race and the upcoming Lake Winnipesaukee Relay. These are two of New Hampshire's most distinctive road races.

For more, see the newsletter page.
 

Steal Joel's Book

If you read Joel on Software, you know Joel has been promoting his new book, The Best Software Writing I. When I first heard about the book, I thought it was a collection of articles originally published in "dead tree format"*. There's definite value there. An anthology can bring you the best-of-breed material and save you the time and cost of buying separate books or magazines.

It turns out The Best Software Writing I is really a collection of blog entries. Jeff Atwood recently posted links to all of the original blog entries. So why would you want to buy Joel's book? According to Jeff, "it's reasonable to have these entries in book form, with Joel's typically insightful introduction for each entry".

I am reserving judgment. It doesn't seem worthwhile to pay for a book, most of which is available online. I am working my way through the live blog entries. There are some interesting viewpoints. Of course, the big advantage to reading the material online is you get the complete context of each author's other blog entries.

---

* Dead tree format is the hip way of saying "printed on paper". Or perhaps it was hip once. In any case, I think it is silly, but I somehow couldn't resist using it.
 

New Job

I've been quiet for a while. I started a new job on Monday. I am working for the same company, but I am no longer working on server-side, web-based applications. I've gone "back to my roots". I am working on a desktop application which I won't name on this blog. Here is a hint: The application is based on Eclipse.

I have been extremely busy this week learning about Eclipse, the plugin framework, and other topics. I haven't had time to read other blogs never mind update this one. In due course, perhaps I will say more about the new job and Eclipse in general. So far it looks like it will be very interesting and maybe even a little fun.
 

Dave on Treehouses

Last summer I built this treehouse with my kids. We based it on a design we found in David Stiles's Treehouses, Huts and Forts.

The house has an 8x5 floor plan with a 3x5 overhanging deck (click here for a better look). It has six big windows to let the fresh air in and screens to keep the bugs out. Security features include a trap door accessible only from the ladder under the house and a dead bolt on the front door. It was a lot of fun to build and I hope my kids and their friends will have lots of fun using it.

How can I say this without sounding immodest? I humbly believe I am now one of the world's foremost authorities on building treehouses. I have big plans. In addition, to the exciting Dave on Treehouses web site (coming soon!), I am working on the following:

• Speaking engagements at major treehouse building conferences around the country.
   
• An anthology of the best writing about building treehouses.
   
• Summer of 2006 internships for worthy candidates. Each intern will take part in the building of a real treehouse.

Of course I'm joking. That is, my kids' treehouse is real, but I have no plans to promote myself as an authority on treehouses. My one treehouse building experience might be archetypal, but most likely you have different trees, different plans, and a different budget.

It is the same with software development. Every software project targets a specific platform, has its own mission, and must conform to its own constraints. Yet there are lots of self-appointed authorities on software development. They apparently believe their experiences are archetypal -- that their specific methods apply to software development in general. We follow their guidance at our own risk.

Does this mean we shouldn't be consulting the experts? Far from it. I just think it is up to us to sift out the relevant, essential advice from prejudice and mere opinion. As Mr. Ed says in Thought Leaders and Thought Followers, an appeal to authority is no replacement for a well-reasoned argument.

How do you sift the good advice from the rest?

• Know the expert's credentials. What has he done in his career? Where is he now? Although I was just poking fun at Joel Spolsky, I think he has good credentials. So do the other experts listed under Software Development at the right.
   
• Understand the expert's biases. Is he biased toward .NET or J2EE? Is he for Agile Methods or against? When you understand a person's biases, it helps you sort well-reasoned argument from knee-jerk reaction.
   
• Seek out opinions from people with different biases. I think this is the most important point. If you just listen to the J2EE crowd, you run the risk of becoming a J2EE acolyte. It's like listening exclusively to "red state" talk radio. Do that long enough and you'll be able to recite the party line. Your world will look a lot redder. But when you turn on NPR, you'll see the "blue staters" have some good points too. The world will begin to look purple -- which in fact it is.

So there you have it. More talk about software development with a little politics thrown in. Sorry if you thought this was going to be about treehouses, but you have to admit, that is a fine looking treehouse. Isn't it?
 

Agile Bridge Building

As a counterpoint to agile methods, check out this satirical look at Agile Bridge Building. It is the author's thesis that agile methods are based on the excuse that software development is essentially different from other endeavors. His opinion is software is not that different. Like any other creation it can be designed, estimated and planned up front.

In this corner, we have "blue state" agile practitioners telling us software is different and requires revolutionary new methods. In that corner, we have "red state" agile dissenters telling us software is not that different. The truth, I'm sure, lies somewhere in the middle.

Hacknot is back. I found the link to Agile Bridge Building on Hacknot. After a short hiatus it appears Hacknot is back. Unfortunately some articles appear to have gone missing.
 

Agile Manifesto

In 2001, Kent Beck, Martin Fowler, Andy Hunt, Dave Thomas, and other software developers penned the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This is old news of course. In April 2003 Ned weighed in with:

I like it, but it is hard to get fired up about a "manifesto". This isn't capitalism being replaced with communism here. Agility is a great thing, but the manifesto isn't so different from other inspirational pieces about software that have come before it. It seems evolutionary rather than revolutionary.

Although the authors called it a manifesto, they definitely tempered it with pragmatism. For example, they admit to the value of process. They just value individuals and interactions more than process.

The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.

So it's not a revolution, but it will still take an army of developers to inject some sanity into big corporate bureaucracies. Where do I enlist?

For more on agile development see the Agile Alliance.
 

Summer in New England

Portsmouth Harbor


Fourth of July at Strawberry Banke


Wallis Sands Beach