PragDave: Writing a Book

Dave Thomas, co-author of “The Pragmatic Programmer: From Journeyman to Master” among many others, has been writing a series of blog posts, PragDave: Writing a Book, giving some excellent advice on how to write a book. True to his pragmatic roots, it is the best, most practically useful advice I’ve ever read on the topic. The link above takes you to the collection of posts in the series, ordered in typical blog style with the latest at the top and the earliest at the bottom. I suggest you take the time to scroll to the bottom and read them in order.

The first addresses the all important question of “Why?” I’ve long wanted to write a book for all the wrong reasons but have only recently begun to considering writing one for more defensible reasons. I’ve gotten to the point where I really like to write. I realize that writing is hard work but I’m certainly going to give it a try. I have decided, however to start by writing shorter pieces. Writing articles will give me a chance to “find my voice” while I wait for the inspiration for the book that must be written to strike me. I’m passionate about a number of technical subjects. I just need to refine my focus some.

The series goes on to give tips on how to read your own writing with a critical eye, how to accept reviewer criticism, along with a number of other extremely practical pieces of advice on successful writing practice. I’ve resolved to try them all myself. I’ll be using this blog as a place to capture early drafts of essays that may grow into articles or books. Watch this space for examples.

Blogged with Flock

The Freedom to Fail

Paul Graham is an inspiring essayist. I agree with most of what he says. In August, he wrote an essay entitled Holding a Program in One’s Head. This essay gave me a lot to think about. He captured the essence of much of what upsets me about the corporate environment in which I try to practice my profession. He overlooks one important aspect of an environment that will encourage creativity and innovation. That is the freedom to fail without repercussions.

I sometimes listen to Terry Gross’ radio program Fresh Air on NPR . Recently she interviewed Steve Carell and Terence Blanchard on two separate programs. The thing that struck me is that they both had similar stories to tell about the environment that nurtured their respective careers.

In Steve Carell’s case, he spoke of his experience as a cast member of Second City, the famous sketch comedy troupe where many of Saturday Night Lives cast received their training. He said that the great thing about that environment was the opportunity to fail. He went on to explain that they were expected to go out and try new characters and ideas. If they worked, great. If they failed, there was no penalty. They were just expected to go out the next performance and try something different.

In a surprisingly similar fashion, Terence Blanchard described what it was like when he joined Art Blakey’s legendary Jazz Messengers band. Terry Gross asked him if Blakey was a disciplinarian. Terence responded that on the contrary, all the members of the band held Blakey in such high regard that he had to spend a lot of effort putting them at ease. When they asked him to let the band play the classics that made the Jazz Messengers famous, he told them that they should compose their own music and make the band their own. Terence went on to say that it was great to have the freedom to fail. To try new things without worrying about whether they would work or not.

I think that programming is the same kind of creative activity that acting and creating music is. By the very same reasoning, I think that the freedom to try things and fail without repercussions is essential to writing innovative software. Furthermore, I think that most software falls into the category of innovative software. We make the mistake of treating software development like the other engineering disciplines and ignoring the central difference between it and them.

If we are building a building or a circuit board or any other physical product, we have a clear idea of the functionality we are after. We might build a model or a prototype to clarify our thinking but we wouldn’t dream of trying to sell a model or a prototype as the final project. Typically, a lot of effort is expended to rigidly define the product so that we can effectively produce it exactly to plan. The reason we do this is that the process of production is costly to change. We get cost breaks from producing many items exactly the same.

Software is different. In the first place, the per unit cost of producing software is negligible.  Secondly, you rarely know exactly what you want the product to look like until you are well along the road to producing it. Unlike physical production lines, changes to software are easy and inexpensive to make. In all but the most extreme circumstances, software requirements are discovered as you implement the program.

You can define requirements in very broad terms, e.g. “this is a point of sale terminal for a video rental store”, but the details of how that should be implemented should be derived from interactively creating software that automates the repetitive tasks of running a video rental store with someone that understands those tasks intimately. And, who knows what those tasks are better than someone that runs a video rental store.

An analogy that was created to explain the rationale behind eXtreme Programming (XP) captures the essence of this principle. You don’t drive a car on a long trip by carefully aiming it in the direction of the destination and tying the steering wheel in place. You would be in the ditch before you went a mile. Instead, you constantly adjust the course, you drive the car. In much the same way, you must drive toward the creation of an innovative piece of software.

That’s why I love being a programmer. That’s why I hate programming in a corporate environment where management doesn’t understand these basic facts about software development and wants to maintain rigid control over the process. But then again, the money is good.

Tuesday Ramble

I’ve been trying to get over this virus the last couple of days. It saps my energy so that I get tired very quickly. That makes it hard to find time to do the things that I have to get done, much less the more or less optional activities like blogging. That doesn’t mean that I’m any less committed to blogging daily, just that I’ve had a temporary set back.

I finally started getting something tangible accomplished at work today. I have been studying various Microsoft Enterprise Frameworks like BizTalk and SharePoint. I made very little progress with the frameworks but yesterday I decided to punt and implement the functionality with a simple Java program. Twenty four hours later and I had implemented 90% of the functionality that I had been struggling to implement for weeks with the Microsoft tools. Now I’m not being critical of Microsoft and I admit that I’m much more experienced with Java than I am with .NET or any of the Microsoft languages and frameworks, but this is ridiculous.

I’m going to post this and go to bed. I’m exhausted. It’s going to be a busy day tomorrow. Hell, the whole rest of the week is going to be hectic.