Return on Software: Maximizing the Return on Your Software Investment / Edition 1

by Steve Tockey

Overview

Is your organization getting the maximum value out of its precious, limitedresources (specifically, money, time, and manpower)? Most professionaldevelopers do not consider the business implications of the technical decisionsthey are making -- but they should! In order for software engineering to trulybecome an engineering discipline, software professionals need to know andunderstand the engineering economy.This new book helps software practitioners appreciate the organizationalramifications of each decision they make. It is an insight into the engineeringeconomy that more software organizations aspire to. Each chapter contains aseries of self-study questions to help the reader apply the learned techniques,and the book can also serve as a reference that software engineers can turn to,again and again.

Product Details

ISBN-13:	9780321561497
Publisher:	Pearson Education
Publication date:	08/30/2004
Edition description:	New Edition
Pages:	672
Product dimensions:	7.00(w) x 9.20(h) x 1.80(d)

About the Author

Steve Tockey is the principal consultant at Construx Software, where he consults on active development projects and teaches software requirements, design, quality, and software project management. He has been in the software industry since 1977, and has worked on applications ranging from radiation monitoring equipment to business systems to automated test equipment for commercial airliners.

Read an Excerpt

Preface

There shouldn't be any doubt in anybody's mind that there's a lot of software around, with more being developed every day. Some software is being developed just for fun. For some people developing software is a hobby. Some software is being developed for education: People are studying to be professional programmers, analysts, project managers, and so on, and they need to develop software as part of their education. Some even say that their software is artistic. But let's face it, the vast majority of the software on the planet was created for a purpose: a business purpose. To put it bluntly, the software is there so that somebody can make money.

And even though making money was the software's intended purpose, you'll see in Chapter 1 that software doesn't always live up to that purpose. A lot of software has been written that probably shouldn't have been written in the first place. And a lot of good technology has been put into building the right software, but building it the wrong way so the software ends up never achieving its business goals. Software projects can easily end up costing more money than the resulting product ever brings back in. Financially, many organizations would have been better off never starting some software projects.

What Is This Book About?

This book is about software economics. 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. But economics is primarily a science of choice, and software economics should provide methods and models for analyzing the choices that software projects must make.

and

In any software project there is always a balance between short-term and long-term concerns . . . economic methods can help us make enlightened choices.

This book is about making choices: making software choices in a business context.

Software professionals are faced with choices every day. Some choices are obviously important, such as "Should we even do the Alpha project?", "How much testing is enough?", "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?", and so on. Other choices may appear to be relatively innocuous, such as "What algorithm should we use in module Gamma?", "Should the Sigma data structure be a linked list or an array?", and so on. However, even apparently innocuous choices can have a noticeable effect on the organization's finances. At a minimum, a poor choice on something as seemingly insignificant as an algorithm or data structure could lead to inadequate performance, low maintainability, or defects and lead to unnecessary downstream maintenance.

If you are a practicing software professional, stop for a moment and think about how choices are usually made today. 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, they don't even know that economics should be a factor in their decisions.

Who Is This Book For?

This book is for practicing software professionals and for people on their way to becoming software professionals. By software professional, I don't mean just programmers. I intentionally include software quality assurance/quality control (SQA/QC) professionals as well as project managers, product managers, and program managers. In fact, the book is written for anyone in the software industry who is (or will be) involved in significant technical and managerial decisions. When you get right down to it, eventually that's pretty much everybody in the industry.

Will Reading This Book Make Me a Better Programmer, Designer, Manager, SQA Person . . .?

In one sense, no it won't. This book won't necessarily help a software developer identify new and clever solutions to technical problems. It won't necessarily help a project manager plan or control software projects any better than before. It won't necessarily help a product manager identify new "killer" features to launch into the marketplace. 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, this book will help you make better decisions. When you're faced with choosing between some X, Y, or Z, you'll have a much better idea of how to go about making the choice. And later, if someone asks you why you chose the way you did, you'll be able to explain it in specific, business-relevant terms.

I could have done X, Y, or Z. I chose Y because it gives us the best return on our investment. Here, let me show you . . ..

In addition to helping you become a better professional, these very same concepts and techniques can be used in your own personal finances. 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. For instance, planning a retirement is a self-study question at the end of Chapter 13.

I'm Not the One Who Makes the Big Decisions, Why Does This Apply to Me?

Maybe you don't make the big decisions: which projects to do, what technologies to use, when delivery dates need to be, and so on. Maybe those decisions are made at levels well above your control. But you must at least be making a lot of little decisions. Decisions such as what kind of algorithm to use in this routine, or what kind of data structure to use in that one. Or, which set of test cases is better. Although these may not be the heavy-hitter decisions, they still affect the organization's bottom line. The wrong algorithms, the wrong data structures, the wrong set of test cases—these are all things that can have a noticeable effect over the long haul.

Even though you may not be making the big decisions, chances are that the ultimate decision makers are going to be basing their decision on input from technical people. Knowing the concepts and techniques of business decisions, you'll know exactly what kinds of input to be giving to the ultimate decision makers. Providing a business- relevant argument that supports your technical ideas can help convince the decision makers why your recommendations should be chosen. 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.

Another way to look at it, however, is to rephrase the question. Maybe you don't make the big decisions today. But what about a few years down the road? Maybe by then you will be in a position to be making substantial decisions. 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 decisions should be made. On the other hand, 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. 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. If a new online order processing system could save a company $50,000 per month, that's its time value: $50,000 for every month sooner the solution is delivered. Would it be wise to spend $100,000 on some tool or technology that would help deliver a solution six months earlier than otherwise? Sure, the organization would be saving about $200,000 in the deal. But what if that tool or technology were able to help deliver the software only one month earlier. Would it still make sense? Probably not, the organization would be spending $100,000 to save $50,000. Again, this is a book about helping you make business-wise choices on software projects. Schedule may very well be king, but sometimes that king isn't as all-important as people think he is.

Won't Paying Attention to Economics Just Reduce Quality?

This question is similar to the last one. This time, think about the cost of poor quality. 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, how much might the jury award to the victims? Software product liability suits have already happened. Suppose, for sake of argument, an organization could be exposed to a $100,000 liability if a certain kind of defect were in their software product. Should they be willing to spend $5000 to have a high degree of confidence that that kind of defect isn't there? Probably. Would they be willing to spend $500,000? Probably not.

In fact, the age-old question of "how much testing is enough?" has traditionally been very difficult to answer. But that's because most organizations have been approaching it from entirely the wrong perspective. It's not a technical question at all; it's a business question. Literally, how much does testing cost and what's the reduction in exposure to liability that comes along with it? Somewhat oversimplified, until the cost of additional testing outweighs the benefit, keep testing. When the cost outweighs the benefit, stop testing because you're wasting money and time that could be put to better use elsewhere.

If I Do My Work More Efficiently, Won't It Make Me Less Valuable to My Employer?

No, in fact exactly the opposite, you become more valuable to your employer. If you're the one who consistently makes business-wise technical or managerial decisions, if you're the one who can justify your decisions in terms that the rest of the business understands, you'll be the one who is respected and valued by the organization.

But I Work for the Government (or Some Other Nonprofit Agency). Does All This Economics Stuff Still Apply to Me?

Not all of it, but most of it. Of course, the government isn't out to make a profit. However, the idea of choosing solutions that are both efficient and cost-effective still applies. Techniques for decision making in government and other nonprofit organizations are explained in Chapter 18.

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. 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, your organization probably has experienced the pain of a technology that didn't live up to its promises. That's why it's often so difficult to sell new technology. Simply, people are scared; "once bitten, twice shy."

So what does economics have to do with this? First, by investigating the financial implications of the new technology yourself, you can figure out whether that technology is really as promising as people say it is. Second, after you've determined for yourself that the new technology is a wise path to follow, you can present the same business- relevant explanation to the rest of the organization. This book gives you the tools and techniques for doing both.

Okay, We Know That New Technologies Don't Always Live Up to Their Advertised Benefits. 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. On the other hand, Chapters 24 and 25 explain the techniques for making decisions under risk and uncertainty. 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.

Dr. Barry Boehm Already Has a Well-Known Book Called Software Engineering Economics. How Is This Book Different from His?

Without question, Dr. Boehm is one of the pioneers in considering the economic consequences of software. Dr. Boehm's landmark work clearly paved the way for most subsequent software economics research and application. With all due respect to Dr. Boehm, however, compared to its title his book Boehm81 somewhat missed the mark. First, there's more to engineering economy than what is covered, including income taxes, inflation, and depreciation. Second, much of his book is about the Cocomo estimation model. Cocomo is only one of a whole family of estimation models; many others are available. (Chapters 21 and 22 of this book cover estimation.)

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, for example, DeGarmo93, Eschenbach03, Grant90, or Thuesen93). They've been around for a long time—more than 100 years by some accounts, and well over 70 years at a minimum. The subject, engineering economy, is even a required part of the curriculum in most recognized undergraduate engineering degree programs (recognized means, for example, civil engineering, mechanical engineering, aeronautical engineering, chemical engineering, structural engineering, etc.).

In the end, a return-on-investment analysis (Chapter 8) is a return-on-investment analysis, whether it's trying to determine the best structure for a bridge span, the best material for the foundation of a building, the best airfoil and wingspan for a commercial jet airliner, or the best catalyst for a certain reaction in a chemical production plant. The problem is that software professionals usually aren't familiar with the different kinds of bridge structures, building materials, airfoil cross-sections, or chemical catalysts. So books about making business-wise decisions for civil, mechanical, aeronautical, chemical, or structural engineers aren't likely to help us software professionals very much.

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. Or, a book that helps you decide whether the next release should incorporate that brand-new function or should have fixes for Problem Reports 459, 585, and 661, 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. This book presents those same concepts and techniques in a way that software professionals can understand.

Who Is the Author and What Is His Background?

Steve Tockey is the principal consultant at Construx Software (http://www.construx.com) in Bellevue, Washington. He started programming in 1975 and had his first professional software job in 1977. 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, a business process reengineering effort involving over 800 software professionals, automated functional test equipment for the Boeing 767 and 777 final assembly lines, corporate employee records, 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, design, programming methods, object-oriented programming, software project management, and engineering economy for software)

And finally, 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, Berkeley in 1981 and a Masters of Software Engineering from Seattle University in 1993. He is a member of the IEEE Computer Society and is a Certified Software Development Professional (CSDP). Steve is also Construx's representative to the Object Management Group (OMG, http://www.omg.org).

If I Have Any Questions, Can I Contact the Author?

Absolutely. Just e-mail him at [e-mail]. Questions, comments, and suggestions for improving the book are all welcome.

Does Construx Offer a Seminar Covering the Material in the Book?

At the time this book was published, Construx did not offer a seminar based on this material. For the current list of seminars, see http://www.construx.com.

Table of Contents

Foreword.

Preface.

I. Introduction and Foundations.

1. Return on Software: Maximizing the Return on Your Software Investment.

Software on Purpose.

Waste Not, Want Not.

The Primary Message.

A Secondary Message: Software Engineering Versus Computer Science.

An Overview of the Book.

Summary.

Self-Study Questions.

2. Business on Purpose.

Why Are Companies in Business, 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.

3. 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.

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.

5. 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.

6. 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.

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.

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.

8. Bases for Comparison.

Comparing Cash-Flow Streams.

A Simple Example.

Present Worth, PW(i).

Future Worth, FW(i).

Annual Equivalent, AE(i).

Internal Rate of Return, IRR.

Payback Period.

Project Balance, PB(i).

Capitalized Equivalent Amount, CE(i).

Summary.

Self-Study Questions.

9. Developing Mutually Exclusive Alternatives.

Relationships Between Proposals.

Alternatives.

Developing Mutually Exclusive Alternatives.

The “Do Nothing” Alternative.

Example Proposals.

Summary.

Self-Study Questions.

II. Making For-profit Business Decisions.

10. For-Profit Decision Analysis.

Minimum Attractive Rate of Return (MARR).

Before- 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.

11. Planning Horizons and Economic Life.

Planning Horizons.

Capital Recovery with Return, 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.

12. Replacement and Retirement Decisions.

Replacement Decisions.

Sunk Cost and Salvage Value, 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.

III. Advanced For-profit Decision Techniques.

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. Kinkaid’s Adventure in Actual and Constant Dollars.

Planning a Retirement.

Summary.

Self-Study Questions.

14. 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), 1981–1986.

Modified Accelerated Cost Recovery System - (MACRS), 1987 and Later.

Units-of-Production Depreciation.

Depletion.

Other Aspects of Depreciation Accounting Not Discussed Here.

Summary.

Self-Study Questions.

15. General Accounting and Cost Accounting.

General Accounting.

Cost Accounting.

Determining Unit Cost.

Summary.

Self-Study Questions.

16. 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.

17. The Consequences of Income Taxes onBusiness 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.

IV. Making Decisions in Government and Nonprofit Organizations.

18. 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.

V. Present Economy.

19. 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.

20. 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.

VI. Estimation, Risk, and Uncertainty.

21. 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.

22. 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.

23. 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.

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.

25. 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.

VII. Multiple-Attribute Decisions.

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.

VIII. Summary.

27. Closing Remarks.

A Review of the Book.

The Primary Message.

A Secondary Message: Software Engineering Versus Computer Science.

Summary.

Self-Study Questions.

Appendix A. Software Project Work Breakdown Structures.

Appendix B. Interest Tables.

Appendix C. Linear Interpolation.

Appendix D. Derivatives.

Appendix E. Introduction to Probability and Statistics.

Appendix F. Answers to Selected Self-Study Questions.

Appendix G. Glossary.

References.

Index.