|
> That sounds great, but hard decisions are hard because there isn't time, money, other resources to have all the facts, yet a decision must be made. While I am sympathetic to the concept of reasoning under uncertainty, the way you've framed it is hardly engineering anymore. Design projects come with a spectrum of data requirements, and each has its own cost function for improved accuracy. For example, knowing exactly how long the bridge you need to build matters greatly, and the cost of surveying should be pretty low. In contrast, measuring the soil at the site you build on top of has a variety[1] of options with varying costs. You can't ever be 100 percent certain that your sampling was good enough, but the samples more you have the more confident you can be. Depending on the project and design, you may not need the most expensive and most accurate option, but you probably don't want to just rely on priors built through "experience." Translating this to the world of software, we have a variety of data collection strategies. A/B tests, canaries, software instrumentation, tracing, offsite monitoring, f-scores, beta tests, market surveys, and more. The best thing you can do as an engineer making an uninformed choice is to design the system to collect the data you are missing and to make it easy to change your design later. Amazon calls these "two way doors" versus "one way doors"; if your decision was wrong you can go back and make a different choice. As an example, if you are designing a caching system, spending a bit of time to generalize the API will allow you to swap between policies as you collect data about cache hit rates. If you don't, the cost of changing your mind goes up as more things depend on the nuances of your API. Rather valorize making uninformed decisions, I'd prefer to valorize flexibility and continuous data collection. Seen this way, the old adage "There's never enough time to do it right, but always plenty of time to do it over" is a coherent philosophy. [1]: https://en.wikipedia.org/wiki/Geotechnical_investigation#Soi... |