Inside Symantec LiveUpdate

Last April, I wrote about my problems with McAfee Internet Security Suite. Since I am on vacation this week, I finally got around to removing the McAfee suite from my home computer. I decided to upgrade to Windows XP Service Pack 2 -- for the built-in firewall -- and then add Norton AntiVirus for virus protection.

I was particularly worried about removing the McAfee software. Last time I tried that, the uninstall program failed and left lots of remnants on the system. I spent hours first tracking down instructions and then manually removing services and registry settings. By comparison, the removal of Internet Security Suite 6.0 was painless. It took all of five minutes.

The installation of Windows XP Service Pack 2 (SP2) was painless too. I still haven't explored all the benefits of SP2, but I like the built-in Windows Security Center, the new Outlook Express security features, and the Internet Explorer pop-up blocker. (Nevertheless, I will continue to use Firefox for most of my web browsing.)

In short, things were going great. I had a brand-new copy of Norton AntiVirus 2006 and I expected that installation to be dirt simple. Twenty four hours later, I finally have things working. Although the initial installation appeared to go well, I couldn't get Symantec LiveUpdate to work. Without LiveUpdate, it is difficult to get the latest virus definitions. Without those, virus protection is incomplete.

When LiveUpdate fails, it tries to be helpful. It displays an error message and provides a link to a Symantec web page with trouble shooting tips. In this case, the message was:

LU1841: Connection to ISP failed. LiveUpdate could not connect to your Internet Service Provider. Verify your dial-up information is correct.

Possible explanations included problems with the system's Internet Options or misconfigured firewall software. I checked these and other possible explanations, used Symantec's Automated Support Assistant, and generally pounded my head against the monitor for hours. Nothing helped.

Finally, I stumbled upon this excellent document on the Symantec site. Near the end of the document there is a section about some Settings.LiveUpdate files. These files hold various settings including the names of LiveUpdate servers. If the files are corrupted, LiveUpdate can stop working. The document suggests removing the files and trying again. Since the LiveUpdate service appears to keep the files open, this is easier said than done. Unless you take some special steps, you will get sharing violations when you try to remove the files.

Here's what worked for me:

1. Restart Windows in safe mode. This causes Windows to run without the LiveUpdate service.
    
2. Backup all the files in c:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate. I just copied the files to a temporary directory.
    
3. Back in the c:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate directory, remove all files with Settings in the file name. In particular, you don't want to remove the Configuration and Product files. Those files apparently contain important information about your registered Symantec products.
    
4. Restart Windows and retry LiveUpdate.

While this whole process took much longer than it should have, I feel like I understand the inner workings of LiveUpdate a little bit better. I am posting this story with the hope that someone else can benefit from it some day. Now I just have to take care of some overdue vehicle maintenance, finish a few household chores, and defeat the legions of spammers assaulting my Inbox. Then my "vacation" will be complete.
 

Thomas Jefferson

I am reading Paul Johnson's big A History of the American People. I am only about a quarter of the way through, but one of the pleasures of this book is seeing how Thomas Jefferson keeps popping up. From 1776, when he wrote the Declaration of Independence, through his busy years as President (1801-1809), until his influence diminished at the end of his friend James Madison's second term (1817), Jefferson managed to play a key role in shaping our nation.

I've read a lot about Jefferson before, but Johnson's history includes some facts that are new to me. For example:

• As a result of the 1783 Peace of Paris, the United States gained a vast new tract of land, the so-called Old Northwest Territory. Jefferson, who helped negotiate the treaty, proposed dividing the territory into several new states including Metropotamia, Polypotamia, Assenisipia and Cherronesus. Fortunately, he was overruled. Instead, over time, we got Ohio, Indiana, Illinois, Michigan and Wisconsin.


• While he was president, Jefferson had an open door policy. He let it be known he would answer any letter from any citizen and he was true to his word. He answered, in his own hand, literally thousands of letters from ordinary people and he kept copies of all his correspondence. The result is a lively record of what was on the minds of both the great men and ordinary people of his day.


• Although he was personally involved in adding the Old Northwest Territory and the Louisiana Purchase to this country, Jefferson wasn't satisfied. In 1812, he urged his friend James Madison to invade and "liberate" Canada. Jefferson and Madison expected to be welcomed by Canada's citizens. They neglected to consider the large population of loyalists who had emigrated from south of the Canadian border before, during and after the American Revolution. Even the French-speaking citizens of Quebec were not inclined to oust the British. The result was a disaster. The inexperienced American army was routed and within months the British invaded and burned Washington, D.C.

Thomas Jefferson was a leading light of the American Revolution and one of our greatest presidents. We have long admired him for his many deeds including writing the Declaration of Independence, building Monticello, and chartering the Lewis & Clark expedition. Recently, his image has been tarnished by his, to our eyes, profoundly inconsistent views on slavery. I guess this is human nature. We put our leaders high on a pedestal and then, every so often, we happily knock them off. But in Paul Johnson's hands, Jefferson emerges as a man in full. Johnson describes Jefferson's greatest achievements, his little inconsistencies, his most enduring ideas and his monumental mistakes. In the end, I am amazed not by Jefferson's inconsistencies (he was only human), but that a man of flesh and blood accomplished so much.
 

Web 2.0 Explained

You may have seen the term "Web 2.0" tossed around, but what does it mean exactly? In one context it appears to have something to do with Ajax. In another context it appears to have something to do with tags -- like tags in Flickr. It turns out it includes both ideas and much more. It's a grab bag of ideas supposedly driving a rebirth of the Internet.

This makes a dramatic narrative. "Web 1.0" rises from nothing in the mid-1990s. Amazon.com takes business from bricks-and-mortar stores. AOL buys Time-Warner. Every business is an e-business. Then, in 2001, it comes crashing down. We realize bricks-and-mortar stores still make sense. In fact, Wal-Mart has gotten very big indeed. Time-Warner executives wrestle control from the AOL upstarts. The Internet bubble is forgotten and everything is (mostly) back to normal.

Then, the narrative continues, "Web 2.0" rises from the ashes of "Web 1.0". Google and a half dozen smaller entities like Flickr and Wikipedia begin to redefine the Internet. Venture capital pours into hundreds of cool startups and the bubble begins to grow again. Hopefully, it doesn't grow too big, too fast. This version of the Web is actually useful.

But there are problems with this narrative. For example, is Ajax really all it's cracked up to be? Chris McEvoy wrote a spoof of Jakob Nielsen lamenting the problems of Ajax. Although it's a spoof, the arguments are compelling. For example:

Ajax breaks the unified model of the Web and introduce (sic) a new way of looking at data that has not been well integrated into the other aspects of the Web. With ajax, the user's view of information on the screen is now determined by a sequence of navigation actions rather than a single navigation action ... Even worse, URLs stop working: the addressing information shown at the top of the browser no longer constitutes a complete specification of the information shown in the window.

And in his excellent essay on Web 2.0, Paul Graham damns Ajax with faint praise:

Basically, what "Ajax" means is "Javascript now works." And that in turn means that web-based applications can now be made to work much more like desktop ones.

Google Mail, Google Maps and other Ajax applications are great, but are Ajax applications really going to replace desktop applications? What happens when I want to disconnect from the web? Don't get me wrong. I don't think Ajax is going away, but it will not single-handedly topple the desktop.

There are also problems with tags. And there are problems with Wikipedia. There are problems with all the social networking, new democracy technologies. Maybe it's just the sources I read, but it feels like "Web 2.0" is losing share to "Cynicism 2.0".

Near the end of his essay, Paul Graham says:

Google was a pioneer in all three components of Web 2.0: their core business sounds crushingly hip when described in Web 2.0 terms, "Don't maltreat users" is a subset of "Don't be evil," and of course Google set off the whole Ajax boom with Google Maps.

Web 2.0 means using the web as it was meant to be used, and Google does. That's their secret. The web naturally has a certain grain, and Google is aligned with it. That's why their success seems so effortless.

In the end, Google is not an Ajax company. They are not even a search company. Right now, their biggest source of revenue is selling advertisements. They are successful because of the value they provide to their customers. The technology they use is only a means to that end. If the "Web 2.0" startups don't absorb that simple lesson, they are doomed to fail.
 

Iraqi Elections

Tomorrow, Iraqi citizens will take another big step toward democracy when they vote to seat members of their new parliament. Undoubtedly, the U.S. media will take a break from the usual body count and "who knew what when" to admit that perhaps, after all, there is promise in Iraq's future.

Meanwhile, there are bloggers who remind us of that promise every day. Michael Yon is one blogger who regularly posts good news from Iraq. I am particularly impressed by a photo essay he posted last month. I'll get to the photo essay in a minute, but first take a few moments to clear your mind. Forget WMD, "blood for oil", the Al Qaeda connection and so on. Those arguments are all relevant certainly, but they are also old news. Regardless of how we got there, we are in Iraq now. If we leave too soon, we risk the total collapse of a fragile democracy. And we'll have broken a promise to our allies.

If you want to meet our allies, see Michael Yon's photo essay.
 

Bloglines

I finally got around to trying Bloglines last week. It's great! I realize this is not news to my techie friends, but I want to spread the word to the less techie readers of Runtime Log.

Bloglines is a FREE web-based service that watches for new posts on multiple blogs. It keeps track of new posts so you don't have to constantly visit your favorite blogs only to be disappointed when there's nothing new. It's especially useful for monitoring blogs with infrequent or sporadic activity.

The heart of Bloglines is the nifty outline shown in the picture. It lets you organize blogs by category. Blogs (or categories) with new activity are shown in bold type, with the number of new posts in parentheses. To read new posts, you simply click on the outline entry. When you do this, Bloglines shows just the new posts in a separate frame.

Reading a blog with Bloglines causes it to be marked as completely read, but you can remember a post you want to get back to by checking a box labeled "Keep New". In the picture above, I have marked two Software Development posts as "Keep New". This is indicated by the numbers in gray parentheses.

If you read lots of blogs, Bloglines is a great way to organize them and save time. And if you have your own blog, you should look at it with Bloglines too. It will look slightly different. You might be interested in how some of your readers are seeing your blog.
 

Form Follows Function

For the past several weeks, I have been working on an API at work. The first step was to design the API and have it reviewed by other software architects. I was surprised by how much time we spent debating the mere form of the API. For example, we argued a lot about whether to use interfaces or classes for value objects, but comparatively little time discussing the function of the API. I am not saying the interfaces vs. classes debate is not important, but often the argument was, "By convention, all value objects must be defined as interfaces (or classes)." In other words, it was a case of form for form's sake. The argument was not grounded in the function of the API.

Now that I have moved from design to implementation, I am noticing another kind of tension. As developers begin to use the emerging API, they make enhancement requests. Often these requests are to add a method that is outside the scope of the API, or worse, to make an existing method do some additional work that isn't obvious from the method definition. As an example, I've had several requests to make methods aware of the User Interface (UI) context, but this is an API for accessing data and metadata. None of its implementations should introduce side-effects in the UI unless all of them can guarantee the same behavior. I think it is important to keep the API contract as simple as possible, so I generally decline such requests.

It strikes me the answer to both kinds of debates is the same: "Form follows function." This phrase first gained currency in the discipline of building design. The late 19th century architect, Louis Sullivan, and his disciple, Frank Lloyd Wright, were its most famous proponents. The phrase is sometimes misinterpreted as a statement of precedence. In other words, it is interpreted as, "function precedes form," but that's not really the idea. Rather, Sullivan and Wright were reacting against the conventions of the day. They thought it was silly to build Renaissance train stations, Greek Classical post offices, and English Tudor homes. There were against ornamentation for ornamentation's sake. As Wright said, "Form and function should be one, joined in a spiritual union."

"Form follows function" has been applied to lots of other design activities besides building design. I actually haven't heard it used in reference to the design of an API, but I think it makes sense. It carries with it two important ideas. When designing an API, you should:

1. Resist unecessary ornamentation. Some conventions are certainly of universal importance, but others should be applied in only some circumstances and some are mere fads. Each convention should be tested against the function of the API. Does it really make sense in this context?
    
2. Make each method as explicit as possible. To improve the usability of your API, give each method a descriptive name and make it do what it says -- no more, no less. Avoid the temptation to have methods cause side-effect in other parts of the system. This is particularily important for APIs that will have multiple implementations.

Next time someone tells me I must always use interfaces for value objects or I must follow some other such convention, I'm going to say I heard differently from a famous architect. "Form follows function." I heard it from Frank Lloyd Wright.
 

December - January Issue of Striding Along

There's a new issue of the Gate City Striders newsletter on the web. This issue includes a description of the Boston Marathon "bypass" process for club members, news about about the Freeze Your Buns winter race series, cold weather running tips, a glimpse at the 2006 New Hampshire Grand Prix calendar, and more. It is also my first issue as ex-newsletter editor. I think the new editor, Bill Farina, is doing a great job.

See it all on the newsletter page.
 

John Vlissides Remembered

John Vlissides, perhaps best known as a co-author of Design Patterns, passed away last Thursday after a lengthy illness. Many of his colleagues are using his Wiki page to share stories about working with Vlissides. If you have read Design Patterns or any of his other works, you may be interested in reading about the human being behind the words. By all accounts he was as humble and generous as he was brilliant.

(via Bjorn and Ward)
 

Erich Gamma on Shipping Software

In part five of a series of interviews at Artima Developer, Erich Gamma talks about Eclipse's culture of shipping software. He talks about six week milestones, transparent planning, constantly "eating your own dog food", and the controlled end game. This is all very familiar. It is almost identical to the Notes development culture at Iris Associates.

There are at least two important differences. Notes release cycles were historically much longer than those of Eclipse. And Notes never was an open source project. However, these differences just highlight the importance of the common themes. If I had to pick one, I'd say the most important is "eat your own dog food". There are lots of different strategies for quality assurance. Nothing compares with running your business on the product you are building.

(via Jeff Atwood, at Coding Horror)
 

Knit Wits and Sports Nuts

My sister-in-law, Patty, has been blogging at PurlySpaniel for a few months. Now I've discovered my sister Deirdre has a blog too. Dee's blog is Knitter from Keene.

Both blogs are mostly about knitting, but they are more than that. For example, I really like Patty's post about knitting and baseball:

They statistically break down anyone who looks like the player, has a name like the player, once played with the player and who has the potential to play with the player. And while this happens my head is spinning and I am knitting. Baseball has been very, very good to me. They watch, I knit. Everyone is happy

I can relate. Although I grew up in a sports crazy household, I've only become interested in sports recently -- mostly because my sons are sports nuts. I guess the "sports crazy" gene sometimes skips a generation. I'm still not a sports nut, but at least now I'm not completely lost when the talk at family get-togethers turns to the Sox, Celts and Pats.

Happy Thanksgiving, everyone. Bring on the sports talk. I won't even try to keep up when the talk turns to knitting.
 

Now Close the Windows

Now close the windows and hush all the fields:
If the trees must, let them silently toss;
No bird is singing now, and if there is,
Be it my loss.

It will be long ere the marshes resume,
I will be long ere the earliest bird:
So close the windows and not hear the wind,
But see all wind-stirred.

-- Robert Frost, from A Boy's Will
 

Beta Testing Considered Harmful

Joel Spolsky warns about the dangers of large-scale software beta testing. He calls it "shipping early and often":

Does ship-early-and-often really work for a huge company doing massive PR pushes that's going to get millions of people checking out their early release?

I don't think it does. This is a classic example of what I've always called the Marimba Phenomenon. The Marimba Phenomenon is what happens when you spend more on PR and marketing than on development. “Result: everybody checks out your code, and it's not good yet. These people will be permanently convinced that your code is simple and inadequate, even if you improve it drastically later.”

As usual, Joel singles out Microsoft when he could just as easily be talking about any large software company. He also adds a plug for small companies (like, for instance, his small company). And he doesn't mention big company Beta success stories. For example, the Google Mail Beta has generated lots of positive buzz for Google.

However, by and large, I agree with Joel. Software companys would do well to heed his warning.
 

Book Review: The Kite Runner

Kahled Hosseini's The Kite Runner is a wonderful book. It's the story of a close-knit Afghan family from Kabul. It follows the family from before the 1979 Russian invasion of Afghanistan, through twenty years of exile in America, and back to the Taliban's hell on earth in 2001.

The story begins in the 1960s, when Afghanistan was a relatively peaceful developing country. The author initially focuses on the friendship between Amir, a wealthy Pashtun boy, and Hassan, his Hazara servant. Although such a friendship is unlikely in the class-conscious and sectarian Afghan culture, Amir and Hassan share a close bond. Hosseini beautifully captures their days spent roaming Kabul, going to the cinema to see American and Pakistani films, playing "Cowboys and Indians", and flying kites. Just below the surface, however, there is tension. Amir is the more privileged of the two, but he is jealous of Hassan. Without understanding his own actions, Amir rejects Hassan. Shortly after, the Russians invade Afghanistan, Amir's family escapes to America, and the two friends are apparently separated for good.

Hosseini devotes the "second act" of the book to Amir's exile in California's Silicon Valley. This part is also compelling and wonderfully told, but the "third act" is the most memorable. In 2001, the now 38 year old Amir is summoned back to Afghanistan. He secretly re-enters his country, sees the destruction wrought by twenty years of war, and bears witness to the tyranny of the Taliban. It's a heartbreaking and terrifying passage, but Amir sees it as the only way to redeem his past.

Although the story focuses on Amir, it is filled with fully realized Afghan characters including Amir's father (or Baba), his friend Hassan, his "uncle" Rahim Khan, his wife and in-laws, and many more. I think the book gives you a real appreciation of traditional Afghan culture, the tragedy of the Russian invansion, and the ruthless reign of the Taliban.

The Kite Runner is a story of personal redemption, but it is also unmistakably an allegory for the redemption of Afghanistan itself. Having read the book, I am proud of the role America played in ousting the Taliban and hopeful about the country's future. Salaam Alaykum, Afghanistan. Peace be with you.
 

Visual Studio vs. Eclipse

According to an internetnews.com story, Microsoft is making some outgageous claims about the cost of Eclipse:

Repeating the Microsoft mantra that "free is not really free," [Microsoft's BJ Holtgrewe] showed that while the basic development environment for Eclipse is free versus a basic Visual Studio 2005 license, which costs $8,200, the cost of using Eclipse increases as users tap into load testing and other advanced features.

When he added it up, the cost of using VS 2005 was over $30,000 versus more than $100,000 for Eclipse-based applications.

That's crazy, but Mike Milinkovich of the Eclipse Foundation thinks it is The Highest Compliment. When Microsoft (or any big company) aims it's FUD arsenal at you, you know you've arrived.
 

Wallace and Gromit

Last night we saw Wallace & Gromit: The Curse of the Were-Rabbit. As others have said, it is a great family film. It is nearing the end of its run in in my local theater. If you haven't seen it already, you may be running out of time to see it in a theater.

As great as Were-Rabbit is, I think The Wrong Trousers is a better film. The action sequences in the older film are ingeniously inventive. I've never seen anything as good. You can see The Wrong Trousers and two other short films by renting Wallace & Gromit in Three Amazing Adventures.
 

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.
 

Bush Invented the Internet

Call me old fashioned, but the other day I was browsing the shelves at my local library. I picked up a book called What the Dormouse Said, by John Markoff. The subtitle of the book is "How the 60s Counterculture Shaped the Personal Computer Industry". According to the publisher's web site:

While there have been several histories of the personal computer, well-known technology writer John Markoff has created the first ever to spotlight the unique political and cultural forces that gave rise to this revolutionary technology. Focusing on the period of 1962 through 1975 in the San Francisco Bay Area, where a heady mix of tech industries, radicalism, and readily available drugs flourished, What the Dormouse Said tells the story of the birth of the personal computer through the people, politics, and protest that defined its unique era.

Although I had to put it down after the first chapter, it is fascinating stuff. I will get back to it eventually.

One premise in the first chapter impressed me most of all. Markoff traces the beginning of personal computing to 1945 -- specifically to an Atlantic Monthly article called "As We May Think". The author, Vannevar Bush, begins the article with a question:

[World War II] has not been a scientist's war; it has been a war in which all have had a part. The scientists, burying their old professional competition in the demand of a common cause, have shared greatly and learned much. It has been exhilarating to work in effective partnership. Now, for many, this appears to be approaching an end. What are the scientists to do next?

Bush alludes to the necessary role scientists played in unleashing "strange destructive gadgets" during the war and challenges his colleagues to turn to more peaceful pursuits. After cataloging the technologies available in his day -- cutting-edge stuff like miniature cameras, microfilm and punch cards -- Bush proposes a concept called the "memory extender" or memex. According to Bush:

It consists of a desk, and while it can presumably be operated from a distance, it is primarily the piece of furniture at which [one] works. On the top are slanting translucent screens, on which material can be projected for convenient reading. There is a keyboard, and sets of buttons and levers. Otherwise it looks like an ordinary desk.

In one end is the stored material...Most of the memex contents are purchased on microfilm ready for insertion. Books of all sorts, pictures, current periodicals, newspapers, are thus obtained and dropped into place. Business correspondence takes the same path. And there is provision for direct entry. On the top of the memex is a transparent platen. On this are placed longhand notes, photographs, memoranda, all sorts of things.

He goes on to describe how the owner of a memex recalls material and makes links between references. Although there are lots of differences, the whole concept is remarkably similar to how we use personal computers and the Internet today. It's amazing Bush dreamed it all sixty years ago.

Interested in more? To whet your appetite, take a look at this animation of what the memex might have been. And you can read the entire Atlantic Monthly article online too.
 

October - November Issue of Striding Along

There's a new issue of the Gate City Striders newsletter on the web. This issue includes coverage of last weekend's Lake Winnipesaukee Relay, a Fitness University wrap-up, previews of upcoming races, "clippings" from the Striding Along archives, a ton of race results and more. See it all on the newsletter page.
 

How to Pronounce Worcester

In response to this post on Bob's blog, some people have been commenting on the correct way to pronounce Revere, Gloucester, and other Massachusetts town names. Bob posted a link to How to Pronounce Massachusetts Town Names. I think it's mostly accurate.

But Worcester is not pronounced WOO-STAH. The correct way to say it is WIS-TAH. That's how people in GAAD-NA say it.
 

Book Review: Absolute Friends

Absolute Friends, by John le Carré, is a well written, gripping, ultimately infuriating book. It's the story of two friends: Ted Mundy, a British boomer born in Pakistan at the time of Partition, and Sasha, a radical German gadfly.

The book is roughly divided into thirds. The first part follows Mundy from birth, through a meandering adolescence, to the time he first meets Sasha in a 1960s West Berlin commune. Sasha is the intellectual leader of the commune. Mundy is a chameleon, trying on different ideologies. Although polar opposites, Mundy and Sasha form a strong bond. They are abruptly separated when one of their student demonstrations ends in violence.

The middle third of the book starts more than ten years later when Sasha reappears to draw Mundy into the Cold War espionage game. Somehow Sasha has become a member of the East German Stasi machinery. He enlists Mundy for a complicated double spy operation. I won't tell you who is really spying for whom.

The third act finds Mundy and Sasha together again after another separation of ten years. Both have been drifting since the Cold War ended, but Sasha has found a new patron, a mysterious billionare named Dmitri. Many reviewers have said Le Carré falters in this part of the book. Oddly enough, I think it is the most compelling part. The first and second parts are masterful set pieces describing 1960s West Berlin and Cold War espionage respectively, but the last part picks up the pace considerably. Mundy is drawn into a plot murkier than anything he experienced during the Cold War. Who is Dmitri? Is his scheme a front for a terrorist operation? Does Sasha know more than he is telling?

It's great stuff -- up until the last ten pages. I won't give away the ending, but it comes out of left field. Le Carré apparently contrived the ending to warn the dear reader about the true menance in our post-9/11 world. And Le Carré's politics are definitely left of center, if not left of Michael Moore.

Some reviewers have cited Le Carré's bias in dialog like this about the War in Iraq:

"It was an old Colonial oil war dressed up as a crusade for Western life and liberty, and it was launched by a clique of war-hungry Judeo-Christian geopolitical fantasists who hijacked the media and exploited America's post-9/11 psychopathy."

You certainly can't assume Le Carré believes that line of dialog. If he does, he picked a strange mouthpiece. The character who recites the line doesn't even believe it. However, throughout the book Le Carré implies that American leaders, particularly Christian American leaders, are the real extremists. And he certainly believes it is now Europe's duty to counter the world's lone superpower.

All in all, Absolute Friends is a brilliant book -- well worth reading. I just think Le Carré is worried about the wrong bogeyman. But I have the benefit of hindsight. Le Carré's book was originally published before the terrorist bombings in Madrid and London.
 

Caution: Service Oriented Architects Ahead

The big IT players are all making a big deal about Service Oriented Architecture (SOA). Apparently SOA is the next gold rush. IBM, Microsoft, Oracle, and others have each staked a claim. The preceding links take you to the SOA welcome center for each company.

But what is SOA really? Is it, as Microsoft's Pat Helland asserts, the next step in the evolution of IT infrastructure? Or is it a swing of the pendulum -- a reaction to the shortcomings of Object Orientation? Or is it yet another attempt to wish away the essential difficulties of software development?

Don't get me wrong. I think there is a lot of value in Service Orientation. I also think there is a lot of value in Object Orientation. Both have their place. Neither is a panacea.

For more healthy skepticism, read Martin Fowler's Service Oriented Ambiguity and David Ing's Dude, Where's My SOA?.
 

Measure Running Routes with Google Maps

Google Maps is only about seven months old but it has spawned a host of cool mapping applications. Damien mentioned one recently. The Google Maps Mania blog has links to dozens of other apps.

Here's an application that's great for runners. Gmaps Pedometer lets you measure the distance of any running route. As you trace your route, it automatically places markers at one mile increments. Best of all you can turn your route into a "Permalink". Click on Permalink and then bookmark the page for future reference. It's pretty incredible the whole route can be encoded in a URL.

Here's a Permalink for Leg 6 of the Lake Winnipesaukee Relay. I'm going to be running leg 6 this year. Now I know approximately where the mile posts are.
 

Geek Runners

Is it just me or are lots of runners real geeks? Many runners I know are into gadgets. Some of them have been using heart rate monitors for years. These devices let you continually measure your heart rate during a run. If you are running too hard and you exceed your target heart rate, you can adjust your pace. Increasingly these devices include a GPS or other technology for measuring distance. Now you can continually track your pace and cumulative distance while you're running.

I have never been into extreme gadgetry, but I have kept a running log for a few years. I use the online log at Cool Running to record the distance of each run. The Cool Running log lets me keep track of my mileage for the week, month and year. Even better, it lets me keep track of how many miles I put on a pair of running shoes. Replacing shoes before they are too worn out is a key tactic for avoiding injuries.

There are lots of other online running logs besides the Cool Running log and there's plenty of desktop software for the same purpose. Now apparently many runners are using blogs to log miles, keep in touch with training partners, and wax philosophical about the act of running. The Running Blog Family Directory lists more than three hundred running blogs.

I've been browsing some running blogs lately. For me, one blogger stands out as the Ultimate Geek Runner (I mean that in a good way). Dave at Runningland has come up with a system for automatically uploading runs from his GPS watch and using Google Maps to display each run on his blog. Click here now for a sample of the result. Amazing.

Here's how Dave did it:

I wrote some Perl code to periodically check to see if I’ve cradled the watch in the charger. If it is detected, the most recent runs are exported using GPSBabel from the watch and converted to the Garmin logbook format and the Keyhole Markup Language (KML) for viewing in Google Earth. It then uploads the files to the appropriate directory on the web server. This allows me to simply insert the watch into the charger and simply go about my business. No buttons to push or programs to bring up. The next time the script runs I know the data from the watch will be processed.

On the web server, a process runs daily to produce the HTML file with my latest runs from the watch. It also creates an RSS feed of the most recent runs.

Is it just me or is that too cool?
 

New Blogs

As you may have read elsewhere, Matt Hatem is blogging. I just discovered that Sami Shalabi and Maureen Leland are blogging too. Welcome, one and all!

The list of ex-Iris folks with active blogs is getting longer. In addition to the above, it includes Bob, Brian, Damien, Joe, Kudla, Ned, and Pete. Have I forgotten anyone?

I realize, of course, that Ray Ozzie has a blog. Unfortunately, Ray hasn't posted anything since March 2004.
 

Labor Day Parade

Labor Day is not typically associated with parades, but the Milford, New Hampshire Labor Day Parade is a long-running tradition. It's mostly about amateur floats, local marching bands, and antique cars. In an election year, there are lots of politicians there too.

This year the only politician in attendance was New Hampshire Governor John Lynch. Next year we'll see a dozen or more politicians running for local, state and federal offices. Two years from now, the parade will include a gaggle of presidential candidates preening for the first-in-the-nation primary voters.

Here are some photos from this year's parade.


Fire Trucks. The noise from the horns and sirens was deafening.


Governor John Lynch and Family.


Bagpipers.


Bektash. I don't know anything about Bektash, but the kids love these guys.


Local Civil War Re-Enactors.


Oktoberfest Band.
 

Live from New Orleans

In the wake of Hurricane Katrina, New Orleans has seen flooding, loss of electricity, looting, and shortages of food, fuel, and potable water. This morning fires broke out around the city. Somehow The Interdictor is blogging through it all. He and his crew are camped out at the directNIC data center in the heart of New Orleans. They are managing to keep the data center running, and at the same time, they are posting first hand reports and lots of pictures. It is a great source of (mostly) unfiltered news.

(via Ned)
 

$3.09 and Other Horrors

On the way home last night, I paid $3.09 per gallon for a tank of mid-grade gas. I think the price had jumped 20 cents from earlier in the day. What a pain, but pictures of the devastation from Hurricane Katrina surely put things in perspective.

Some experts are saying the nationwide average price for a gallon of gas could easily reach $4.00 soon. I understand the price of crude is rising and Katrina has reduced our refining capacity, but it still feels like OPEC and Big Oil are making a killing. Meanwhile, tens of thousands of people in Louisiana and Mississippi have lost everything. Maybe I'll work at home for the rest of 2005 and send what I would have spent on gas to the American Red Cross.
 

Work vs. Progress

In Work vs. Progress, Scott Berkun writes about the difficulty of measuring progress in software development and other creative activities. We all know hours worked, lines of code, and other simple metrics don't really measure progress. Managers depend on such metrics only because the alternative is wicked hard.

Berkun outlines some smarter approaches to setting goals and measuring progress, but there is no silver bullet. Each software project has its own challenges, constraints and personalities. A good manager has a bag of tricks, but must adapt to the situation at hand. On this blog, I have often complained about short-sighted managers, but I haven't often acknowledged this simple fact: Software project management is an extremely difficult job. It is easy for software developers to complain about bad managers, but few of us could do a better job.
 

Franconia Notch State Park

Lonesome Lake


Alpine Zone


Franconia Notch
 

Spam Bites Blog

Over the past few days, this blog has been hit by spammers who post unrelated comments to specific posts. I have removed most of the spam, but here's an example:

='Brand New News Fr0m The Timber Industry!!'=

========Latest Profile==========
Energy & Asset Technology, Inc. (EGTY)
Current Price $0.15
================================

Recognize this undiscovered gem which is poised to jump!!

Please read the following Announcement in its Entierty and
Consider the Possibilities�
Watch this One to Trad,e!

[... and so on ...]

I am currently using the basic Blogger comments feature. I suppose this means I will have to replace it with comments from SquawkBox.tv or some other source. I'm open to suggestions. Please post a comment if you have some relevant advice. Of course if it's spam, I'll just delete it.
 

Ethics and Software Development

Mr. Ed has posted another thought provoking essay on Hacknot. The Crooked Timber of Software Development asserts that software development is more of an occupation than a profession:

The key concept in any profession is that of integrity. It means, quite literally, "unity or wholeness." A profession maintains its integrity by enforcing standards upon its practitioners, ensuring that those representing the profession offer a minimum standard of competence. Viewed from the perspective of a non-practitioner, the profession therefore offers a consistent promise of a certain standard of work, and creates the public expectation of a certain standard of service.

In other words, unlike the medical profession, we have no residency system, licensing board, or code of ethics. Therefore software development is not a real profession.

I suspect Mr. Ed is using a rhetorical flourish to make his point. In any case, I don't agree there is one standard for all professions. Software development, as a profession, is certainly at a much earlier stage in it's evolution than medicine. But I do agree with his main point:

If we are ever to make a profession of software development, to move beyond the currently fractured and uncoordinated group of individuals motivated by self-interest, with little or no concern for the reputation or collective future of their occupation, then some fundamental changes in attitude must occur. We must begin to value both personal and professional integrity and demonstrate a strong and unwavering commitment to it in our daily professional lives.

Mr. Ed closes with the story of David Parnas, a software developer who resigned from the Department of Defense over his objections to the Strategic Defense Initiative (SDI). There might be a hint of politics masquerading as ethics in Parnas's story, but you can't argue with his code of ethics:

• I am responsible for my own actions and cannot rely on any external authority to make my decisions for me


• I cannot ignore ethical and moral issues. I must devote some of my energy to deciding whether the task that has been given is of benefit to society.


• I must make sure that I am solving the real problem, not simply providing short-term satisfaction to my supervisor.

Good stuff.
 

Contestants Making Brownie Points

In the early 1970s, the prophet Dr. Brooks wrote this about a major software development project:

The project was large enough and management communications poor enough to prompt many members of the team to see themselves as contestants making brownie points, rather than as builders making programming products. Each suboptimized his piece to meet his targets; few stopped to think about the total effect on the customer. This breakdown in orientation and communication is a major hazard for large projects.

If you are a student of human nature, it's no surprise the contestants are still at it. In some organizations, it is all about maximum visibility for minimum effort. The truly frightening thing is how far the tools for self-promotion have evolved since the 1970s. These days contestants wield PowerPoint presentations, electronic mail, and instant messaging in their quest for maximum visibility. There's nothing wrong with Joe Programmer using such tools to communicate, but in some cases, he should be spending more time with his favorite IDE.

Of course, the above quote is from The Mythical Man-Month. Having stated the problem, Dr. Brooks begins framing the solution in the very next sentence:

All during implementation, the system architects must maintain continual vigilance to ensure continued system integrity. Beyond this policing mechanism, however, lies the matter of the attitude of the implementers themselves. Fostering a total-system, user-oriented attitude may well be the most important function of the programming manager.

In other words, when a software project is in trouble, it is ultimately not the fault of individuals who "suboptimize". It is the architect's job to monitor the integrity of the system and the project manager's job to foster the right attitude. This is a classic system of checks and balances. It may be human nature for developers to minimize effort, but in a healthy organization, the leadership encourages and rewards behavior that results in a better product.

The above quotes come from Chapter 9, Ten Pounds in a Five-Pound Sack. In this context, Dr. Brooks was describing how to safeguard performance when developing large systems. He might just as well been describing how to safeguard the health of a development organization. Only a dysfunctional organization allows a developer to choose building a better career over building a better product. In my opinion, the only way to build a better career should be by building a better product first.
 

Disintermediate Cutting-Edge Schemas

Yesterday, my co-resources and I were having fun with the Web Economy BS Generator. This inventive little web-toy automatically generates meaningless marketing phrases like "maximize front-end web-readiness", "whiteboard compelling initiatives", and "generate magnetic interfaces".

But truth is stranger than fiction. This morning I googled a few of these phrases. It turns out a company named Intisoft really does enable collaborative e-business. And an Arthur Anderson report really does recommend that your company disintermediate customer relationships. I am almost certain 90s Web hasn't really been "orchestrating e-business to e-business e-business since 1995", but it's difficult to separate parody from unintentional self-parody.
 

Wilton Town Hall Theater

The Wilton Town Hall Theater is a Southern New Hampshire treasure. It is a very small movie theater with two screens. Most of the year they show foreign and independent films. During the summer they usually show at least one blockbuster to help pay for the rest of the year.

Yes, the theater really is in the town hall. The box office entrance is right next door to the town offices. Ticket prices are $5 and $3. As you walk to your seats in the main theater, the wooden floor boards creak. It feels like you are stepping back in time. When the vintage "Previews of Coming Attractions" reel plays, the effect is complete. You have traveled back to 1965.

I haven't been able to find the details on the web, but in addition to running current films, the Wilton Town Hall Theater also offers free Saturday matinees of film classics. This Saturday, the free feature is This Gun for Hire, a 1942 film noir starring Alan Ladd and Veronica Lake.
 

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.