One situation that lends itself quite well to half-arsing is working to maximise the performance of a system that consists of a number of components, where the performance of the system is bottlenecked by the weakest performing component. You can get pretty far by (i) identifying what the bottleneck of the whole system is, (ii) figure out the cheapest/easiest move to eliminate the bottleneck, and then (iii) iterating. There's little value in full-arsing the performance of a ccomponent if it is not the system bottleneck and unlikely to become the bottleneck any time soon.<p>E.g. suppose we've got a system with three components A, B and C, so that perf(system) := min { perf(A) , perf(B) , perf(C) } . Currently perf(A) is 0.3, perf(B) is 0.5 and perf(C) is 0.4, so the performance of the system is 0.3 since it is bottlenecked by A. You have an elegant idea to reengineer C completely which should lift perf(C) to the region of 0.9 -- 0.95 but it will take a few months to prototype and sort out the details. You've also got a lamentable idea for a hack to increase perf(A) from 0.3 to 0.5 -- it's a dead end and the hack cannot be extended in future, but can be cobbled together quickly. What's your move?<p><a href="https://en.wikipedia.org/wiki/Theory_of_constraints" rel="nofollow">https://en.wikipedia.org/wiki/Theory_of_constraints</a>