Second-Order Thinking
This article, and some of the comments here, seem to confuse &quot;second-order&quot; with &quot;long-term&quot;.<p>Long-term just means doing the same analysis far out into the future: &quot;If I spend less on maintaining software product $LEGACY, I will save money. If I continue to do this, I will save more and more money by each passing month.&quot;<p>Second-order means discovering neighbouring causal links. &quot;If I spend less on maintaining software product $LEGACY, I will save money. I will however also have to prioritise which bugs I fix. This will lead to some bugs that would be fixed today not getting fixed. That might mean that some users of $LEGACY move to a competitor. In turn, it costs more to acquire new customers than to retain old ones, so just maintaining the same customer count while dissatisfying customers until they quit will cost more money than by trying to make existing customers happy.<p>&quot;Quitting $LEGACY customers will however lead to fewer bugs being discovered in $LEGACY, meaning the reduced maintenance budget might be sufficient again. However, quitting customers doesn&#x27;t only force me to spend more to re-acquire similar number of customers – it might also be negative for marketing, so it becomes harder to acquire new customers, thus having a non-linear effect on the customer replacement costs.<p>&quot;Decreased maintenance of $LEGACY might make some developers happier, but signal to others that we are not serious about the lifecycle of our product. This might result in them not putting in as much effort to make maintenance easier in future products, which will increase the maintenance demand in future products. Thus, insufficient maintenance efforts on $LEGACY may lead to increasing maintenance demand, which leads to insufficient maintenance efforts, which leads to increasing maintenance demand, and so on.&quot;<p>As the last parts of that hint at, what&#x27;s really important is not all the neighbouring causal links, but those that lead to nonlinearities and feedback cycles. By mucking about with things in a stable system, in particular when there are nonlinearities and feedback cycles involved, you can accidentally create an unstable system that wants to drive itself into the ground.