The Community for Technology Leaders
RSS Icon
Subscribe

Bookshelf

(HTML)
Issue No.05 - September/October (2006 vol.23)
pp: 99-101
Published by the IEEE Computer Society
ABSTRACT
Two book reviews of The Best Software Writing I by Joel Spolsky and Return on Software: Maximizing the Return on Your Software Investment by Steve Tockey.
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.
Ignoring the biggest offenders
A text like this could be useful for managers in government and not-for-profit organizations. Surprisingly, however, Tockey devotes only 15 pages to making economically acceptable choices in such organizations, despite the fact that some of the gravest failures in software history have come from government organizations. Recently, the FBI shelved its virtual case file project, which cost US$170 million to taxpayers and failed to deliver on its promises. A more detailed treatment of decision making using examples from government and not-for-profit organizations would help decision makers more effectively select and manage software projects.
Dealing with investment uncertainty
In practice, organizations are constantly acquiring new software systems, replacing old systems, and upgrading existing systems while accounting for such factors as technology evolution and user acceptance. Above all, managers must live with limited budgets. Return on Software Investment provides the necessary tools for managers to evaluate software amid risk and uncertainty and to choose the best possible decisions. However, no lunch is free, and readers must read the introduction to probability and statistics (in an appendix) to learn the techniques in Parts V and VI.
As a note of caution, it seems that Tockey has unconsciously misrepresented the definition of precision of estimation. Page 359 states that "precision means how finely the estimate is being expressed." Tockey's example suggests that an estimation of "about 11 hours" to drive 500 miles is much less precise than "11 hours, 13 minutes, and 42.7693 seconds," if the actual time was 11 hours and 10 minutes. This notion reflects conventional wisdom but not the definition that would be useful for decision-making analysis under uncertainty. When examined critically, this example essentially reflects closeness to truth (that is, accuracy) and not the degree of reproducibility—which is the correct definition of precision in metrology (the science of measurement). To ensure good decisions, the analyst or decision maker should obtain multiple estimates of underlying decision variables. The closeness of the average value of such estimates would reflect accuracy of estimation, whereas the estimates' standard deviation would reflect precision. In other words, precision indicates how coherent the estimates are. So, we can modify Tockey's example: suppose a group of five people estimates the time it will take to drive 500 miles as (11 hours, 11 hours 5 minutes, 10 hours 50 minutes, 11 hours 10 minutes, and 11 hours 5 minutes). A second group of five people estimate it as (11 hours, 10 hours 30 minutes, 11 hours 30 minutes, 11 hours 15 minutes, and 12 hours). The first group is more precise than the second group. Another way to look at accuracy and precision would be as the average bias in and variance of estimates from actual value.
Supporting materials
Tockey has included several appendices, complete with exhaustive supporting information on topics such as developing a work breakdown structure, interest calculations, linear interpolation, derivatives, and probability and statistics. These background materials are excellent and will help readers grasp the text's technical intricacy. Additionally, he also gives solutions for the self-assessment questions that conclude each chapter. This could help readers validate their solutions and also makes the book appropriate for continuing professional education courses on software evaluation. However, the interest calculation tables in Appendix B could be shortened by restricting the time period n = 15 or 20. For most practical purposes, n = 15 or 20 time periods should be sufficient because software systems are often replaced as a result of technological advances.
Overall, Return on Software: Maximizing the Return on Your Software Investment contributes significantly to knowledge building among practitioners. The simple language, charts, and figures make for a good read. This book fills a critical gap, given a dearth of texts discussing economics-based decision making at different software life-cycle stages, from initiation to retirement. The book is definitely a valuable resource for both practitioners and academics.
Ajit Appari is a PhD candidate in management information systems at Syracuse University. Contact him at aappari@syr.edu.
233 ms
(Ver 2.0)

Marketing Automation Platform Marketing Automation Tool