The Calculus of Writing Software for Money, Part II

The dictionary definition of economics is a social science concerned with the description and analysis of production, distribution, and consumption of goods and services. [1]

Another definition of economics, closer to software developemnt is the study of how people make decisions in resource-limited situations. This definition matches the classical use of the term and is the basis of software economics. Since software product development always takes place in the presence of limited resoruces. Time, money, capabilities, even knowledge. And since software development always is the exchange of those resources for the production of value, looking at development from an economics point of view is a good start for any discussion around improving the process. 

Two other definitions are needed before continuing. Macroeconomics is the study of how people make decisions in a resource-limited situation on a national or global scale. Microeconomics is the study of how people make decisions in a resource-limited situation on an individual or organization scale. 

For software development, microeconomics deals more with the type of decision making needed for successful projects. And since much of the discussion these days is about making decisions on projects, let's see how the microeconomics paradigm may improve the communication.

There have been suggestions that the book above is old school and no longer applicable to the modern world of software development - e.g. Agile. Since the book is actually about engineering economics  not about software development methods, let's see what the book actually says for those who have not read it, heard Dr. Boehm speak, or in my case worked for the same firm where Dr. Boehm lead our process improvement management effort.

This book was a working text, when I attended USC as a Master's student while working at TRW (Boehm's home) for an Engineering Economics course. The book is still in print and available in used form for low prices. So those wishing to comment on the book, without having first read all 765 pages, can now do so at a low cost.

The preface of the book starts with the usual qualifiers, but contains three important objectives

1. To make a book easy for students to learn from
2. To make a book easy for professors to teach from
3. To provide help for working professionals in the field

The major objective of the book is to provide a basis for a software engineering course, intended to be taken at the college senior or first year graduate level

So let's look at chapters to get a feel of the concepts of software engineering economics. My comments on the chapter are in italics.

1. Chapter 1 - Case Study of the Scientific American subscription processing system.
2. Chapter 2 - Case Study of an Urban School Attendance system
3. Chapter 3 - Goals of Software Engineering
4. Chapter 4 - The Software Lifecycle: Phases and Activities. This is where the book does not represent the current practice. 1980 Agile was not known. But TRW applied an iterative and incremental development process to Cobra Dane and TRDSS, two programs I participated in as a software engineer writing signal processing code in FORTRAN 77. 
5. Chapter 5 - The Basic COCOMO Model. This model is in use today, along with SEER , QSM, Price-S, and many other software cost and schedule modeling tools. COCOMO was the first. But all are based on some sort of reference class estimating process.
6. Chapter 6, 7, 8, and 9 - The  COCOMO Model: Development Modes,Activity Disribution, Product, and Component level 
7. Chapter 10 - Performance Models and Cost-Effectiveness Models
8. Chapter 11 - Production Functions: Economies of Scale
9. Chapter 12 - Choosing Amoung Alternatives: Decision Criteria. This is where the microeconomics starts to enter the current discussion. If we intend to make decisions about how we are going to spend our customers money, we need to consider (from the chapter)
• Minimum available budget
• Minimum performance requirements Performance in this context is anything techncial. We have cost, schedule, and performance the three variables of all projects.
• Maximum effectiveness / Cost Ratio
• Maximum Effectiveness-Cost Difference
• Composite options
• The basis of all decision making in the software development paradigm starts and ends with cost. This is true, simply because writing software for money, costs money.
• Value to customer, delievry dates are of course critical decision making attributes as well.
• Knowing how much money, how that money is being utilized - efficacy of funds, how that money is time phased - absorption of funds, and the "return on investment" of those funds Starts and Stops with estimating (because we can't know for sure in the beginning and can't wait till the end) how much it will cost to deliver the needed capabilities to produce the value for the customer. [2]
10. Chapter 13 - Net Value and Marginal Analysis - another chapter on the effacay of money
11. Chapter 14 - Present versus Future Expenditure and Income. Another microeconomics chapter on forecasting and estimating budget, performance, and value
12. Chapter 15 - Figures of Merit - how to decide what to do, now that you have some notion of cost, schedule, performance, and risk
13. Chapter 16 - Goals as Constraints. Some good discussion in the #NoEstimates world about contraints. Wonder if that author is famailar with this book?
14. Chapter 17 - Systems Analysis and Constrained Optimization. The Masters degree TRW sent us to was about Systems Engineering and Systems Management. This is one of the chapter we paid close attention to.
15. Chapter 18 - Coping with Un-reconcilable and Unquantifiable Goals. Lots of decisions deal with these two conditions. "Deciding" means performing an "Analysis of Alternatives" from a microeconomic point of view. This is course means knowing something about the three variables of all projects. One of which is cost.
16. Chapter 19 - Coping with Uncertainties: Risk Analysis
17. Chapter 20 - Statistical Decision Theory: The Value of Information. Much of the discussion around current "estimating" processes fails to deal with the statistical processes involved in those decision. Small samples - 5 cycles, self-selected samples, uncalibrated baselines, use of terms (bayesian) without working examples of their use - all seem to have entered the conversation. This chapter can provide insight to managing software projects using statistical processes.
18. Chapter 21 - Seven Basic Steps in Software Cost Estimation. When it is mentioned "software can't be etimated," this chapter had better have been read and found flawed with working, reviewed examples of it not working. Conjecture is no substitute for facts.
19. Chapter 22 - Alternative Software Cost Estimation Methods. When we hear "we're exploring for new ways to estimate" wonder if this chapter has been read?
• Algorithmic models
• Expert judgement
• Estimation by analogy
• Parkinsonian estimating
• Price-to-Win estimating
• Top-down estimating
• Bottom-up estimating
• Summary comparison of methods
• So next time we hear "we're exploring altenative" ask straight out - "What are those alternatives, where have you had success with them compared to other methods, what domain have you had this success, and can you share the details of this success so others can asertain if they might be applicable in their domain? 
• When there is no information forthcoming to these questions, think hard about the veracity of the speaker. Maybe they don't actually have a solution to this critically important problem that is still with us in 2014.
20. Chapters 23 - 29 are about the details of the COCOMO model
21. Chapters 30 - 33 are about software cost estimation and life-cycle management using more the COCOMO model

So What's the Point of All This?

When we hear estimating can't be done for software, we actually know better. It is being done in every software domain. Tools, processes, books, papers, conferences, vendors, professional organizations will show you how.

When we hear this, we now know better.

[1] "Software Engineering Economics," Barry W. Boehm, IEEE Transactions on Software Engineering, Volume SE-10, Number 1, Januarym 1984, pages 4-21.

[2] This is the crux of the post, the book and the discussion around the conjecture that we can make decisions about how to spend other peoples money with estimating that spend. 

Related articles

Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices