Managing Product Development

I led a two-hour writing workshop this past weekend. The attendees ranged from a 9-year-old who says, “I LOVE to write,” to retired adults who are involved in community projects who hate to write. We performed two writing exercises. Although the writing is useful, it’s the debrief of each writing activity that helps each writer grow. The first exercise was to write for three minutes to introduce yourself and why you wanted to attend the workshop. Some people had trouble writing anything — even for only three minutes. When it came time to debrief, people first read their intros (where that fit for them), we offered gentle commentary, and if people dicussed a problem, I referred them to the handout, so they would have a printed reminder of some suggestions.

The most fascinating debrief came from the participant who didn’t write very much. She’d written a few phrases, and proceded to speak her intro. Now, as a professional speaker, I certainly appreciate speaking. But she was stuck. I interrupted her several times and finally was able to break into her (speaking) fugue. She has “almost” finished a book. She thinks she needs another chapter, but she was stuck. She couldn’t figure out how to finish the book. She told us why: There is no finishing this story. One of the other participants caught that and gently said, “That’s the ending.” She was unable to process those words into meaning. So I asked her to repeat what she’d just said about no ending, and I said, “Write that down.” Of course, she’s an extrovert (like me), so she had no idea what she’d just said. Luckily, of the other 12 or so people in the room, other people did remember. I insisted she write down the phrase and sit with it for a while to see if that’s what she needed to end the book. She might need a paragraph or two, but no more.

If you are the kind of person who needs to speak in order to think, you’re an extrovert. Take care with your speaking, because as soon as you’ve spoken the thought, it’s out. You no longer need to write it down. I use a number of aids, including a voice recorder, to avoid losing thoughts I need to write down.

Those of you who are innate writers: make sure you’re not writing over your gems. If you write everything, it’s hard for other people to see the gems you’ve written. Edit yourselves carefully. If you love some words, take them out and replace them with something else. If you’re like me, and want credit for everything you write, save those words in another file and take credit.

In the second exercise, each of us wrote down three of our favorite words on index cards, one to a card. I collected the index cards, shuffled them, and then everyone took three cards from the pile. Each of us had 5 minutes to write something using those cards. Some people created compelling short stories. Others created marketing literature. I got started on an article that’s been eluding me for months. One person wrote “garbage” (his words, not mine). Even when this activity doesn’t succeed by starting you on your way, you write something. And if the something isn’t so hot, you throw it out, because you’ve only spent 5 or 10 minutes on it. BTW, I don’t think he wrote garbage at all. I think he wrote a yucky first draft — I heard energy and the germ of an idea.

I’m always amazed that timed writing can be so successful. To me, it’s successful because you know you don’t have to stare at a blank page very long. Joel Spolsky in Joel on Software and on Diverse and Occasionally Related Matters… says on page 51 (about why people don’t write specs) “…so many people don’t like to write. Staring at a blank screen is horribly frustrating. … Writing is muscle. The more you write, the more you’ll be able to write.” Knowing I can write for a short time frees me from having to write the whole darn thing — and being scared that I won’t be able to do so. Timed writing is like a Hudson’s Bay Start.

We discussed how adverbs weaken verbs (from Stephen King’s On Writing), Anne Lamott’s idea (from Bird by Bird) of the (expletive deleted) first draft, and a bunch of other ideas from Naomi Karten’s and my writer’s workshop at AYE the past few years. And, I pointed people to Brian’s blog entry about editing.

We discussed one of the ideas in Brian’s entry, that of taping the piece to the wall and reading it through binoculars. I sometimes print my writing and look to see what it looks like. I look for shorter-than-normal paragraphs and longer-than-normal paragraphs. I like to keep a particular tempo in the piece — unless I want to shake people up with something out-of-tempo.

If you’d like to write — or write better, start. You can start short, with 5 or 10 minute timed writing. (Write for 5 or 10 minutes. Do not stop. Keep writing. If you get stuck, write blah, blah, blah, but keep writing.) Find someone who’ll review it. Or put it aside and read it later. I find I need at least 24 hours before I can read with a critical eye and a critical ear.

Writing is not an innate skill — even for you introverts. The more I practice, the better I write. You too.

Last week we held the AYE conference. Attending bloggers (in random order) were: Ron Pihlgren, Esther Derby, James Bach, Don Gray, Steve Smith, Tim Bacon, Rachel Davies, Dave Hoover, Dave Pickett, and Dave Liebreich. I hope I didn’t forget anyone.

One of the highlights for me was the writing workshop. We practiced several timed writing exercises. Timed writing works because if you don’t have a lot of time, the evil editor sitting on your shoulder keeps quiet. Without the editor, your passion comes through. What you write may not be of final draft quality — but that doesn’t matter. You’ve found the passion and the energy, so when you review, edit, and rewrite, you’ve got a wonderful piece. I use timed writing as an exercise frequently in my writing. It’s one technique I use to get started when I’m feeling un-creative.

Read “Everything You Need to Know About Writing Successfully - in Ten Minutes”, and when you’re done chuckling, note the necessary ideas:

• His point #5: throw away reference books. This works for all first drafts. I don’t care if you’re writing a novel, a spec, or code. It works. Interrupting flow and what do you have? Mistakes. Lots of them. Stay in flow and what do you have? Something that fits together — but is not necessarily done after the first draft. That’s fine. You don’t want something done after the first draft, because all writing requires
• His point # 3 and 4: being self-critical and remove every extraneous word. This is refactoring as you proceed, not waiting until you’ve already checked in the code, or asked for review. If you’ve done this and you’re stuck, fine, ask for help. But first read your own work and see what you can take out.

I highly recommend King’s On Writing if you’re thinking of writing anything. I have the hardcopy version, and it is one of the best investments I made in my writing.

Esther’s here this week (again), so we can finish the pre-review draft of the book. We’re telling the story of a great manager who’s just arrived to a new organization. We describe meetings ,where we wanted to say “Everyone nodded.” I wanted to add “like bobble-headed dolls.” While that’s humorous, it’s not very respectful to people caught in terrible meetings or in situations they can’t see their way out of — and they feel their only recourse is to nod like bobble-headed dolls. We changed the dialogue. (And, we’re trying to help people see alternatives.)

Esther and I have been editing the management book this week. We’re pairing to edit also - one keyboard, one file, two heads. It’s exhausting and fun. Here are things I’ve learned this week:

• We don’t have the same default ways to write — and that’s ok. The manuscript is richer for us talking through how the words should be.
• When we’re laughing out loud, we’re synching. Not quite in flow, but close.
• When one snaps at the other, it’s time for a break.
• The product is much better than it would be if we did the standard one-person-write/other-person-edit pass back and forth. We tried that. The writing is crisper. The word choice is better. The manuscript flows.

If you haven’t tried pairing yet, to create some form of intellectual property, consider it. I’ve paired for programming and for writing now. It’s fun. Exhausting and trying sometimes, but absolutely worth it.

Esther and I are working together this week, starting over again with the management book. This time, we’re pair-writing, and it worked surprisingly well today. We collaborate — and we have conflict, where the person at the keyboard says, “Oh no, I’m not writing that down.” However, we worked until about 5:30 today, when we were were exhausted, but have close to two chapters in first draft form. And, this first draft is far superior to the previous first drafts.

Writing English (or any other natural language) is different than writing code. In English, it’s not just the design of the writing that we discuss, it’s also the structure and the actual words. Computer languages are much more structured and very specific on how the language can be used. So we have more options for every decision. It’s a challenge, but it’s working. With any luck we’ll have more to share later this week.

In this issue of Better Software, I have the featured article, No More Second Class Testers! and Frank Patrick has a great article, “Promises and Prescriptions, How the Theory of Constraints can help cure common project ailments.” I can’t give you a URL to Frank’s article, but maybe in a month or so he’ll post the article on his web site, and you can see it then. Here are some gems (all quoted from the article):

• “Get rid of task due dates. The only dates that count are those promised outside the project.”
• “At the project task level, don’t allow yourself to be bullied into multi-tasking behaviors.”
• “Plan for the need to plan along the way.”

It’s a great article. I hope you read it.

Last week at the AYE conference, Naomi Karten and I facilitated a writing workshop. We ask people to write for five minutes and then for ten minutes. We find that people who are stuck on their writing make significant progress in five or ten minutes. However, we need to set our expectations low — very low — for a zeroth draft. We each took the challenge of writing on a subject of the attendees’ choice. I took on the “The Role of Footwear in Software Development.”

Here’s my zeroth draft on “The Role of Footwear in Software Development”

Earth shoes. Running shoes. Sandals. Hiking boots. Software developers wear all kinds of footwear, and all footwear has a common role.

Footwear for software people serves one simple purpose: to disguise the owners’ foot odor. You’d think that software people — people with desk jobs — wouldn’t necessarily smell. However in a surprising number of cases, they do.

Some software people forget to bathe. You might ask, “How could people who put a man on the moon, or create a clearinghouse for the Federal Reserve or manage your health insurance program have such a difficult time with such a basic skill?”

The answer is simple. Bathing is not an intellectually challenging task. Bathing is simple. Bathing is something you have to at home — not at work — so you have to be home to do it. Given the state of many software organizations, too many people aren’t home enough — at least — not long enough to bathe.

That was the end of my five-minute timed writing. As you can see, it took me a long time to figure out where I was going:

• that software people may not rank intellectually simple tasks at the same priority as intellectually challenging tasks, even though the “simple” tasks are just as necessary
• that the state of the project may create a situation where people can’t perform the most simple of tasks
• smelling your project is an indication that something might be wrong on your project.

The subsequent draft, the 10-minute timed writing, was nowhere near as funny, but started to link in the idea of code smells.

If you’re writing and having trouble, try timed writing. I find it a useful technique to extract that useful nugget so I can start writing the real work.

And, I now have a partial draft of an article that may be useful to project managers. When I finish it, I’ll let you know.

I’m a big fan of managers admitting their mistakes. (It’s one of the lessons I learned early as a manager.) I take that seriously, seriously enough that when someone found a glaring error in my last SD column, Future Fixes, I asked the editor let me publish a correction and I sent in replacement text for the article.

If you read the article and get to the part labeled “Critical Chain,” stop right there. Jump over that part and wait for the updated version to be posted online. (As of the time I published this post, the article was not updated.) The updated page will have a part called “Manage Your Buffers.” What I described originally has nothing to do with critical chain. If you’re looking for great information on critical chain, go to Frank Patrick’s site, a mother-lode of information.

I feel stupid and dismayed. On the other hand, I’m very glad I have a chance to fix the article and apologize to the readers. I would feel even more dismayed if I hadn’t discovered the error and had a chance to fix it.

Esther’s blog entry this morning set me off into gales of laughter. I’m sure I was the original author of the peanut butter/white bread entry, and with editing, Esther turned it from mud to something that’s ready to be edited. A great case of refactoring in writing.

Now that I write for human consumption, as opposed to code for computers, I redesign and refactor my writing all the time. Sometimes, my editing is more like redesign, where I move chunks of text around, and reorganize, add and subtract whole ideas. Sometimes I rewrite small pieces (refactor) so that someone other me can understand what I’m trying to say.

I’m writing the transition to management book with Esther because we both have passion about the topic and we write well together. We’ve tried some pair writing, and it’s not as easy as we thought it would be, so we tend to write separately and then edit each other’s writing. Sometimes we redesign, sometimes we refactor. Sometimes we throw out.

Refactoring is as applicable to project schedules and human-readable writing as it is to code. If you practice refactoring whenever you can, each of you work products will become more valuable and have fewer defects.

Back to the book