# Bookshelf

Pages: pp. 99-101

## Read Well to Write Well

Anthony Akins

The Best Software Writing Iby Joel Spolsky, ed., Apress, 2005, ISBN 1-59059-500-9, 328 pp., US$24.99. I've always read a lot and realized that reading good works improves my writing. I also believe the opposite is true. I have come across people who have written volumes of documentation, specifications, emails, and marketing material, and yet, despite all that writing practice, their writing was terrible. It didn't flow. It was boring, inaccurate, and grammatically incorrect. It was terrible in so many ways. Then one day, I learned why when one of these prolific writers told me she rarely read anything. That convinced me that if you want to write well, you better read well—that is, if you read good writing, your own writing can't help but improve. But enough of my beliefs—you're interested in the book. I've been a fan of Joel Spolsky's Web columns for some time, so when I came across this book, it piqued my interest. A quick scan of the back cover had me hooked: "Programmers hate writing … [When] they are forced to write down something, it reads like … all the "don't do this" examples from an English style guide … Well, enough is enough … At my own company … we only want to hire software developers who can write, and write well." In the introduction, Spolsky further expounds on these ideas. The software field desperately needs good writing that engages us. We've all seen too many examples of bad writing. But how do you correct the problem? A good start is to recognize and make available examples of good writing. This book's purpose is to showcase excellent writing, with the goal of releasing a new volume every year or so that highlights the best writing since the previous volume. ### The essays The Best Software Writing I consists of 29 essays written by 27 authors. The essays range in length from one page ("Kicking the Llama" by Kevin Cheng and Tom Chi) to 25 pages (the hilarious and excellent "A Quick (and Hopefully Painless) Ride Through Ruby (with Cartoon Foxes)" by why the lucky stiff). Spolsky briefly introduces many of the essays. The essays cover a wide range of topics, from Python's beauty and why enforcing coding styles isn't necessarily a bad thing ("Style Is Substance" by Ken Arnold), to the dangers of outsourcing ("The Pitfalls of Outsourcing Programmers" by Michael Bean), to long days and nights at Electronic Arts ("EA: The Human Story" by ea_spouse). Several essays focus on technical issues, while others focus more on software's sociological issues. All have one thing in common—they're examples of excellent writing. ### Recognizing excellent writing What is excellent writing? I rely on three characteristics to help me recognize it, and this book satisfies all three: • Have I highlighted good phrasing, fundamental truths, and other important points throughout the book? • Have I marked up the margins with my own annotations? • Do I catch myself going back and rereading parts of or the entire book just for the enjoyment? Would I recommend this book to others? Hmm, how's this? Read this book! You'll laugh, you'll cry. Maybe that's an exaggeration, but you'll get 30 examples of good software writing. Some of what you read you'll agree with, some you might not. Things you already knew will be reinforced, and you'll learn a few new things. If you're like me, you'll track down additional works by the authors. Once you're through with The Best Software Writing I and waiting for the next volume, I suggest you pick up another book—Edward Yourdon's Writings of the Revolution (Prentice Hall, 1986). It's a little harder to find but worth the effort because it collects some classics from the early software engineering field. Anthony Akins is a senior consultant at Valtech Technologies. Contact him at anthony.akins@valtech.com. ## Bridging the Gap between IT Managers and Business Managers Ajit Appari Return on Software: Maximizing the Return on Your Software Investment by Steve Tockey, Addison-Wesley, 2005, ISBN 0-321-22875-8, 656 pp., US$49.99.

Software project financing is a primary decision executives must make to compete in this volatile information age. However, most senior technology managers lack adequate training in performing economic analysis of information technology projects for investment justification. Return on Software: Maximizing the Return on Your Software Investment attempts to provide such technology executives with the hands-on tools they need to advocate software projects in economic jargon to the top echelon of their organizations. The book discusses various economic concepts and methods in-depth, making it useful for both technology managers and graduate students of management information systems, engineering management, and software engineering. It seems primarily geared toward for-profit organizations, although it also briefly discusses government and not-for-profit organizations.

### Meeting practical goals

The book's underlying goal is to enable software professionals to make better decisions at different stages of a software project's life cycle, starting from the proposal. By practicing the book's principles, a technology manager could develop the sought-after skills of making economic decisions for software projects and disseminating rationale to project stakeholders. Author Steve Tockey doesn't aim to turn technology managers into economics experts; rather, he guides managers through the basic techniques of economic decision making step by step.

### Laying the foundation

The book presents its core content well. For example, Part I introduces the building blocks of economic decision making by examining the nature of business decisions in both for-profit and not-for-profit organizations. Tockey then moves on to fundamental concepts related to developing cash-flow streams for the project, accounting for time-value of money using different payment mechanisms, estimating the decision variables to differentiate projects' value and performance, and analyzing mutually exclusive alternatives.

Subsequently, Tockey lays out the decision process and discusses various comparison bases for evaluating alternatives for software projects, including present worth, internal rate of return, payback period, and capitalized equivalent amount. An important aspect that practitioners must remember is that depending on a single decision criterion can be misleading. Tockey cleverly drives this point home through a hypothetical example used to elaborate on a comparison base.

Because organizations are continually upgrading their portfolio of software systems, it's imperative for managers to examine software investments in terms of their useful economic life, the effect of economic factors, and regulations on project cost and benefits. Readers should be able to develop these necessary skills by mastering the advanced topics in Parts II and III. However, some of the examples in these sections seem out of place, although they do make sense for accounting and finance professionals (such as planning a retirement in chapter 13 and cost accounting of a car manufacturer in chapter 15). It is important to note that a primary reason the accounting procedures didn't take root in software investment decisions was the lack of appropriate mapping of these accounting concepts to the software world. Although Tockey attempts to explain some of the accounting calculations in software project context (for example, taxation impact), it would be better to construct a single example from a hypothetical software development organization and run through each topic covered in Part III. This would help technology managers see these techniques in a better light.

Part IV discusses what is commonly called incremental cost-benefit analysis in accounting circles. In this approach, practitioners include only those benefits and costs that would be realized when the organization moves from the state of without to with the project. Tockey should have used the prefix incremental in the title of the technique. Because incremental cost-benefit analysis is standard in any managerial accounting textbook for MBA students, retaining the traditional terminology would help technology managers speak the same language as business managers.