Going Halfway

Someone¹ once said "There is nothing so useless as half of a bridge.  You've wasted resources that could have been used on something useful, and you still can't get across the river."  There are a lot of things which are like bridges, and are worse than useless if you don't finish them.  But there are a lot of things that are worth starting even if you can't finish.  If you're starving, it's worth eating a little, even if you can't afford a full meal.  Likewise, if you've got a federal deficit, raising taxes on rich people will reduce the political pressure to resolve the problem and not hurt the economy in any way that is borne out by economic history, even though it won't completely solve the problem.

There are lots of cases where going halfway is a lot worse than finishing the job.  The space shuttle was conceived as a much bigger project, with more, larger vehicles.  Cost cutting reduced the efficiency of the ultimate design to the point that the total cost of the program was 450% (correcting for inflation) of the predicted cost of the more ambitious program delivering less than 10% of the projected payload to space.  Most experienced engineers have been involved in projects where cutbacks intended to reduce development time or costs had the effect of increasing them--while damaging the product more than could possibly be made up by reduced costs².

When deciding to cut back a project, be it a small engineering project or a national health care system, it's important to try to decide if you're saving money or producing half of a bridge.  The evidence is pretty overwhelming--single payer healthcare, such as US medicare or the British national health, is far cheaper and produces better outcomes than piecemeal "market based" systems.  People must have adequate health care.  Cutbacks to medicare and medicaid will either make healthcare more expensive, or kill thousands.

¹ I think this may have been the military strategist Karl von Clausewitz, but I haven't been able to find the reference.
² My own experience with this was Microsoft C6.  We'd planned an 18 month development cycle, but about 4 months in, this was shortened to 6 months.  Three years later, we finally shipped a vastly inferior product to the one we'd have built on the original schedule, at perhaps triple the cost, to great loss of market share and prestige, and provoking most of the technical talent to leave the team.