A Lesson in Writing from 1944

I watched the Presidential debate tonight. One of the candidates mentioned a pair of letters that General Dwight David Eisenhower wrote in 1944. He wrote one letter that he would use in the event of a victorious Normandy invasion, and he wrote another one that he would use in the event of a defeat.

I was curious about those letters, so I googled for them. I found something interesting in a way that I didn't expected. Here's the text of the letter that General Eisenhower wrote in case the invasion force at Normandy had been defeated:

Our landings in the Cherbourg-Havre area have failed to gain a satisfactory foothold and I have withdrawn the troops. My decision to attack at this time and place was based on the best information available. The troops, the air and the Navy did all that Bravery and devotion to duty could do. If any blame or fault attaches to the attempt it is mine alone. —July 5

Here is a picture of the handwritten note, which I found at archives.gov:



The handwritten note contains some important information that isn't present in the transcribed text alone. Observe that General Eisenhower edited his message. He actually edited himself three times; I'll refer here only to the top one. Here's the original version:

Our landings in the Cherbourg-Havre area have failed to gain a satisfactory foothold and the troops have been withdrawn.

Here's the modified version:

Our landings in the Cherbourg-Havre area have failed to gain a satisfactory foothold and I have withdrawn the troops.

The difference is subtle but important. In grammatical terms, General Eisenhower made the choice to discard passive voice and adopt the direct, subject-verb-object style of active voice. One Wikipedia article that I particularly admire identifies passive voice as a tactic of weasel wording: "Weasel words are usually expressed with deliberate imprecision with the intention to mislead the listeners or readers into believing statements for which sources are not readily available."

In Eisenhower's original version, he had stated that "the troops have been withdrawn." From this statement, we would have learned some information about the troops, but we would not have learned directly about who had withdrawn them. This passive-voice language, "the troops have been withdrawn," would have subtly conveyed the notion that the author wished to conceal the identity of the decision-maker about the withdrawal.

In the modified version, General Eisenhower made it abundantly clear who had made the decision: he did. The revised wording is more informative, it is more efficient, and it is more courageous.

Active-voice writing holds several advantages over passive-voice writing. I've learned this in my work, especially in consulting engagement reports, where I've found it's essential to write with active voice. Advantages of active-voice writing include:

• Active voice transmits more information to the reader.
• Active voice is plainer and simpler; it is easier to read.
• Active voice is often more economical; it conveys as much or more information in fewer words.
• Active voice is often more courageous.

The value of courage is obvious in the Eisenhower case. Even if the Allies had been defeated at Normandy, Eisenhower was courageous enough to accept the responsibility for the plan, its execution, and even its remediation.

Courage is also important in our writing about technology. Writing with active voice can be much more difficult than writing with passive voice. ...Because, you see, active voice gives you noplace to hide. When you know something, you say it. When you don't, active voice writing pretty much forces you to say that. It can be quite unsettling to admit to your audience that you don't know everything you wish you knew. It takes courage.

If you find yourself ashamed that your writing is too vague or that it asks more questions than it answers, then I think you have only four choices. (1) You can decide not to write anymore because it's too hard; (2) You can try to conceal your deficiencies with weasel wording; (3) You can admit the gaps in your work; or (4) You can improve the quality of your own knowledge.

Of course, I don't believe that giving up is the right answer. Option two—concealing your deficiencies with weasel wording—is, I think, by far the worst option of the four. Choice three frightens a lot of people, but actually it's not so bad. I believe that one of the great successes of the modern wiki- and forum-enabled Internet is the ease with which an author can voice unfinished ideas without feeling out of place. The fourth option is a fantastic solution if you have the time, the inclination, and the talent for it.

Back to General Eisenhower's note... I find his edit inspiring. By making it, he reveals something about his thought process. He wrote his original text in the common, politically safe "tasks have been executed" kind of way. But his edit reveals that it was especially important to him to be direct and forthcoming about who was making the decisions here, and who was at fault in case those decisions went wrong.

Knowing that General Eisenhower edited his note in the particular way that he did actually makes me respect him even more than if he had written it in active voice in the first place.

* * *

Here's where I thought I was finished for the evening. But I want to show you what it looks like to execute faithfully upon my own bitter advice. Eisenhower's letter piqued my interest in the D-Day invasion of Normandy. One thing I noticed is that the invasion was initiated on June 6, 1944. Eisenhower's memo is dated "July 5." Uh, that's a month after the invasion, not the night before. It was another hour or so of writing lots more stuff (which I've long since deleted) before I googled "eisenhower message june july" and found this, which states simply that, "The handwritten message by General Eisenhower, the In Case of Failure message, is mistakenly dated 'July' 5 instead of 'June' 5."

Ok. I can accept this as authoritative for my own purposes, for one, because it doesn't matter too much to me tonight if it's not true. It's a plausible mistake to imagine a man making who's under as much pressure as he would have been on June 5, 1944. For comparison, I could barely remember my own phone number on the night of the Loma Priete earthquake, which I rode out in the Foster City Holiday Inn in 1989. But of course, such an anecdote about me is no proof of this particular proposition about Dwight D. Eisenhower.

So, do you see what I mean when I say that writing is HARD!? The act of writing itself—if you try to do it well—forces you to do work that you never intended to do when you set out to write your piece.

That's one of the good things about the software industry. When someone makes a statement about computer software, I can confirm or refute the statement myself using strace, DTrace, 10046, block dumps, or some other research tool that I can actually get my hands on. That doesn't make it easy, but it usually does make it at least possible.

Miracle Open World 2008 presentation

Have a look at the video abstract for my Miracle Open World 2008 presentation, "Millsap's Grand Unified Theory of 'Tuning'."

Business of Software 2008, day 2

Greetings from the second and final day of "Business of Software 2008, the first ever Joel on Software conference."

Yesterday was a hard act to follow, but today met the challenge. Today's roster:

• Steve Johnson, of Pragmatic Marketing
  
• Tom Jennings, of Summit Partners
  
• Richard Stallman, founder of Free Software Foundation
  
• Noam Wasserman, from Harvard Business School
  
• Mike Milinkovich, of Eclipse Foundation
  
• Steve Krug, author of Don't Make Me Think
  
• Joel Spolsky, of Fog Creek Software
  

Some of today's highlight ideas for me (again, with apologies to the speakers for the crude summarization):

• Nothing is difficult to someone who doesn't know what he's talking about. (Johnson)
• Creating more artifacts and meetings is no answer. (Johnson)
• Entrepreneurs are better entrepreneurs when they're not worried about their personal balance sheet. (Jennings)
• "In the software field, we don't have to deal with the perversions of matter." (Stallman)
• VCs say 65% of failed new ventures are the result of people problems with founding or management teams. (Wasserman)
• Websites are successful to the extent they're self-evident as possible. (Krug)
• Sensible usability testing is absolutely necessary and, better yet, possible and even inexpensive. You can even download a script at Steve's site. (Krug)
• The huge chasm between #1 and #2 is all about elements of happiness, aesthetics, and culture. (Spolsky)

Steve Johnson and Steve Krug gave truly superb presentations. Steve Krug I knew about beforehand, from his book. Steve Johnson I did not know, but I do now. These are people I'll take courses from someday. And of course, Joel Spolsky... I had seen him speak before, so I knew what to expect. He's one of the best speakers I've ever watched. I've asked him to keynote at Hotsos Symposium 2009. We'll see what he says.

Business of Software 2008, day 1

Greetings from Boston, where I'm attending "Business of Software 2008, the first ever Joel on Software conference."

It has been fantastic so far. Here's a featured presenters roll call for the day:

• Seth Godin, author of ten bestselling books about marketing
  
• Jason Fried of 37signals
• Eric Sink of SourceGear
• Dharmesh Shah of HubSpot
• Jessica Livingston of Y Combinator, author of Founders at Work
• Paul Kenny of Ocean Learning
  

That's not to mention the eight Pecha Kucha presentations, although I will mention two that I particularly enjoyed by Jason Cohen of SmartBear Software ("Agile marketing") and Alexis Ohanian, founder of Reddit ("How to start, run, and sell a web 2.0 startup"). Alexis won the contest, which netted him a new MacBook Air. Not bad for 6 minutes 40 seconds of work. ;-)

Here are some of the highlight ideas of the day for me (with apologies to the speakers for, in some cases, crudely over-simplifying their ideas):

• Ideas that spread win. (Godin)
  
• The leader of a tribe begins as a heretic. (Godin, Livingston)
• Premature optimization is bad. In business too. Not just code. (Fried, Shah)
• Interruptions are bad. Meetings are worse. (Fried, Sink, Livingston)
• "Only two things grow forever: businesses and tumors." Unless you take inelligent action. (Fried)
• Pricing is hard. Really, really hard. (Shah)
• Business plans are usually stupid. (Fried, Shah, Livingston)
  
• Software specs are usually stupid. (Fried)
  
• An important opportunity cost of raising VC money is the time you're not spending working on the business of your actual business. (Shah)
• The most common cause of startup failure isn't competition, it's fear. (Livingston)
• Your first idea probably sucks. (Fried, Sink, Shah, Livingston)
• Radical mood swings are part of the territory for founding a company. (Livingston)

An overarching belief that I think bonds almost all of the 300 people here at the event is this: If you're not working on your passion, then you're wasting yourself. It is inspiring to met so many people at one time who are living courageously without compromising this belief. Re-SPECT.

I think a good conference should provide three main intellectual benefits for people:

1. You can expose yourself to new ideas, which can make you wiser.
2. You can fortify some of the beliefs you already had, which can make you more confident.
3. You can learn better ways to explain your beliefs to others, which can make you more effective.

And then of course there's networking, fun, and all that stuff—that's easy. So far, this event is ringing the bell on every dimension that I needed. Absolutely A+.

Hotsos Symposium 2009 Call for Papers

The Call for Papers for Hotsos Symposium 2009 is now open. To submit an abstract proposal for the event, please visit the Call for Papers page. The call will remain open until 24 October. This is your chance to get your name on the agenda and earn a complimentary pass to the event.

I love the Symposium for the people who show up, both the speakers and the attendees. If you've been there, you know: it is the best event of the year for professionals interested in Oracle performance. It's one of the rare places that I can just sit down with a pencil and fill my notebook with answers to long-standing questions and good new ideas to pursue for the coming year.

We've already booked Jonathan Lewis for two technical sessions and the Training Day event, and Tanel Põder has confirmed his participation on the agenda as well. That makes two of my favorites, with lots more on the way.

You're probably aware that earlier this year, I left Hotsos with a few former employees to create Method R Corporation (see our press release for more info). Method R and Hotsos are pleased to continue the tradition of the Hotsos Symposium as a joint venture between our two companies. I hope you'll join us.

Messed-Up App of the Day

My family has a cat. I don't like to talk about it, because I really don't like cats that much.

One thing our cat does that's kind of interesting to me, is that she brings "gifts" into our garage near her food bowl. Here's a picture of one. She climbs to the tops of the trees in our yard to catch these things.



Jeff Holt does something similar on occasion. Sometimes when I return from a trip, there'll be something on my desk from Jeff for me. Today, it was this:



It's a piece of wire taped to a sheet of paper. And that's my Messed-Up App of the Day.

Handwritten on the paper is this message from Jeff:

This was a grounding cable for the network.

LMAO

The first few seconds I looked at the cable, it didn't seem that funny to me. It was about the same reaction as when I see a dead cicada next to the food bowl at home. Amused. But not "LMAO."

Sometimes, what Jeff thinks is funny is funny because of something I haven't learned yet. So I got thinking, maybe his point is that it's against code to use stranded copper wire as grounding cable. Most of the ground wire you'll find in houses is solid copper. But then again, no, stranded cable is fine for ground wire. If I remember correctly, you use stranded instead of solid wire in applications where the wire is going to be required to flex in normal operational circumstances.

Then I noticed there was red tape on one end of the wire, and black tape on the other. Ah, ok, that's what was funny--ground wires are supposed to be labeled green. I figured the guys who wired our network probably just used some scrap wire instead of properly marked "ground wire." Sometimes that kind of thing bugs Jeff, and he knows it bugs me, too. Mystery solved, then.

But not really "LMAO," though, when you think about it.

Then I picked up the wire and looked at it. Look at this:



Oh... It's not tape. That's two wires. One red, one black.

Ok, that's legitimately "LMAO."

P.S.: If you have trouble explaining to your friends why this is funny, the following handy diagram may help you.

So how do you FIX the problems that "Performance as a Service" helps you find?

I want to respond carefully to Reubin's comment on my Performance as a Service post from July 7. Reuben asked:

i can see how you actually determine for a customer where the pain points are and you can validate user remarks about poor performance. But i don't see from your post how you are going to attack the problem of fixing the performance issue.

i would be most interested in hearing your thoughts on that. I wonder if you guys are going to touch the actual code behind the "order button" you described.

Under the service model I described in the Performance as a Service post, a client using our performance service would have several choices about how to respond to a problem. They could contract our team as consultants; they could use someone else; they could do it themselves; or of course, they could choose to defer the solution.

Attacking the problem of fixing the performance issue is actually the "easy" part. Well, it's not necessarily always easy, but it's the part that my team have been doing over and over again since the early 1990s. We use Method R. Once we've measured the response time in detail with Oracle's extended SQL trace function, we know exactly where the task is spending the end user's time. From there, I think it's fair to say we (Jeff, Karen, etc.) are pretty skilled at figuring out what to do next.

Sometimes, the root cause of a performance problem requires manipulation of the application source code, and sometimes it doesn't. If you do diagnosis right, you should never have to guess which one it is. A lot of people wonder what happens if it's the code that needs modification, but the application is prepackaged, and therefore the source code is out of your control. In my experience, most vendors are very responsive to improving the performance of their products when they're shown unambiguously how to improve them.

If your application is slow, you should be eager to know exactly why it's slow. You should be equally eager to know, whether you wrote the code yourself or someone else wrote it for you. To avoid collecting the right performance diagnostic data for an application because you're afraid of what you might find out is like taking your hands off the wheel and covering your eyes when a child rides his bike out in front of the car that you're driving. There's significant time-value upon information about performance problems. Even if someone else's code is the reason for your performance problem (or whatever truth you might be afraid of learning), you need to know it as early as possible.

The SLA Manager service I talked about is so important because the most difficult part of using Method R is usually the data collection step. The difficulty is almost always more political than technical. It's overcoming the question, "Why should we change the way we collect our data?" I believe the business value of knowing how long your computer system takes to execute tasks for your business is important enough that it will get people into the habit of measuring response time. ...Which is a vital step in solving the data collection problem that's at the heart of every persistent performance problem I've ever seen. I believe the data collection service that I described will help remove the most important remaining barrier to highly manageable application software performance in our market.