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.
 

Toughest 10Ks in New England

According to New England Runner, the Jackson Covered Bridge race is one of the four toughest 10Ks in New England. The others are:

24th Annual Pottle Hill 10K
Mechanic Falls, ME - June 25

27th Annual Goshen Gallop 10K
Goshen, VT - July 24

27th Annual Bridge of Flowers 10K
Shelburne Falls, MA - August 13

New England Runner has organized a contest this year. Run each of these four 10Ks and you will be entered into a drawing for valuable prizes including, ahem, a free entry to one of next year's races.
 

Jackson Covered Bridge 10K

A few weeks ago I decided to run the Jackson Covered Bridge 10K. Jackson is in the heart of New Hampshire's Mt. Washington valley. The race web site describes the course as challenging with "a mile-long uphill starting in the first mile, rising about 500 feet in elevation." No problem. I recently ran a 12K with some hills. What goes up must come down.

On Friday, I checked the weather report. Saturday, race day, was going to be 85 degrees in Southern New Hampshire. No problem. It couldn't be that hot in the mountains. Also, race time was set for 10:00 AM, too early to worry about the heat.

As we assembled at the starting line on Saturday morning, it was at least 80 degrees. The race director cheerfully welcomed us to the "toughest 10K in New England." Uh Oh. This could be harder than I thought. I decided to just take it easy for the first mile.

The web site neglected to mention one important bit of information. The first uphill mile was followed by a second uphill mile easily as steep and punishing. Even worse, there was hardly any shade on the course. For me, it was the first time running in the heat this year.

In a word, it was a miserable race. I don't blame the race organizers at all. In fact, I'd like to go back next year and redeem myself. One rule about running is it demands specificity in training. If you are going to race on hills, you have to train on hills. If you are going to race in the heat, you have to train in the heat. Better luck next year.

Mt. Chocorua

At least I got some good pictures yesterday. Here's Mt. Chocorua from the shore of Lake Chocorua in Tamworth.

Eight Fallacies

On his blog, James Gosling has a permanent link to a page describing the Eight Fallacies of Distributed Computing:

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

These are assumptions developers make when building distributed systems -- like web applications. Of course, each assumption is completely wrong.

And here's the really sad part: Developers can make these false assumptions, show excellent progress against their schedule, and deliver a system that is unreliable, slow, and impossible to administer. Software development managers often don't know about these problems until it is too late. Indeed, you could argue managers encourage wrong behavior by tracking progress on the wrong things.

But this is not a diatribe against managers. In many ways, I think managers and developers are co-conspirators. To correct these false assumptions would make it obvious that building distributed systems is wicked hard and can take a long time. In other words, we pretend problems don't exist to compress schedules.

I think this is where the Software Architect comes in. A good architect has seen it all before. He knows the pitfalls. Like James Gosling, he has the Eight Fallacies (or some other canonical rules) pinned to his door. And here's the really important part: In a healthy organization, the architect has the power to change the schedule, to give developers guidance and enough time to do it right.