We find no sense in talking about something unless we specify how we measure it. A definition by the method of measuring a quantity is the one sure way of avoiding talking nonsense — Sir Hermann Bondi
So when we hear a suggested approach to solving any problem, what are the units of measure of the discussion elements, the inputs to that discussion, and the outcomes?
Micro-economics is defined as
A branch of economics that studies the behavior of individuals and small impacting players in making decisions on the allocation of limited resources. Typically, it applies to markets where goods or services are bought and sold.
Certainly in the software development business, goods are bought and sold. Software is developed in exchange for money. The resulting product is then put to work to generate some monetized value for the buyer. The value exchanged for the cost of that value is usually assessed as the Return on Investment
ROI = (Value - Cost of the Value) / Cost of the Value
Let's start with some basic concepts of writing software for money. I'd suggest these are immutable concepts in a for proft business world. The book on the left is a good start - The Economics of Iterative Software Development - but there are other materials about the economics of software development. The one that comes to mind is Software Engineering Economics, Barry Boehm, Prentice Hall. While some has suggested this book is dated and no longer applicable to our modern software development paradigm, that could only be true if our modern paradigm is not subject to the principles of micro-economics. And that is unlikely, so let's proceed with applying the principles of micro-economics to the problem at hand. That problem is
How can we know the cost, schedule, and performance of a software product with sufficient confidence into order to make business (micro-economic) decisions about how to manage the limited resources of the project?
Those resources are of course the variables we are trying to determine. Cost, Schedule, and Performance. Each of which contains resources. Cost in software development is primarily driven by staff. Schedule is driven by the efficacy of that staff's ability to write code. And the performance of the resulting outcomes are driven by the skills and experience of the staff, who is consuming the funds (cost) provided to the project.
So if we look at the basics of the economics of writing software for money, we'll see some simple principles.
If it's a product development effort, someone in the marketing and sales department has a planned release date. This date and the projected revenue from that release is in the sales plan. These are random numbers of course - so I won't repeat that, but all numbers in business are random numnbers until they get entered into the General Ledger.
- These projected revenue numbers are based on releasing the product with the features needed for customers to buy it.
- The cost to develop that product is subtracted from the revenue - usually in some complex manner - to produce the retained earnings attributed to the product.
- This of course is the simple formula
- Earnings = Revenue - Cost
- Where cost is categorized in many ways, some attributable to the development of the product, some to overhead, benefits, fringe, and other indirect costs (ODC).
- Revenue recognition is a continuously evolving issue with taxes and performance reporting in actual firms
- But for the purposes here, the simple formula will do. Managerial Finance, Brigham and Weston is a good place to look for the details.
If it's a service effort, the customer has engaged the firm to perform some work in writing software, doing consulting around that software, integrating existing software or some combination of these and other software related services. Managing the Professional Services Firm, was mandatory reading along wioth other internal company written books when I worked for a large Professional Services (PS) firm. With our small firm now, we still refer to that book.
- Some type of problem needs to be solved involving a solution that uses software (and maybe hardware), processes, and people.
- The cost, schedule, and capabilities of the solution need to be worked out in some way in order to know what DONE looks like. Any one subscribing to this Blog know the Knowing What Done Looks Like is a critical success factor for any effort.
- But in the case of a services solution, this knowing is a bit more difficult than the product solution, since the customer may not know themselves.
- This is the golden opportunity for incremental and itertaive development.
- But in the end the PS customer still needs to know the cost, schedule, and what will be delivered, because that person has a similar ROI calculation to do for those funding the PS work.
