The lead article is "Conservatism After Trump" by senior editor William Voegeli. Here are some representative quotes [with the same example, namely, private health insurance vs. Medicare-for-All, inserted by way of illustration in each quote]:
-
In How to Be a Conservative (2014), the English philosopher Roger Scruton says that conservatism originates in "the sentiment that good things [e.g. private health insurance] are easily destroyed, but not easily created [Medicare-for-All]."
[We take current conditions for granted.] In doing so, we stop comparing our condition [private health insurance] favorably with known, existing alternatives and begin comparing it unfavorably with hypothetical possibilities [Medicare-for-All].
[O]ne of the most basic conservative principles, as summarized by Thomas Sowell [is]: don't replace one thing that works [private health insurance] with a different thing that sounds good [Medicare-for-all].
This same basic thought was precisely what I was getting at recently when I wrote in my blog:
-
Following Burke, I am guided by the following principle: as soon as a person starts talking about tearing the entire system (private health insurance) down and replacing it from the ground up (with Medicare-for-all), I know s/he is a charlatan. For, as Burke correctly observed, when you tear down the entire system, what you end up with is not a wonderful new system, but a wasteland. This is because you have destroyed the old system and then you discover that replacing it with a new system from the ground up is frighteningly more complex and expensive -- and oftentimes bloody -- than you ever could have imagined. The French and Russian Revolutions taught us this lesson. And it is with the horrors of the French and Russian Revolutions in mind, that we ought to reject the crazy, utopian, abstract, socialist theorizing of the Kamala Harrises and Alexandria Ocasio-Cortezes of the world.
The interesting thing is that the same principle frequently applies to software engineering.
That is, whenever someone starts talking to you about "refactoring" a body of code, your bullshit meter should start flashing red. Code almost always starts out with a nice, clean, architecturally and algorithmically sound design. Over the years, as the code is used in real life and is modified to handle real problems, it accumulates cruft to perform various kinds of special purpose processing. Inevitably, some young software engineer comes along, looks at the code, and says "This code is really ugly. It needs to be refactored." (This software engineer was often named Sabaziotatos.) Oftentimes, the young software engineer is influenced by the latest trends in "cool" new technology and wants to rewrite the old code base to use the cool new technology.
The young software engineer ends up replacing the old body of code, which has been in operation for a long time and works, with a new body of code that is very pleasant to look at, and works mostly, but fails to handle all the various special purpose processing problems (some of which the young software engineer was not even aware of) and has bugs of its own. This young engineer's work is performed at great expense to the company and at great inconvenience to the customers, who need to replace their old software with the new software and who are the ones, inevitably, who discover that their particular special purpose processing doesn't work any more or that the new software has the new bugs.
In other words, as Thomas Sowell warned: don't replace one thing that works with a different thing that sounds good.
No comments:
Post a Comment