Book Review: Mrs. Roberto

I recently finished reading Mrs. Roberto, the fourth installment of the Moosepath League series by Van Reid.

I'm too rushed to write a complete review, but I heartily recommend the book. I've written about the Moosepath League series before. In my opinion, Mrs. Roberto is the best installment yet. The fifth book, Fiddler's Green, is also the last in the series. At least it is the last one published. I hope there will be more.

Here are some real reviews at Amazon.
 

Conway's Law

In a 1968 article called How Do Committees Invent?, Melvin Conway minted Conway's Law:

Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.

This makes sense to me. A product like Eclipse -- with loosely coupled components and a very small kernel -- can only result from a loose "open source" organization with little central control. On the other hand, an organization with a rigid command structure and central planning is most likely predestined to produce software that is unwieldy and difficult to change.

It also suggests how designing the wrong organization can result in gaps in a system design. I know of one client software project that never had a network group although one was desperately needed. The hope must have been that a network layer would emerge out of the shared requirements of many groups, but it didn't happen. Because there was no assigned responsibility for a network layer, each group created a different set of network utilities.

Dr. Conway calls this phenonmenon homomorphism. There is a "structure-preserving relationship" between the organization and the design it produces. This insight is significant in itself, but Dr. Conway also develops some interesting corollaries. One of them is:

... the structure of the system will reflect the disintegration which has occurred in the design organization.

In other words, when two groups in the organization do not communicate well, the components they produce will not communicate well either. This suggests a better way to monitor progress in software development. In addition to monitoring the progress of individual components, we should also be asking are groups X and Y communicating well? If they aren't, it might indicate an impending breakdown in the design.

While reading How Do Committees Invent?, I experienced several "Ah-ha" moments. Once again, I am amazed something written in 1968 is still relevant today. Follow the preceding link for the full text of Melvin Conway's article.

The truth about Google. I found my way to Conway's Law by reading Don Norman's essay called The Truth about Google's So-called Simplicity. That is also interesting reading.
 

Top Ten Blogging Mistakes

Jakob Nielsen has published a list of the Top Ten Design Mistakes made by bloggers. Mr. Nielsen is a smart guy, but he's not half as funny as David Letterman.

Here's how my blog measures up:

1. No Author Biographies. Guilty.


2. No Author Photo. Guilty.
   (Then again, I don't post dozens of high resolution photos of myself like Mr. Nielsen)


3. Nondescript Posting Titles. Not guilty.


4. Links Don't Say Where They Go. Not guilty.
   (I'm on a roll.)


5. Classic Hits are Buried. Guilty.
   (Well, I was on a roll.)


6. The Calendar is the Only Navigation. Not guilty.


7. Irregular Publishing Frequency. Guilty.


8. Mixing Topics. Guilty.


9. Forgetting That You Write for Your Future Boss. Not guilty.
   (Heck, I am writing for my current boss most of the time.)


10. Having a Domain Name Owned by a Weblog Service. Guilty.

Four out of ten is pretty bad. Why am I doing this again?

Update. I previously ended this post in mid-thought. To answer my own question, I expect this blog to be read by only a handful of colleagues, friends, and family. It started as an experiment and I keep going mostly because I enjoy writing. Getting a better score on the "Nielsen test" is the least of my concerns -- especially if it requires a lot of work.

Of course, I do hope people enjoy Runtime Log. Many thanks for reading!
 

On Quotes and Misquotes

"Quotation, n.: The act of repeating erroneously the words of another."
-- Ambrose Bierce from The Devil's Dictionary

A few weeks ago, I added the "Random Quote" section to the right side of this page. Ever since, I have been looking for new quotes to add to my list. Recently, I stumbled upon this one:

Proof by induction is not as prevalent as proof by intimidation.
-- Austin Train

I like that. It neatly captures what many of us experience every day. In supposedly rational debates, power often trumps reason.

Before adding this quote to my list I decided I should at least answer one question. Who is Austin Train? Google provided the answer. He is a fictional character in The Sheep Look Up by John Brunner. Although I am reluctant to quote the words of a fictional character, I decided to take it a step further. I used Amazon.com to Search Inside the book for the above quote. Guess what? The fictional Austin Train apparently never said those words.

The point is a quotation is a dicey proposition. One of my favorite sources is the often bizarre, always deadpan comedian Steven Wright. There are many lists of Steven Wright jokes on the Internet, but I remember reading once that Steven Wright himself denies making some of the jokes. So while I am 99% certain Steven Wright is a real person, I can't guarantee he said everything you might see under "Random Quote". I can only say I wouldn't knowingly misquote anyone.

This of course is a symptom of a general phenomenon. We have more information readily available to us than ever before. The trouble is half of it is wrong. So enjoy the quotes, but don't believe everything you read.
 

B.A.A. Half Marathon

Many runners have a favorite race -- a race they return to year after year. My favorite is the B.A.A. Half Marathon. Last Sunday I completed the B.A.A. Half for the fourth time in as many years. I've run each edition of the race except the inaugural 2001 edition.

Why do I keep going back?

• The beautiful 13.1 mile course starts in the Fenway district of Boston, runs out to Franklin Park Zoo along the Emerald Necklace, and returns along the same route. I've heard it described as a moderately difficult course, but the hills are nothing compared to New Hampshire hills.
  


• Columbus Day weekend is a great time of year for a half marathon. The temperature is cooler and the Fall foliage is just getting started in Boston.
  


• The race is very well organized. It is officially run by the Boston Athletic Association, but it is really directed by Dave McGillivray Sports Enterprises. This is the same team that has directed the Boston Marathon for the past several years. Each year, the B.A.A. Half organizers bring a great volunteer staff, provide excellent traffic control, and in general manage the race flawlessly.
  


• At three thousand plus runners, it is a medium sized field. It's not big enough to cause a huge bottleneck at the start, but you have plenty of company all along the course.
  


• The crowd support is great. Much of the six mile plus, out-and-back course is lined with people cheering the runners. The crowds give you a boost of energy, especially in the last two miles. The smaller New Hampshire races I normally run just can't compare.

All of the above combine to produce a favorable atmosphere for racing and, usually, I post a relatively good time. Of course, I am no threat to the leaders, but I ran a "personal best" 1:38:23 at the 2003 B.A.A. Half.

This year my time was about four minutes slower, but it was about what I expected given the amount of training I've been able to do. When you are a middle-of-the-pack runner, your main goal is to run your best possible time at an even pace. You don't want to go out too fast and finish the race slow. This year I felt in control of my pace largely because I am now so familiar with the course. I can't wait to give it another try next year.
 

Sustaining Irrational Technology Choices

There's another great essay on Hacknot. In A Dozen Ways To Sustain Irrational Technology Selections, the author explains there is a myth about software developers:

External observers often think of programmers as being somewhat cold and emotionless...Those who have watched programmers up close for any length of time will know that this is far from the case. I believe that emotion plays a far larger part in IT decision making than many would be willing to admit. Frequently developers try and disguise the emotive nature of their thinking by retrospectively rationalizing their decisions...

With tongue-in-cheek, the author goes on to list twelve ways to protect your image in the face of a bad technical decision. Here's number ten:

10. Exclude The Technically Informed From The Decision Making Process

As a self-appointed evangelist for your chosen technology, your worst enemy is the voice of reason. The technology's inability to fulfill the promises its vendor makes should be no obstacle to its adoption in your organization - and indeed, it won't be, so long as you can keep those who make the decisions away from those who know about the technology's failings. Let their be no delusion amongst your staff and colleagues that it is management's purview to make these decisions, and the techies' job to implement their decision. Some will try and argue that those who know the technology most intimately (technical staff) are in the best position to judge its value. Assure them that this is not so and that only those with an organizational perspective (management) are in a position to assess the technology's "fit" with the corporate strategy. Allude to unspoken factors that influence the decision to use this technology, but are too sensitive for you to discuss openly (conveniently making that decision unassailable).

In my opinion, it's a good list, but the author missed at least one item. Here's my contribution:

13. Banish the Infidel

When pleading your case to management, lament the fact that those who disagree with you just aren't "team players". Label the dissenters as malcontents. Make it clear it is they, not you, who are being emotional about your technical decision. Of course, you can't literally banish the dissenters -- especially if it is a large group. Who would implement your design? However, you can ostracize the dissenters to the point where their voices are not heard, and here's the silver lining. When your design fails, you can blame the implementers. Your choice of technologies was sound, but the dissenters, perhaps unconsciously, made it fail by suboptimizing the implementation.

What else is missing from the list?
 

Screencast of Flooding in New Hampshire

Heavy rains caused localized flooding in southwestern New Hampshire this weekend. Dams were breached, homes were destroyed and roads were washed out.

Jon Udell toured Keene on his bike, captured some video, and created a screencast of the flood. He combined his video capture with a Google Maps trace of his route through Keene -- not to mention a light-hearted running commentary. Even with a broadband connection, the feed was very jumpy this morning, but the concept is intriguing.
 

Four Minutes

Last night, I watched Four Minutes on ESPN2. In case you've missed the previews, it is an ESPN original movie about Roger Bannister and his record sub-4 minute mile in 1954. It was very well done, but left me wanting to know more about his training techniques.

At one point, the four minute mark was considered unattainable. It was modern training techniques as much as talent that allowed Bannister to get there first. The movie is understandably short on the details. Now I guess I'll have to read The Perfect Mile for the whole story.

Even so, the movie was very good. ESPN2 is replaying it throughout October. Check out the list of air-times.
 

Tom DeLay, No Relation

For the record, I am not related to Tom DeLay. He spells his last name with a capital "L", indicating a French heritage. My ancestors are Irish. Delay with a little "l" is the anglicanized form of an old Gaelic name.

We can't possibly be related. Not a chance. At least I hope not.
 

Google and Sun Announce Partnership

Yesterday, Google and Sun announced they are best buddies. The press is speculating Google and Sun will join forces to challenge the dominance of Microsoft Office, but the facts are fuzzy. According to a story at USA Today:

What is known: Google is buying computers from Sun. Sun is buying ads from Google. And the companies are bundling Google's Toolbar and Sun's Java, both pieces of free software designed to improve the Web-surfing experience. Terms of the deals were not disclosed.

From an Associated Press story:

"There really isn't much depth to this partnership," said industry analyst Rob Enderle.

"I think Eric [Schmidt] is doing this as personal favor for Scott [McNealy]," he said. "It provides a certain amount of press and visibility to Sun when there hasn't been very many positive things going on at the company."

So the benefits for Sun are obvious. What I don't understand is what this means for Google. They don't appear to have a huge investment in Java or the J2EE stack. There doesn't appear to be much synergy there. They have been playing with free email and other web applications, but Gmail is still in Beta after 1-1/2 years. They have a very successful search engine and advertisement-based revenue model. Does Google really want to take on Microsoft Office?

My guess is the founders are too smart for that -- unless they just aren't old enough to remember Borland, Lotus, Novell, Corel and the other losers in the office suite wars.