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
- To make a book easy for students to learn from
- To make a book easy for professors to teach from
- 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.
- Chapter 1 - Case Study of the Scientific American subscription processing system.
- Chapter 2 - Case Study of an Urban School Attendance system
- Chapter 3 - Goals of Software Engineering
- 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.
- 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.
- Chapter 6, 7, 8, and 9 - The COCOMO Model: Development Modes,Activity Disribution, Product, and Component level
- Chapter 10 - Performance Models and Cost-Effectiveness Models
- Chapter 11 - Production Functions: Economies of Scale
- 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. 
- 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.
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.
 "Software Engineering Economics," Barry W. Boehm, IEEE Transactions on Software Engineering, Volume SE-10, Number 1, Januarym 1984, pages 4-21.
 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.