With any luck, readers will be intrigued by your title. But you could lose your readers before they read very far if the first few sentences don’t continue with sufficient intrigue to compel them onward. Now, by intrigue—don’t get me wrong—I don’t mean that you should say something cryptic. I mean that you should propose a topic in a way that piques the interest of people inclined to read about your topic. Your first sentence doesn’t have to be a companion to the title, but it shouldn’t be a change of direction. In non-fiction writing, there are two types of first sentences: Declare the Problem and Solve the Problem. How you go about that is, of course, the difficult bit. Today’s blog, Part 1 of two, addresses the Declare the Problem approach. Part 2 looks at choosing Solve the Problem as a first paragraph strategy. Here are some examples, all straight from MSDN articles online.

Straightforward

In this first example, the author gets right to it. He declares the problem and then refines the situation in the following sentences. Microsoft Access provides no built-in support to scale a form's size to match the current screen resolution. A form that you design on a computer with a video driver resolution of 1024x768 (Super VGA) may appear too large on computers running at 640x480 (VGA) resolution. A form that you design using 640x480 resolution may appear too small on computers running at 1024x768 resolution. On its own like this, we can’t really tell what the article is about. In context of the title, we probably could figure it out (it’s probably about designing scalable forms using a particular tool in Access). It is a little hard to read with all the dimensions and acronyms, but readers developing in Access and readers creating forms will want to read on. Here’s another one that digs right in without preamble. This author also declares the problem, and, in the next sentence, promptly names the application providing the solution to the problem. Data interoperability with Microsoft Office-based applications is an important part of real-world solutions. ADO.NET is the powerful, flexible data access layer in the Microsoft .NET Framework that makes data interoperability with any application easier and more extensible. This one is stronger than the first example because we also know the subject of the discussion from the first sentence: data interoperability in Office. I don’t like the use of the jargon word “solutions” to mean “customized applications,” but we can still figure out what he means so I’ll only dock him a tenth of a point. (Are you watching the Olympics?) In the second sentence, he tells us how to solve the problem and why we should pursue it, providing a great segue to the rest of the piece, or we can stop here and go figure out the problem on our own because he’s already given us the tools we need to do the task ourselves. He loses another tenth of a point for saying “more extensible” without saying more extensible than what. (“More” is a comparative word. You have to compare it to something.) Here’s another one that just tells us what the problem is and promptly proposes a solution, or at least a current way of solving the problem. Programmers often overlook Null values in their efforts to preserve database integrity. When you load a record from the database, you need to convert Null fields to appropriate values your property variables can hold. You can convert Null values by turning them into some other value or by storing all your variables as Variants. Notice that in this example and the previous one, the problem is stated in fairly personal terms. Both authors assume that the reader performs the tasks at hand and has encountered some of the problems detailed in the articles. In the first example, the author names the tools he’ll use to overcome the difficulty. In the second example, the author continues evaluating the problem, without naming his proposed solution or tool. By the time we get to the next paragraph of both articles, we’re primed and ready to follow along.

History

If you’ve been reading my blogs, you know that I don’t approve of history lessons in technical articles. I feel that history lessons are feeble attempts to prove the author’s worthiness to write such an article and that they belong in the jungle with chest thumping and vine swinging. This example is a case in point: the author explains his motivation for writing the article, but there’s only one tiny little clue about what the article is about. In watching the various Internet discussion forums, it has become glaringly obvious that the development community at large is still struggling with how the Web services fabric will be held together. By the end of 2001, everyone in the emerging Web service industry had converged on SOAP. Based on the raging debates held in 1999, this is amazing progress. I think this author set out to state the problem but he missed the mark. Partially, the fault is that it’s too personal—he’s been watching forums, although he declines to say that he is the watcher, and he has gleaned a kernel of information, even though he doesn’t declare his own presence there. He uses euphemisms (community at large, fabric held together, raging debates) to spice up his somewhat aimless entry into the discussion. He has a clue to what the chatter is all about (SOAP), but he doesn’t tell us what the problem is nor how he proposes to solve it. We’re not sure what year he’s writing about forum-watching either, as he seems to be headed backward in time. Here are two history-style problem stating starts that tell us what we need to know to keep reading. (These are unrelated first paragraphs.) Only a small percentage of Visual Basic 6.0 programmers ever found the need to create any class modules other than the ones that were automatically created when they built Visual Basic 6.0 forms. In addition, most programmers who did create their own class modules in Visual Basic 6.0 did so only because they wanted to build Microsoft ActiveX components and they had to use class modules to do it. Up until now, creating Word documents from Access required extensive knowledge of the Word object model plus some significant programming knowledge. With Word 2003, that's all changed. [Author’s Name] illustrates how you don't even need Access 2003 to take advantage of Word's new functionality. In the first, one, we’re not really clear about the subject of the article, only a narrowing of the field of possible topics. Presumably, the title told us what the article is about. If that’s the case, the paragraph is acceptably oblique in that we are curious about what will be in the next paragraph, so the purpose of drawing the reader into the article was served because we have context for what will follow. In the second example, the problem is declared without equivocation and the source for our enlightenment is clear. It’s not a very intriguing beginning, but there’s no question what the article will cover, so it accomplishes the goal satisfactorily. Not everything needs to be intriguing. Straightforward is just dandy for many situations, especially if that matches your personality.

Personal

Sometimes, being personal is the best way to get readers invested in reading about a dry subject. You can write about your own experiences with the topic at hand, or you can relate to the topic in a way that allows the readers to feel that they know you or the topic and you’re just having a nice schmooze. This first example is good because it assumes that the reader and the author are equals. Despite the richness and versatility of its programming interface, the ASP.NET 1.x DataGrid control requires you to write a lot of custom code to handle common operations such as paging, sorting, editing, and deleting data. For example, while the DataGrid control can raise events when the user clicks to save or cancel changes, it doesn't offer much more than that. If you want to store changes to a persistent medium, such as a database, you have to handle the UpdateCommand event yourself, retrieve changed values, prepare a SQL command, and then proceed from there to commit the update. Both the examples and the tone are inviting enough to encourage reading, even though the paragraph is a little longer than the other examples. It’s long because he provides examples of his nouns (types of common operations, user events, and persistent mediums). Without these examples, he might lose readers who aren’t sure that the article covers topics that are personally relevant. Dock him a tenth of a point for saying “while” when he means “although.” (See my blog My Editorial Pet Peeves.) In this next example, the author’s good-natured approach to a serious problem makes us want to read. Let's face it: every minute of every day, someone, somewhere, is patrolling the Web looking for sites to hack. ASP.NET developers must constantly be on their guard to ensure attempted hacks can't be successful. That means constraining and validating user input, accessing databases securely, storing sensitive data securely, and generally writing secure code that repels rather than accommodates these malevolent hackers. Because the author makes some assumptions about the skill-level of his readers, we are pulled forward into the piece whether we actually have those qualifications or not. In the first sentence, we can’t really tell what the article is about, but partly because of the tone and partly because of its brevity, we are ready for the second sentence that clears it all up. The third sentence tells us what the article will be about without the self- conscious device of saying “this article will be about…”. Here’s one that’s hopelessly personal. We have no idea at all what the article will cover, except that “Hello World” is probably in there somewhere. If you have been reading this column for the past year, you saw that I have created other articles with "Definitive Hello World" in the title. My purpose with these articles is to give developers a step-by-step approach to getting a basic solution up and running so they do not need to read several articles just to get started. This author MEANT to tell us what the problem was that he proposes to solve, but he got lost in the quagmire of shameless self-promotion and he blows it. He starts by saying “I know you’re breathlessly awaiting yet another article from me” and he ends by saying “I’m trying to prevent you from reading countless articles from me by writing this article.”

The Voice of Experience

It’s entirely possible—and not necessarily inappropriate—to do a little quiet chest-thumping if you can do it inconspicuously. You tell us that you know what you’re talking about by telling readers that you can prevent heartache and heartburn. As you move forward with your use of ADO.NET, you'll need to know how to approach situations that you previously learned to handle in ADO and now have to tackle with ADO.NET. Just as n-tiered solutions developed using Visual Basic, C++, and ASP often rely on ADO for their data access needs, Windows Forms, Web Forms, and Web services rely on ADO.NET. That example is personal in several ways. It puts the reader in the cube next door to the author because he uses the personal pronoun “I,” and he quotes something he’s overheard, even though it’s a presumably fabricated quotation. Another example of using a quotation comes in this next example. I’ve provided the second paragraph from the article because you can’t tell where it’s heading without it. Having talked to thousands of developers who use the Microsoft .NET Framework, I've heard one consistent complaint: "I really wish all the samples were written in my programming language." Nothing is more frustrating than having braved the wilds of Internet searches for a snippet of code that does exactly what you want but is written in a language you don't use. The good news is that you can translate code into your favorite language with a minimum of fuss. I certainly don't want to get involved in any nasty language wars, but for .NET, the two most commonly used languages are Visual Basic .NET and C#, so I'll focus on translating between those. The first paragraph declares the problem. It’s personal, it makes assumptions about readers that pull us all in whether our experience matches or not, and it uses the interesting visual and literary effect of including a quotation. The second paragraph tells us what the proposed solution is, how it will be limited, and what tools we will explore.

Going On

A good opening paragraph pulls readers further into the piece. If you’re lucky, your topic will continue to pull readers from one paragraph to the next throughout the piece. And you can certainly learn lessons from the first paragraph by writing similarly conscientiously all the way through your piece. In Part 2, I’ll cover the (much rarer) opening gambit of Solving the Problem.