This action might not be possible to undo. Are you sure you want to continue?
PRAISE FOR RETURN ON SOFTWARE “This pioneering book highlights critical, overlooked skills needed by true software professionals.” —Steve McConnell CEO and Chief Software Engineer Construx Software “It’s about time someone took this stuff seriously.” —Stephen Mellor Chief Scientist Embedded Systems Division Mentor Graphics Corporation Co-Author of Executable UML: A Foundation for Model Driven Architecture and six other books “Despite the fact that engineering economics is considered a core area of any engineering field, virtually no books have been written in the area of software engineering economics. Steve Tockey’s Return on Software nicely fills this gap by providing a comprehensive introduction to software engineering economics accessible both to students and to new software professionals.” —Donald J. Bagert, Ph.D., P.E. Director of Software Engineering and Professor of Computer Science & Software Engineering Rose-Hulman Institute of Technology “The elements of this book are useful not only in making decisions but also in understanding why and how other people and organizations make decisions.” —Shari Lawrence Pfleeger Senior Researcher, RAND Co-Author of Security in Computing and eight other software engineering titles “This is just what the doctor ordered to help software programs solve the problem of how to introduce engineering economics and business decision-making into their curricula. The economics of software development should not only be part of any computing curriculum they are an essential element of recent accreditation and certification recommendations. This book is an accessible and relevant text for any student of software engineering. The style is clear and straightforward and the software examples will be appealing to students and faculty alike. I can’t wait to use it in class!” —Thomas B. Hilburn, Professor Department of Computer and Software Engineering Embry-Riddle Aeronautical University
Return on Software: Maximizing the Return on Your Software Investment
qxd 7/23/04 8:11 AM Page iv .00Tock_00.
00Tock_00.qxd 7/23/04 8:11 AM Page v Return on Software: Maximizing the Return on Your Software Investment Steve Tockey Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid Capetown • Sydney • Tokyo • Singapore • Mexico City .
Rights and Contracts Department 75 Arlington Street. For information on obtaining permission for use of material from this work. Inc. The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information. Suite 300 Boston. or otherwise. please contact: U.qxd 7/23/04 8:11 AM Page vi Return on Software Maximizing the Return on Your Software Investment The authors and publisher have taken care in the preparation of this book.com Library of Congress Cataloging-in-Publication Data 2004105898 Copyright © 2005 by Pearson Education. stored in a retrieval system. mechanical.awprofessional. All rights reserved. Published simultaneously in Canada. but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. Printed in the United States of America.00Tock_00. electronic. Inc. without the prior consent of the publisher. Corporate and Government Sales / (800) 382-3419 corpsales@pearsontechgroup. photocopying. please submit a written request to: Pearson Education. please contact: International Sales / (317) 581-3793 international@pearsontechgroup. recording. in any form.S. or by any means.com Visit Addison-Wesley on the Web: www.com For sales outside of the U. or transmitted. No part of this publication may be reproduced.S. MA 02116 / Fax: (617) 848-7047 ISBN 0-321-22875-8 Text printed on recycled paper 1 2 3 4 5 6 7 8 9 10 Publisher: John Wait Acquisitions editor: Paul Petralia Editorial assistant: Michelle Vincenti Marketing manager: Chris Guzikowski Senior project editor: Kristy Hart Indexer: Larry Sweazy Composition: The Scan Group Proofreader: Debbie Williams Cover designer: Alan Clements Manufacturing buyer: Dan Uhrig . No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein..
00Tock_00.qxd 7/23/04 8:11 AM Page vii Contents Foreword Preface xxi xxv PART ONE: CHAPTER 1: INTRODUCTION AND FOUNDATIONS 1 Return on Software: Maximizing the Return on Your Software Investment 3 Software on Purpose 3 Waste Not. Anyway? Business Decisions in For-Profit Organizations Business Decisions in Not-for-Profit Organizations Business Decisions in Your Own Personal Finances Summary Self-Study Questions The Fundamental Concepts of Business Decisions Proposals Cash-Flow Instances and Cash-Flow Streams Cash-Flow Diagrams Developing Cash-Flow Streams Summary Self-Study Questions 13 13 18 19 20 20 21 23 23 24 26 28 32 33 CHAPTER 2: CHAPTER 3: . Want Not 5 The Primary Message 6 A Secondary Message: Software Engineering Versus Computer Science 7 An Overview of the Book 9 Summary 10 Self-Study Questions 11 Business on Purpose Why Are Companies in Business.
00Tock_00.qxd 7/23/04 8:11 AM Page viii viii Contents CHAPTER 4: The Business Decision-Making Process Introducing the Business Decision-Making Process Understand the Real Problem Define the Selection Criteria Identify All Reasonable Technically Feasible Solutions (the Proposals) Evaluate Each Proposal Against the Selection Criteria Select the Preferred Proposal Monitor the Performance of the Selected Proposal Summary Self-Study Questions Interest: The Time Value of Money Time Is Money Interest Naming Conventions in Interest Formulas Simple Interest Discrete Compounding of Interest Single-Payment Compound-Amount (F/P) Single-Payment Present-Worth (P/F) Equal-Payment-Series Compound-Amount (F/A) Equal-Payment-Series Sinking-Fund (A/F) Equal-Payment-Series Capital-Recovery (A/P) Equal-Payment-Series Present-Worth (P/A) Summarizing the Formulas Some Other Handy Relationships Summary Self-Study Questions Other Interest(ing) Calculations Using Different Interest Periods and Compounding Frequencies The Relationship Between Cash-Flow Instances and Compounding Interval Continuous Compounding. Discrete Payment Determining Actual Interest Rates 35 35 37 39 40 41 42 42 44 44 47 47 48 50 50 52 54 58 60 62 64 66 67 67 69 69 73 73 78 81 82 CHAPTER 5: CHAPTER 6: .
IRR Payback Period Project Balance. PW(i) Future Worth. CE(i) Summary Self-Study Questions Developing Mutually Exclusive Alternatives Relationships Between Proposals Alternatives Developing Mutually Exclusive Alternatives The “Do Nothing” Alternative Example Proposals Summary Self-Study Questions 84 85 87 91 94 94 97 97 100 101 103 106 106 109 110 110 112 114 116 117 119 121 123 124 125 127 127 129 129 132 133 135 136 CHAPTER 8: CHAPTER 9: . PB(i) Capitalized Equivalent Amount. FW(i) Annual Equivalent. AE(i) Internal Rate of Return.00Tock_00.qxd 7/23/04 8:11 AM Page ix Contents ix Paying off a Loan Through a Single. Lump-Sum Payment Separating Interest and Principal in Loan Payments Paying Off a Loan Early Through Higher Payments Interest Rates Might Not Be What They Seem Summary Self-Study Questions CHAPTER 7: Equivalence A Simple Comparison of Two Proposals Simple Equivalence Equivalence with Varying Cash-Flow Instances Equivalence Under Different Interest Rates Summary Self-Study Questions Bases for Comparison Comparing Cash-Flow Streams A Simple Example Present Worth.
CR(i) Economic Life Finding the Economic Life of an Asset Special Cases in Economic Life Economic Lives and Planning Horizons Summary Self-Study Questions Replacement and Retirement Decisions Replacement Decisions Sunk Cost and Salvage Value.and After-Tax MARRs The Basic For-Profit Decision Process Decisions Based on Total Versus Differential Cash-Flow Streams Present Worth on Incremental Investment IRR on Incremental Investment Comparisons Based on Total Cash-Flow Streams Rank on Rate of Return Summary Self-Study Questions Planning Horizons and Economic Life Planning Horizons Capital Recovery with Return.qxd 7/23/04 8:11 AM Page x x Contents PART TWO: CHAPTER 10: MAKING FOR-PROFIT BUSINESS DECISIONS For-Profit Decision Analysis Minimum Attractive Rate of Return (MARR) Before.00Tock_00. Special Issues in Replacement Decisions The Outsider’s Viewpoint: Addressing Sunk Cost and Salvage Value An Example of Replacement Analysis Retirement Decisions Summary Self-Study Questions 139 141 141 143 144 144 147 149 151 153 154 155 157 158 158 160 162 164 164 168 169 171 171 172 173 174 178 181 182 CHAPTER 11: CHAPTER 12: .
1981–1986 Modified Accelerated Cost Recovery System (MACRS).00Tock_00. Kinkaid’s Adventure in Actual and Constant Dollars Planning a Retirement Summary Self-Study Questions Depreciation Introduction to Depreciation Actual Depreciation Depreciation Accounting Value-Time Functions Book Value Depreciation Methods Depreciation Methods Before 1981 Declining-Balance Depreciation Accelerated Cost Recovery System (ACRS).qxd 7/23/04 8:11 AM Page xi Contents xi PART THREE: ADVANCED FOR-PROFIT DECISION TECHNIQUES CHAPTER 13: Inflation and Deflation Inflation and Deflation Price Indices: Measuring Inflation and Deflation Popular Price Indices The Inflation Rate Purchasing Power and Inflation Accounting for Inflation Actual Dollar Versus Constant Dollar Analysis Mr. 1987 and Later Units-of-Production Depreciation Depletion Other Aspects of Depreciation Accounting Not Discussed Here Summary Self-Study Questions 185 187 188 189 190 192 194 196 198 200 201 206 207 211 212 212 213 214 215 216 217 218 223 226 228 229 229 230 230 CHAPTER 14: .
00Tock_00.qxd 7/23/04 8:11 AM Page xii xii Contents CHAPTER 15: General Accounting and Cost Accounting General Accounting Cost Accounting Determining Unit Cost Summary Self-Study Questions Income Taxes and After-Tax Cash-Flow Streams What Are Taxes? Federal Income Taxes for Corporations Federal Income Taxes for Individuals Effective Income Tax Rates Calculating After-Tax Cash-Flow Streams Tax Credits Inflation and After-Tax Cash-Flow Streams Summary Self-Study Questions The Consequences of Income Taxes on Business Decisions Interest Expenses and Income Taxes Interest Income and Income Taxes Depreciation Method and Income Taxes Depreciation Recovery Period and Income Taxes Capital Gains and Losses for Corporations Gain or Loss When Selling or Scrapping Depreciable Assets Comparing Financing Methods in After-Tax Cash-Flow Terms After-Tax Analysis of Replacements Summary Self-Study Questions 233 234 245 249 260 260 265 266 266 268 269 270 274 275 276 277 279 280 281 282 285 286 287 288 293 293 294 CHAPTER 16: CHAPTER 17: .
qxd 7/23/04 8:11 AM Page xiii Contents xiii PART FOUR: CHAPTER 18: MAKING DECISIONS IN GOVERNMENT AND NONPROFIT ORGANIZATIONS Making Not-for-Profit Business Decisions Software and Governments Software and Nonprofit Organizations Decision Analysis in Government and Nonprofit Organizations Benefit-Cost Analysis for a Single Proposal Benefit-Cost Analysis for Multiple Proposals Cost-Effectiveness Analysis Summary Self-Study Questions 297 299 299 302 303 303 308 311 314 314 PART FIVE: CHAPTER 19: PRESENT ECONOMY Break-Even Analysis Decision Variables and Objective Functions Break-Even Analysis with Two Alternatives Break-Even Analysis with Three Alternatives General Case Break-Even Analysis Summary Self-Study Questions Optimization Analysis Introducing Optimization Optimizing a Single Alternative with a Single Decision Variable Optimizing Multiple Alternatives with a Single Decision Variable Optimizing a Single Alternative with Multiple Decision Variables Optimizing Multiple Alternatives with Multiple Decision Variables Summary Self-Study Questions 317 319 319 320 323 325 329 329 331 331 332 334 336 337 337 338 CHAPTER 20: .00Tock_00.
00Tock_00. AND UNCERTAINTY Basic Estimation Concepts What Is an Estimate? Why Estimate? Estimates and Probabilities Estimates and Uncertainty The Cone of Uncertainty: Uncertainties Change over Time Expressing Estimate Uncertainty The Cone of Uncertainty in Light of a Fixed Schedule Summary Self-Study Questions General Estimation Techniques Expert Judgment Estimation Estimation by Analogy Bottom-Up Estimation Estimation by Statistical Methods Estimating by Multiple Methods Make Assumptions Explicit Summary Self-Study Questions Allowing for Inaccuracy in Estimates Knowledge Drives Estimation Accuracy Allowing for Inaccuracy in Estimates Allowing for Inaccuracy Using Conservative Decision Criteria More Effective Strategies Considering Ranges of Estimates Sensitivity Analysis Delay Final Decisions Summary Self-Study Questions 341 343 343 344 344 347 350 358 360 362 362 367 367 369 371 374 377 379 380 381 383 384 384 385 389 390 392 397 399 399 CHAPTER 22: CHAPTER 23: . RISK.qxd 7/23/04 8:11 AM Page xiv xiv Contents PART SIX: CHAPTER 21: ESTIMATION.
00Tock_00.qxd 7/23/04 8:11 AM Page xv Contents xv CHAPTER 24: Decision Making Under Risk Expected Value Decision Making Expectation Variance in Decision Making Monte Carlo Analysis Decision Trees The Expected Value of Perfect Information Summary Self-Study Questions Decision Making Under Uncertainty The Payoff Matrix The Laplace Rule The Maximin Rule The Maximax Rule The Hurwicz Rule The Minimax Regret Rule Summary of the Decision Rules Summary Self-Study Questions 403 404 405 407 411 416 420 420 425 426 427 428 428 429 430 432 433 434 CHAPTER 25: PART SEVEN: MULTIPLE-ATTRIBUTE DECISIONS CHAPTER 26: Decisions Based on Multiple Attributes Different Kinds of “Value” Choosing the Attributes Selecting Measurement Scales Dimensionality of the Decision Techniques Noncompensatory Decision Techniques Compensatory Decision Techniques Summary Self-Study Questions 437 439 439 441 442 447 447 449 459 459 .
00Tock_00.qxd 7/23/04 8:11 AM Page xvi xvi Contents PART EIGHT: SUMMARY CHAPTER 27: Closing Remarks A Review of the Book The Primary Message A Secondary Message: Software Engineering Versus Computer Science Summary Self-Study Questions Software Project Work Breakdown Structures Interest Tables Linear Interpolation Derivatives Introduction to Probability and Statistics Answers to Selected Self-Study Questions Glossary References Index 465 467 467 470 475 475 476 477 485 521 525 531 545 581 603 607 APPENDIX A: APPENDIX B: APPENDIX C: APPENDIX D: APPENDIX E: APPENDIX F: APPENDIX G: .
qxd 7/23/04 8:11 AM Page xvii Dedication To my friends and family xvii .00Tock_00.
00Tock_00.qxd 7/23/04 8:11 AM Page xviii .
certainly deserves mention as well. Shari Lawrence-Pfleeger. Software Project Survival Guide [McConnell98]. especially Mark Nygren.qxd 7/23/04 8:11 AM Page xix Acknowledgements They say that imitation is the sincerest form of flattery. Inc) Karl F. and Melissa Feroe. Steve Mellor (Project Technology).D. Inc) S. London) • James Snell • Fred Waskiewicz (Object Management Group) Their feedback. suggestions.00Tock_00. Develle Ellen Gottesdiener (EBG Consulting. Ph. and general support were instrumental. Bloom Jim Brosseau (Clarrus Consulting Group) Daniel Danecki Heeral Dedhia Michael C. questions. Eric Rimbey. The book benefited greatly from reviews and encouragement from the following people: Renate Bahnemann (Micromuse) Adam B. xix • • • • • • • • • • • • • • • • . and Professional Software Development [McConnell03]). Sivzattian. and Meilir Page-Jones (Wayland Systems) for their advice and support. Hoech Vsevolod (Simon) Ilyushchenko Rob Jasper (Intelligent Results) Francesca Johnson David Kane (SRA International) Xena Kinkaid (Peopleware) Cindy McComiskey Ken Rose (Genesis Microchip. Professor Sid Dyjkstra. Rapid Development [McConnell96]. V. (Imperial College of Science. Special thanks go to Dr. whose impact on the software industry has been immeasurable. I would also like to acknowledge the assistance of the entire team at Construx Software. I hope that’s true because there has been a deliberate attempt to imitate the easy-to-read style of Steve McConnell’s classics (Code Complete [McConnell04]. Technology and Medicine.
the only problem was that the text was not written for software professionals. Thuesen.00Tock_00. The 1950 edition was a textbook in my father’s electrical engineering degree at the University of Nebraska in the early 1950s. and my reading that book in the early 1980s led me to recognize the importance of the topic and its relevance to software engineering. David Umphress—deserves mention for their work in developing a prototype “engineering economy workbench” that automates many of the calculations described here. and faculty advisor Dr. authors of Engineering Economy [Thuesen50] [Thuesen93]. . I would also like to acknowledge H. Thuesen and W. G. The Seattle University course was well received by the students. Fabrycky. Suneela Vaidyula. Craig Kulfan. I hope SWEEP can be turned into a full-featured product someday. The 1993 edition was used as a textbook for a course on software engineering economy at Seattle University. Mike Fidler. Steve Rinn.qxd 7/23/04 8:11 AM Page xx xx Acknowledgements The SWEEP (SoftWare Engineering Economy Project) team at Seattle University—Sheri Brown.
* the newly appointed project manager from IT. First. (In truth. short.qxd 7/23/04 8:11 AM Page xxi Foreword An Introductory Tale A few years ago I attended a software project-initiation meeting in which Levesley. It ran very differently from the way that most other IT projects in that shop had run. with a minor in information technology. Eventually. including business VPs. but when buy-in eventually was reached.00Tock_00. I followed the project for the next year. Usually. there was a sound.) *To protect his anonymity I have not used his real name. object layers. component environments. the buy-in didn’t come easily. So what came next didn’t surprise me. IT people stood up and spoke of distributed relational databases. Levesley did get to “universal-client Web solutions. business-founded charter for the overall undertaking. I happened to know that Levesley had majored in economics and political science. xxi . As a consultant. he had set up such a solid business and—dare I say it—economic context for the project that the VPs of Finance and Marketing were ready to eat from his hands. He discussed things like interest-rate trends and the potential lost-opportunity costs of the capital investment. was making a pitch to various project stakeholders. and such strange things from other dimensions. There were many long days of violent argument. This was the first time that anyone from IT had made a pitch in terms that the Finance VP could identify with. He then demonstrated multiple solution options whose lifecycle costs differed and which also demanded differing up-front capital investments.” “applicationintegrating portals. but it caused the eyes of the VP of Finance to pop out like organ stops. with buy-in from the top to the bottom of the organization. Levesley showed slides about the one-off. But by that time. it was solid.” and so on.and medium-term benefits of addressing particular business problems.
In part. at least as it applies to engineering. But there was also genuine zeal at the grass-roots level. when. I’ve seen many definitions of “success” in shops that I’ve visited over the years. that brings us back to the present and to the book by Steve Tockey that you’re holding right now. both technically and managerially. as Steve puts it so succinctly: Engineering = Science + Economics Software Engineering = Computer Science + Software Economics Why should we software folk care about economics. they tested the effects of the new approach (system and business re-engineering) in an economic way. course-correction project. It was all in sharp contrast to the past. business people would make hurried excuses about dental appointments and would leave for the day. they tested their charter. there was tremendous cooperation. even enthusiasm. But I’d prefer to follow Steve in endorsing Leon Levy’s view that economics is the science of reasoned choice.” I can’t blame him for that assessment (because he’d just finished reading Thomas Malthus’ gloomy work on population density and the economics of famine). however. Success: We’re still here at the end of the project. Or. but not perfectly—I’d say four stars out of five. And that.00Tock_00. as you might expect. science generates the possibilities. in turn.qxd 7/23/04 8:11 AM Page xxii xxii Foreword Second. according to this view. such as: 1. reduced costs. using financial yardsticks. They learned. some project changes had improved corporate competitiveness far more than they’d hoped for. Yes. while economics selects among them: science sets ’em up. They looked at increased revenue. . this came from the top (the VPs) down. Conversely. So. They used these shortfalls as grist for a Version 2. from the business folk. What Is Economics and Why Is it Important to Us? Thomas Carlyle once called Economics “the dismal science. economics knocks ’em down. Six months after deployment. And so (cue: harp music and shimmering visual effects). This is engineering. But they were not done yet. The project ended well. that some things didn’t pan out nearly as well as they’d set forth in the project charter. depends on how high our shop sets the bar for its notion of software success. should an IT person come a’calling. as opposed to just coding— about engineering as opposed to science? The answer lies in our chances of survival in the capitalist environment. and improved customer service that could be attributed to their project. until only both the technically feasible and economically viable options remain.
this book is not about religion. They have to or they will simply go away: When the Grim Economic Selector stops by for a quick reap. Clearly knowing the why will illuminate decisions on the what and the how. it’s about engineering. Success: We’re still here at the end of the project and we’ve written a bunch of code. Levesley’s shop is a good example of a software outfit that consciously assessed the economic environment before making a move. 5. a heavyweight methodology or a lightweight one. When software was a minor issue in many companies. . rather than “good enough” testing. what you are trying to achieve and the economic factors that apply to your organization. No. it teaches you how to fish. with software a bigger and more important factor in everything. Success: We’re still here at the end of the project and we have implemented costeffective solutions to real business problems and cost-effective exploitations of real business opportunities. involving a combination of manual and automated systems.qxd 7/23/04 8:11 AM Page xxiii Foreword xxiii 2. How.00Tock_00. More and more shops are taking this approach. And the economic environment enveloping software shops is getting tougher all the time. 3. 4. a way that depends on your shop’s circumstances. It does not rule for or against an “agile” or an “extreme” approach. It does not recommend exhaustive testing. Making an economic choice is akin to adaptability. Among companies whose business is software. Assuming that you already know your way around software. This book is about the why of software. Success: We’re still here at the end of the project and we have a bunch of code (from various sources) that does something useful.” What. they too will become more and more subject to economic factors. But nowadays. Rather than handing you a fish on a plate. he’s far more likely to wipe out a “#1 shop” than a “#5 shop. it teaches you the tools and techniques for making each of the above decisions in a reasoned way. competition is fierce. This book does not come out in favor of a spiral lifecycle or a waterfall one. Shops in the first three categories are on very thin ice when it comes to survival in a tough economic environment. even a grossly inefficient IT shop could be kept afloat by cash infusions by the business-at-large. IT shops will not be cocooned indefinitely in a benign enveloping corporation. grossly inefficient IT shops are an impediment that can bring down an entire corporation. Success: We’re still here at the end of the project and we we’ve written a bunch of code that runs. and Why Much has been written over the decades on the what and the how of software.
NOW I ARE ONE.qxd 7/23/04 8:11 AM Page xxiv xxiv Foreword Title Inflation President Lincoln liked to ask: “If I call a tail a leg. just as software people always have. software should be the dominion of engineers. As the great software luminary Sid Dijkstra (no relation to the late Edsger Dijkstra) once said: “Software is too important to be left to programmers. But to think that someone can join the software industry and become a true software engineer in less than a year is ludicrous. screens are gaudier. is software architect. a real souvenir of 1990s Zeitgeist: LAST YEAR I COULDN’T SPELL SOFTWARE ENGINEER. germane. It was indeed a time when almost anyone who learned to spell HTML could get a well-paid software position. languages are generally richer.” Lincoln would retort. Calling a tail a leg doesn’t make it a leg.” During my stretch in the software industry I’ve seen several generations of title come and go.) Merely calling someone a software engineer certainly doesn’t make them one. Then software developers. (The latest vogue title. memories are larger. Then programmers/ analysts. Then programmers.” would come the inevitable response. Mr. comprehensive.” In this book. Return on Software: Maximizing the Return on Your Software Investment. but authentic engineers who know how to meld economics successfully with software science. Once upon a time we were all coders. Read it and you’ll be well on your way to becoming a bona fide software engineer. Meilir Page-Jones Renton. Steve Tockey’s book. Steve refines that statement: “Yes. President. WA June 2004 . and its effects are too bloody expensive to be left to programmers too. That’s when I saw this bumper sticker in Palo Alto. modeling approaches are more complex. The “software engineer” misnomer was perhaps at its worst in the late 1990s. Even today—although computers are faster. Not people with I Are a Software Engineer on their business cards. Then software engineers. and development tools are more sophisticated—most so-called software engineers simply develop software.00Tock_00. “five. “Four. is probably the most important. how many legs does a dog have?” “Why. I believe.” Instead.” “No. and usable work to date on the economic issues in software.
What Is This Book About? This book is about software economics. and so on. And a lot of good technology has been put into building the right software. . Two quotes from Leon Levy [Levy87] summarize the book: Software economics has often been misconceived as the means of estimating the cost of programming projects. analysts. the software is there so that somebody can make money. the vast majority of the software on the planet was created for a purpose: a business purpose. This book is about making choices: making software choices in a business context. with more being developed every day. economic methods can help us make enlightened choices. project managers.00Tock_00. And even though making money was the software’s intended purpose. but building it the wrong way so the software ends up never achieving its business goals. .qxd 7/23/04 8:11 AM Page xxv Preface There shouldn’t be any doubt in anybody’s mind that there’s a lot of software around. and they need to develop software as part of their education. Some software is being developed just for fun. xxv . Financially. For some people developing software is a hobby. and In any software project there is always a balance between short-term and long-term concerns . many organizations would have been better off never starting some software projects. A lot of software has been written that probably shouldn’t have been written in the first place. Some software is being developed for education: People are studying to be professional programmers. To put it bluntly. Some even say that their software is artistic. and software economics should provide methods and models for analyzing the choices that software projects must make. But let’s face it. you’ll see in Chapter 1 that software doesn’t always live up to that purpose. Software projects can easily end up costing more money than the resulting product ever brings back in. But economics is primarily a science of choice.
I don’t mean just programmers. SQA Person . If you are a practicing software professional. product managers. Other choices may appear to be relatively innocuous. It won’t necessarily help a . eventually that’s pretty much everybody in the industry. When you get right down to it. such as “What algorithm should we use in module Gamma?”. low maintainability. such as “Should we even do the Alpha project?”. Who Is This Book For? This book is for practicing software professionals and for people on their way to becoming software professionals. It won’t necessarily help a project manager plan or control software projects any better than before. they don’t even know that economics should be a factor in their decisions. Will Reading This Book Make Me a Better Programmer. “How much testing is enough?”. a poor choice on something as seemingly insignificant as an algorithm or data structure could lead to inadequate performance. and so on. Designer. no it won’t. Does the typical software professional ■ ■ ■ ■ Consider more than just a single possible technical solution? Ask how much each of those possible solutions will cost? Ask how much (or even if) those possible solutions will generate income or reduce the operating expenses for the organization? Care what the time frame for the costs and benefits might be? It’s been my experience over more than 25 years in this industry that most software professionals not only don’t know how to make financially responsible technical choices. the book is written for anyone in the software industry who is (or will be) involved in significant technical and managerial decisions. Manager. and program managers.? In one sense. “Should the Omega project use the Rational Unified Process [Kruchten00] or would eXtreme Programming [Beck00] [Jeffries01] or one of the other Agile [Cockburn02] methods be better?”. . stop for a moment and think about how choices are usually made today. and so on. However. or defects and lead to unnecessary downstream maintenance. . This book won’t necessarily help a software developer identify new and clever solutions to technical problems.qxd 7/23/04 8:11 AM Page xxvi xxvi Preface Software professionals are faced with choices every day. I intentionally include software quality assurance/quality control (SQA/QC) professionals as well as project managers. By software professional. even apparently innocuous choices can have a noticeable effect on the organization’s finances. “Should the Sigma data structure be a linked list or an array?”. At a minimum.00Tock_00. In fact. Some choices are obviously important.
Being familiar with the methods and techniques in this book may also help you better understand and appreciate the decisions that are made at those higher levels.. I could have done X. But you must at least be making a lot of little decisions. Why Does This Apply to Me? Maybe you don’t make the big decisions: which projects to do. is to rephrase the question. planning a retirement is a self-study question at the end of Chapter 13. I’m Not the One Who Makes the Big Decisions. these very same concepts and techniques can be used in your own personal finances. and so on. And later. chances are that the ultimate decision makers are going to be basing their decision on input from technical people. . this book will help you make better decisions. or Z. How do you decide if it’s better to lease a car or buy it? How do you decide between one house loan with higher closing costs and a lower interest rate and another loan with lower closing costs and a higher interest rate? This book gives you the tools to do that and more. It won’t necessarily help a tester come up with more effective test cases nor will it show an SQA person different techniques for finding or preventing software defects in the first place. On the other hand. In addition to helping you become a better professional. It would be better for you to get practice with the concepts and techniques now and have a few years of experience under your belt rather than be put into the position with no knowledge of how the big . if someone asks you why you chose the way you did. you’ll know exactly what kinds of input to be giving to the ultimate decision makers. Y. Knowing the concepts and techniques of business decisions. But what about a few years down the road? Maybe by then you will be in a position to be making substantial decisions. let me show you . they still affect the organization’s bottom line. When you’re faced with choosing between some X. what technologies to use. or what kind of data structure to use in that one. Although these may not be the heavyhitter decisions. you’ll have a much better idea of how to go about making the choice. Decisions such as what kind of algorithm to use in this routine. Providing a businessrelevant argument that supports your technical ideas can help convince the decision makers why your recommendations should be chosen. or Z. For instance. Y. The wrong algorithms. the wrong set of test cases—these are all things that can have a noticeable effect over the long haul. the wrong data structures. I chose Y because it gives us the best return on our investment. business-relevant terms.00Tock_00. when delivery dates need to be. Here. which set of test cases is better. Maybe you don’t make the big decisions today. however. Even though you may not be making the big decisions. . Another way to look at it.qxd 7/23/04 8:11 AM Page xxvii Preface xxvii product manager identify new “killer” features to launch into the marketplace. you’ll be able to explain it in specific. Or. Maybe those decisions are made at levels well above your control.
000 for every month sooner the solution is delivered.000 per month. the organization would be spending $100. On the other hand. If a new online order processing system could save a company $50. that’s its time value: $50.qxd 7/23/04 8:11 AM Page xxviii xxviii Preface decisions should be made. Literally.000 liability if a certain kind of defect were in their software product.000? Probably not. In fact. stop testing because you’re wasting money and time that could be put to better use elsewhere. how much does testing cost and what’s the reduction in exposure to liability that comes along with it? Somewhat oversimplified. it’s a business question. Again. How much more income could be generated (or costs could be avoided) if a software solution to some problem were available sooner? The time value of the software is essentially that income or cost difference. how much might the jury award to the victims? Software product liability suits have already happened. Suppose. an organization could be exposed to a $100.000 on some tool or technology that would help deliver a solution six months earlier than otherwise? Sure. Would it still make sense? Probably not. the age-old question of “how much testing is enough?” has traditionally been very difficult to answer. keep testing.000 in the deal. this is a book about helping you make business-wise choices on software projects. But that’s because most organizations have been approaching it from entirely the wrong perspective. . This time.000.000 to save $50. think about the cost of poor quality. for sake of argument. Won’t Paying Attention to Economics Just Reduce Quality? This question is similar to the last one. until the cost of additional testing outweighs the benefit. Should they be willing to spend $5000 to have a high degree of confidence that that kind of defect isn’t there? Probably. What kind of damage could a defective software product cause? Would it cause users to lose work? Would it cause them to lose data? Would it cause them to lose their customers? If it came down to a product liability suit. the organization would be saving about $200. Schedule may very well be king. But what if that tool or technology were able to help deliver the software only one month earlier. Would they be willing to spend $500. if you don’t know how to approach making big decisions—by practicing and showing competence in how you make smaller decisions—what are the chances that you’d be promoted in the first place? Why Would Anyone Bother When Everybody Knows That Schedule Is King? This question can be answered by thinking in terms of the “time value” of the software product. It’s not a technical question at all. but sometimes that king isn’t as all-important as people think he is.00Tock_00. When the cost outweighs the benefit. Would it be wise to spend $100.
in fact exactly the opposite. Haven’t you ever had a hard time selling the rest of the organization on some technology that you thought held promise? Whether you personally have ever been burned or not. the idea of choosing solutions that are both efficient and cost-effective still applies. after you’ve determined for yourself that the new technology is a wise path to follow. Simply.qxd 7/23/04 8:11 AM Page xxix Preface xxix If I Do My Work More Efficiently. you become more valuable to your employer. you’ll be the one who is respected and valued by the organization. Techniques for decision making in government and other nonprofit organizations are explained in Chapter 18. by investigating the financial implications of the new technology yourself. However.” So what does economics have to do with this? First. the government isn’t out to make a profit.00Tock_00. Won’t It Make Me Less Valuable to My Employer? No. That’s why it’s often so difficult to sell new technology. if you’re the one who can justify your decisions in terms that the rest of the business understands. twice shy. . you can figure out whether that technology is really as promising as people say it is. people are scared. Of course. But I Work for the Government (or Some Other Nonprofit Agency). your organization probably has experienced the pain of a technology that didn’t live up to its promises. This book gives you the tools and techniques for doing both. “once bitten. but most of it. Does All This Economics Stuff Still Apply to Me? Not all of it. Why Focus on Economics When It’s The New Technologies That Provide All the Big Gains in Software? Do the new technologies really provide all the big gains? Almost every organization has been burned by at least one “hot new technology” that didn’t live up to its promises. you can present the same businessrelevant explanation to the rest of the organization. Second. If you’re the one who consistently makes business-wise technical or managerial decisions.
much of his book is about the Cocomo estimation model. or the best catalyst for a certain reaction in a chemical production plant. With all due respect to Dr. Cocomo is only one of a whole family of estimation models. (Chapters 21 and 22 of this book cover estimation. however. a return-on-investment analysis (Chapter 8) is a return-on-investment analysis. civil engineering. compared to its title his book [Boehm81] somewhat missed the mark. [Grant90]. Boehm’s landmark work clearly paved the way for most subsequent software economics research and application. They’ve been around for a long time—more than 100 years by some accounts. [Eschenbach03]. How Is This Book Different from His? Without question.). for example. including income taxes. chemical engineering. Second. etc. Dr. The subject. Barry Boehm Already Has a Well-Known Book Called Software Engineering Economics. First. many others are available. We Know That New Technologies Don’t Always Live Up to Their Advertised Benefits. Dr. for example. structural engineering. there’s more to engineering economy than what is covered. Boehm is one of the pioneers in considering the economic consequences of software. and well over 70 years at a minimum.) What About the Other Books on This Topic? Why Should I Care About This Book? The concepts and techniques in this book aren’t new or unique (see. Dr. engineering economy. aeronautical engineering. mechanical engineering.qxd 7/23/04 8:11 AM Page xxx xxx Preface Okay. In the end. or [Thuesen93]). Boehm. is even a required part of the curriculum in most recognized undergraduate engineering degree programs (recognized means. the best airfoil and wingspan for a commercial jet airliner. whether it’s trying to determine the best structure for a bridge span. If you’re not entirely certain that the new technology will pan out as advertised—which should almost always be the case—these techniques allow you to factor in your degree of confidence (or lack thereof) and see how it impacts the decision. What Happens If I Make My Choice Based on False Claims? How Does This Book Help Me Then? Nothing can help you if you wait until after the fact.00Tock_00. and depreciation. [DeGarmo93]. On the other hand. The . inflation. Chapters 24 and 25 explain the techniques for making decisions under risk and uncertainty. the best material for the foundation of a building.
or chemical catalysts. or structural engineers aren’t likely to help us software professionals very much. He is a member of the IEEE Computer Society and is a Certified Software Development Professional (CSDP). design. Construx (where he consults on software development projects and teaches both public and on-site seminars). Steve received a Bachelor of Arts degree in Computer Science from the University of California. and 661. This book presents those same concepts and techniques in a way that software professionals can understand. building materials. Who Is the Author and What Is His Background? Steve Tockey is the principal consultant at Construx Software (http://www.com) in Bellevue. http://www. because you already know that you don’t have the money or the people to do both? Wouldn’t that be a handy reference? This is that book. a book that helps you decide whether the next release should incorporate that brand-new function or should have fixes for Problem Reports 459. corporate employee records. He started programming in 1975 and had his first professional software job in 1977. automated functional test equipment for the Boeing 767 and 777 final assembly lines.omg. object-oriented programming. aeronautical. chemical.org). Berkeley in 1981 and a Masters of Software Engineering from Seattle University in 1993. Or. mechanical. a business process reengineering effort involving over 800 software professionals. 585. . Steve is also Construx’s representative to the Object Management Group (OMG. software project management. Washington. So books about making business-wise decisions for civil. Since then he’s worked at • Helgeson Scientific Services (radiation monitoring equipment for the nuclear industry) • Lawrence Livermore National Laboratory (data acquisition and process control system for laser isotope separation) • The Boeing Company (software engineering research. and engineering economy for software) • And finally.qxd 7/23/04 8:11 AM Page xxxi Preface xxxi problem is that software professionals usually aren’t familiar with the different kinds of bridge structures. programming methods. airfoil cross-sections.construx.00Tock_00. visualization of computational fluid dynamics data. and a host of other smaller projects) • The Collins Avionics division of Rockwell International (more software engineering research and some participation in the development of a microwave landing system (MLS) receiver for commercial airliners) • Seattle University (adjunct professor teaching courses including analysis. But a book that explains how to use return-on-investment analysis to figure out whether it was better to keep maintaining an existing software system or throw it out and rebuild it from scratch? Now that would be a useful book for a software professional.
Just e-mail him at firstname.lastname@example.org 7/23/04 8:11 AM Page xxxii xxxii Preface If I Have Any Questions. see http://www. Does Construx Offer a Seminar Covering the Material in the Book? At the time this book was published. .construx.00Tock_00. and suggestions for improving the book are all welcome. For the current list of seminars. Questions. Can I Contact the Author? Absolutely. Construx did not offer a seminar based on this material. comments.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.