When we encounter simple answers to complex problems, we need to not only be skeptical, we need to think twice about the credibility of the person posing the solution. A recent example is:
The cost of software is not directly proportional to the value it produces. Knowing cost is potentially useless information.
The first sentence is likely the case. Value of any one feature or capability is not necessary related to it's cost. Since cost in software development is nearly 100% correlated with the cost of the labor needed to produce the feature.
But certainly the cost of developing all the capabilities and the cost of individual capabilities when their interactions are considered must be related to their value or the principles of Microeconomics of Software Development would not longer be in place.
Microeconomics is a branch of economics that studies the behavior of individuals and small impacting organizations in making decisions on the allocation of limited resources. Those limited resources include (but are not limited to) Time and Money.
So without knowing the cost or time it takes to produce an outcome, the simple decision making processes of spending other peoples money based on the Return on that Investment gets a divide by zero error
ROI = (Value - Cost) / Cost
Since all elements of a project are driven by statistical processes, the outcomes are always probabilistic. The delivered capabilities are what the customer bought. Cost and Schedule are needed to produce those capabilities. The success of the project in providing the needed capabilities depends on knowing the Key Performance Parameters, the Measures of Effectiveness, the Measures of Performance, and the Technical Performance Measures of those capabilities and the technical and operational requirements that implement them.
The cost and schedule to fulfill all these probabilistic outcomes is itself probabilistic. It is literally impossible to determine these outcomes in a deterministic manner when each is a statistical process without estimating. The Cost and Schedule elements are also probabilistic, further requiring estimates.
The notion that you can determine the Value of something without knowing its Cost is actually nonsense. Anyone suggesting that is the case has little understanding of business, microeconomics of software development or how the world or business treats expenditures of other peoples money.
Here's some background to help in that understanding:
- Value Stream: Generally Accepted Practice in Enterprise Software Development, Mark Kennaley.
- The Road Map to Software Engineering: A Standards Based Guide, James W. Moore
- Estimating Software-Intensive Systems: Projects, Products, and Processes, Richard D. Stutzke
- The Incremental Commitment Spiral Model: Principles and Practices for Successful Systems and Software, Barry Boehm, Jo Ann Lane, Supannika Kollmanojwong, and Richard Turner
- Facts and Fallacies of Software Engineering, Robert L. Glass
- Forecasting and Simulating Software Development Projects, Troy Magennis
- The Economics of Iterative Software Development: Steering Toward Better Business Results, walker Royce, Kurt Bittner, and Mike Perrow
- Performance-Based Project Management, Glen B. Alleman
- Probability Methods for Cost Uncertainty Analysis: A Systems Engineering Perspective, Paul R. Garvey
- Project Management the Agile Way: Making it Work in the Enterprise, John C. Goodpasture
- Agile Project Management for Government: Leadership Skills for Implementation of Large-Scale Public Sector Projects in Months, not Years, Brian Wernham
- Agile Information Systems: Conceptualization, Construction, and Management, edited by Kevin C. Desouza
- Agile Project Management, Jim Highsmith
- Managing Agile Projects, edited by Kevin Aguanno
And for any suggestion that cost is not important in determining value please read
- Essential of Managerial Finance, 11th Edition, Fred Weston, Scott Besley, and Eugene Brigham
Between this last book and the books above and all the papers, articles, and training provided about how to manage other people's money when producing value from software systems, you'll hopefully come to realize those notions that we don't need to know the cost, can't know the cost, and poor at making estimates, and should simply start coding and see what comes out are not only seriously misinformed, but misinformed with intentional ignorance.
If your project is not using other peoples money, if your project has low value at risk, if your project is of low importance to those paying, then maybe, just maybe they don't really care how much you spend, when you'll be done, or what will result. But that doesn't sound very fulfilling where I live.
And a final BTW, using a small sample of past performance, without adjusting for variances, adjusting for irreducible (aleatory) uncertainty, and adjusting for Reducible (epistemic) uncertainty - all three create risks - is simple driving in the dark with the lights off. A simple High School statistics class will show how to Not Make That Type of forecast. Once you enter to domain of spending other people's money - at least a non-trivial amount of money - much better statistical forecasting will be needed is you have any hope of showing up before the need date, below the planned budget, and with the required capabilities to earn back the cost in exchange for delivered value. To learn how to use probability and statistics for estimating software intensive systems, buy and read the book to the left