I am still not convinced that your examples show that it would be unreasonable to estimate their monetary impact. Since a company is an organic whole, every fu

I am still not convinced that your examples show that it would be unreasonable to estimate their monetary impact. Since a company is an organic whole, every functional part of it would netting out in the millions if considered in isolation. However, such a perspective is usually without practical significance, as it is not linked to concrete business-relevant scenarios. If there is no risk[1] that something that functions properly could fail, then the costs associated with such a failure never occurring are irrelevant. I would also concede that many things cannot be estimated accurately or might be very hard to estimate. But in my experience, the really difficult decisions are those that relate to new big and complex things, such as what technology to use for an innovative product. Evaluating whether it is worth improving a specific detail of an existing application is most of the time far less difficult. Let me give you an example from my current work: It is a business application to process customer enquiries that result in an offer for a tailored product. In a specific scenario we know that we can process 5 enquiries per hour. The goal is to process 6, an increase of 20%. There are about 6,000 enquires per month, meaning saving 200 staff-hours per month. The hourly costs for software development are about 4 times the costs for the staff using the application. That means that for every 50 hours it would take me to reach that goal, the break-even point would move by one month. I estimated that I could reach the goal by putting betwenn 100 and 150 hours into it. This precision was enough to get the green light from the management.[2] And management does not really care how I reach that goal in detail (by improving the performance of the database, by reworking the user interface, by using better templates as a basis for the tailored products, ...). And even if my estimates were off by a factor of 2 or 3, it would still be worthwhile to attempt the improvement. Regarding your case about the quality of an API, I cannot see a fundamental difference to the case I just described. Set some time and/or quality goals for the improvement of the API and attache a reasonable price point to everything. Than see, whether it makes economic sense at all, whether something else promisses a better return on investment, or if this is the best thing to do now. Finally, I would like to emphasise that the correct thing to do is never only purely a question of technology. Notice, for example, how the assessment of the case I described above changes with the number of enquires per month. Were there only 1,000 enquires per month, the break even point would be 6 times further away, which means that there might probably exist a lot more other fields more worthwhile for the company to invest their money in (and not all in IT). [1] More precisely, the risk is seen as marginal or irrelevantly small, or if it occurs there is no way to manage it anyway (a meteorite hits the factory), or circumstances are so fundamentally changed that the entire business model is called into question. [2] Actually it was the other way round: The management came up with the idea to improve the process by 20% and already had some suggestions how to do it. Then I looked at it and gave my rough estimates and own suggestions what could be done.