March of the Penguins

We saw March of the Penguins last night. It's a feature length National Geographic Special about the annual migration of adult emperor penguins. It was fascinating. Every March, the penguins leave their ocean habitat and walk 70 miles across the Antarctic ice to their breeding grounds. They form pairs, each mother lays a single egg, then each pair works together to ensure the survival of their chick through the harsh Antarctic winter. They are 70 miles from any food source. I won't give away any more details. That would take the fun out of watching the story unfold. It is just incredible how they manage to survive.

This is a great family movie. There are some short scenes that might unsettle a sensitive child, but overall it is uplifting and fun. The kids in my family (ages 8 to 48) all loved it.

For more see Google Reviews.
 

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
 

NameVoyager

Here's a cool Java applet. NameVoyager lets you dynamically graph the popularity of most common names since the 1880s.

The Baby Name Wizard's NameVoyager is an interactive portrait of America's name choices. Start with a "sea" of nearly 5000 names. Type a letter, and you'll zoom in to focus on how that initial has been used over the past century. Then type a few more letters, or a name. Each stripe is a timeline of one name, its width reflecting the name's changing popularity. If a name intrigues you, click on its stripe for a closer look.

But words can't describe how cool it is. Try it out.

(via Hans Muller)
 

Time to Do Software Right

I've been thinking about two recent posts by Jeff Atwood. In UI is Hard, Jeff cites evidence that UI programming is harder than server-side programming. His recommendation is to think about the UI first.

In my opinion, both the premise and the solution are wrong (or at least they aren't universally correct). UI programming is certainly hard. The UI should never be an afterthought, but server-side programming can be equally hard to get right. You must design for scalability, performance and reliability on the server-side. If you don't, even the most elegant front-end will be broken from the user's perspective.

So it shouldn't be "UI first". Instead it should be "UI and server-side together". And you might need a few iterations to get it right. The problem is iterations take time.

In The Broken Window Theory, Jeff argues we should take the time to fix "broken windows" (bad designs, wrong decisions, poor code). Failure to do so breeds an atmosphere of sloppiness. When a developer see problems throughout the code, he wonders why he should spend the time to do his part right.

I agree with 100% with this analysis, but let's consider the cause of the "broken windows". Is it incompetence or laziness on the part of developers? Sometimes, but more often I think it is lack of time. Compressed schedules are epidemic in the software industry. Because of the schedule, we short-change the design phase of projects, we ignore the need to iterate in the design-development process, and pretend not to see the myriad "broken windows" in our code. After all, we can fix the process and the code "next release".

In The Mythical Man-Month, Dr. Fred Brooks likens good software to good cooking. Brooks quotes the resolute Chef Antoine:

Good cooking takes time. If you are made to wait, it is to serve you better, and to please you.

If we had more Chef Antoines in the software industry, we might have happier customers.
 

Scambaiters

This morning, Morning Edition included a report on scambaiters. This is a group of people who turn the tables on email scammers. A scambaiter wastes the scammer's time by sending him on a wild goose chase. For example, he might pretend to wire some money and then repeatedly ask the scammer to check a nearby Western Union office. This old BBC report shows how one scambaiter used an elaborate hoax to waste a scammer's time. Blinded by greed, some scammers will do incredibly stupid things.

There's even a scambaiting community at 419 Eater. Personally, I think the 419 Eater Trophy Room is disturbing on many levels. Yes, scammers are criminals, but vigilante justice is not pretty. Scambaiters claim they are doing a public service. I think they enjoy humiliating incompetent crooks just a little too much.

By the way, Joe Russo is not exactly a professional scambaiter, but his blog includes some really funny transcripts of his chats with scammers. See parts one, two, and three of his "International Financier" story.
 

Book Review: Nop's Trials

Ever since I first watched a sheep dog trial, I have been fascinated by border collies. With just a few commands from his master, a well trained border collie is able to gather a small herd of sheep, march the herd through a gate, and drive them into a pen. It's a eerie mixture of predatory instinct and obedience training.

Nop's Trials, by Donald McCaig, is a story about a border collie named Nop. I am not giving away too much of the plot by telling you Nop becomes separated from his master, a Virginian farmer named Lewis Burkholder. The story follows Nop from one bad experience to another. Meanwhile, finding his dog becomes a kind of quest for Lewis Burkholder.

This sounds a little like Lassie Come Home, but it's not kids stuff. The book is unflinchingly gritty at times. It's also inventive. It's told in the third person, but McCaig often gives you Nop's perspective. There's even dialog between Nop and the other dogs he meets. Dog dialog may sound like a gimmick, but if despite your better judgment you have ever wondered what your dog is thinking, you will be enchanted.
 

As the World Turns

When we last left our story, Joel's post questioned why anyone would want to work for Microsoft and Robert Scoble countered with a whole list of good reasons. Now Joel has posted a follow-up claiming "folks at Microsoft are feeling a little defensive these days". Joel is not exactly in a compromising mood.

At Stanford's commencement last weekend, Steve Jobs said this:

"Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma - which is living with the results of other people's thinking. Don't let the noise of other's opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary."

Good advice.

Jobs message is to "find what you love." I think Joel Spolsky has found it. I guess Robert Scoble has found it too. Lots of people at Fog Creek, Microsoft, Google and IBM have found it. Congratulations. But once you've found it, there's little point in claiming you have found the one true way.
 

Flickr Hack

Inspired by flickReplacr -- a neat tool that replaces words on a web page with Flickr images -- the following is a representation of "run" "time" "log":



The images should change every time you visit this blog or hit Refresh. And of course each image is also a link. Click on an image to see a larger version at Flickr.

(flickReplacr is via Coding Horror)
 

Big Company Blues

Not that big company. I'm talking about Microsoft. Gretchen, a recruiter at Microsoft, blogged about the difficulties of finding and attracting talented developers in today's climate. She has me convinced recruiting is a tough job. It's very interesting that hiring managers think they can do her job better than she can. That's a common complaint from developers too.

Joel's response to Gretchen is also worth reading. Joel is head of a small company so he has an obvious axe to grind. He can't understand why anyone would want to work for a big company. Still, I got a kick out of some of the pages Joel links to -- for example, this microserf's ode to his office guest chair. He has somehow escaped the big company Furniture Police. Who will have the last laugh?
 

The Yankee Siege Trebuchet

I was driving through Greenfield, New Hampshire the other day and noticed a strange sight. Standing in the middle of a clearing was a sort of wagon with four 12 foot diameter steel wheels. There were lots of other large welded objects lying around the yard. Up on a small hill at the edge of the clearing was a replica of a medieval castle. What could this be?

When I returned home I searched the web. It turns out I had passed the home of the Yankee Siege trebuchet. A trebuchet is like a catapult. (You can click the thumbnail at the left to get a better view.) This one weighs close to 20 tons and can toss a 250 pound object about 300 yards. Usually it tosses lighter objects like pumpkins. At the 2004 World Championship Punkin Chunkin contest, the Yankee Siege captured the world record by tossing a pumpkin 1394 feet.

According to the Yankee Siege web site, you can see this trebuchet in action each weekend during the Fall foliage season. Apparently they toss pumpkins at the castle. I can't wait.
 

The Mythical Surgical Team

The Mythical Man-Month is a masterpiece on the subject of software project management. Although he wrote the book in 1972, the author, Dr. Fred Brooks, is still quoted by software developers and managers today. "Plan to throw one away," "Take no small slips," and "Adding manpower to a late software project makes it later," have long since become conventional wisdom. We don't always follow the conventional wisdom, mind you, but we can quote it.

It is amazing how relevant The Mythical Man-Month still is, but Chapter 3 struck me at first as quaint if not downright bizarre. The chapter is called "The Surgical Team". In it Dr. Brooks promotes an idea first developed by IBMer Harlan Mills in 1971. The idea is to organize large software development projects into multiple "surgical teams". Each team is headed by a chief programmer, the surgeon, who does most of the delicate work. In a real surgical team, the surgeon does all of the cutting and stitching. He is supported by a staff of specialists with more mundane roles. In the Brooks/Mills scheme, the chief programmer does most of the programming. He has a staff of nine people to take care of mundane tasks.

Brooks goes into a lot of detail about the supporting roles. I won't give all the details, but here is a summary:

• The copilot is the chief programmer's right-hand man. He can do the development work but he has less experience. He often represents the team at meetings and otherwise off-loads the chief programmer from duties other than pure development.

• The administrator manages people, hardware and other resources required by the team.

• The editor is responsible for editing documentation written by the chief programmer.
  

• Two secretaries -- one each for the administrator and editor.
  

• The program clerk keeps all the records for the project including source code and documentation.
  

• The toolsmith builds specialized programming tools to the chief programmer's specifications.
  

• The tester develops and runs both unit tests and system tests.
  

• The language lawyer is an expert on the computer languages used by the chief programmer. He provides advice on producing optimal code.
  

My first reaction to this list was, he's crazy. It doesn't take nine people to support one good software developer. Then I realized it may have taken that many people to support one good systems programmer in 1972. And you know what? Many of the above roles have since been automated by software itself. We don't need a language lawyer anymore. We have optimizing compilers, PMD and other tools. We don't need a programming clerk anymore. We have easy-to-use source code control systems, discussion databases, and document repositories. We don't need a toolsmith anymore. We have plenty of tools to choose from.

My point is that Brooks's vision has largely been realized, but in a way he didn't predict -- by automation. We haven't hired a support staff for each chief programmer. We have automated most of the surgical team's tasks.

Does that mean each developer is a self-contained surgical team? Unfortunately, the answer is no -- no more than hiring a real surgical team would make me a surgeon. A surgeon is made by training and experience, not by the resources at his disposal.

In The Mythical Man-Month, Brooks establishes at least two central premises before promoting the surgical team concept:

1. The main problem with large software development projects is one of communication. The more developers on the project, the bigger the communication problem is.
    
   
2. There is a huge productivity gap among software developers. The good developers are very, very good. The bad ones are very, very bad.

The whole idea of building multiple surgical teams is to reduce the effects of these two phenomena. In other words, minimize the number of hands in the code, make sure only the best, brightest and most productive developers are coding, and give these developers all the resources they need. I think automation has solved the resource part of the equation, but in my experience, software development managers still misunderstand the rest of it. We tend to build large teams of developers with a wide-range of training and experience, and then reduce them to interchangeable man-months. This is a recipe for disaster.

My advice is to go back to the drawing board. Hire the best developers to do the work. Pair them with more junior developers for the purposes of training and insurance -- not necessarily to do the work. And, at all costs, keep teams as small as possible.