0 > 0.5
When I first started to study computer science 6 years ago, it was a long long period of suffering. One day, after spending 3~4 hours debugging my homework, I fell into desperation and sent an email to the TA.
“I’m having a problem with my assignment.” There I wrote, “I debugged for over 3 hours, it still doesn’t work. Can you please help me to find the bug?”
I supposed he would help because I knew it would take him no more than 3 minutes. However, I received an email saying: “I don’t debug any code. If you can’t fix it, just rewrite.”
My desperation turned into desperate anger immediately. I was about to type a reply asking him if ever a TA’s duty was to help his students. But wait a minute, there must be reasons for him to say so. I tried to calm myself down and step back to see what I neglecte. Then I realized, if nobody gonna help me on my code, rewriting it was truly the best way to pull me out. So I, (still with uncontrollable anger,) replied to him, “Your suggestion is helpful. Thanks.” Then I rewrote my code and it worked.
Do you see the magic there? Starting over is sometimes (if not often) better than patching up. It is not only useful in computer science, but also in game development and beyond. It has saved me over and over. But why?
Why do people keep shitty code? Why didn’t I rewrite my code before told so? Even if the new one doesn’t work, I can simply submit the old code. (And in the context of game development, the developers can always ship the old game version.) Then why do so many developers keep working on shitty projects and ship mediocre products?
It is the power of habits that makes us stick to the shitty code! And although we always tend to keep our habits without realizing why, many many reasons are indeed behind this simple decision. One major reason is the consideration of safety and fear of risk. “Patching up” can always ship a predictable product, while “starting over” doesn’t guarantee anything. Nobody can predict how well the new one will work or how fast it will progress, until they start over. The new work could end up worse than the old one, or it might not be finished before the shipping date; then people miss the chance to polish the old work. In the image 1-(2) below, the light-blue line could have grown less sharp.
Image 1. Product Quality: Patching up vs. Starting over
Another important reason is that we always want to feel our life under control. Admitting the failure of the old work, facing the fact that all the efforts are wasted and are the result of bad management, is not an easy thing, even if no other people are involved. While staying in the old armchair, lingering around the imagined joy, convincing ourselves that the efforts spent are valuable and we are not idiots, is much easier and more comfortable than reality.
Sounds fair? Yes. Practical? No. For those sunk costs that have already been incurred and cannot be recovered, they are gone forever. To stop the loss, what we really need and should do is to analyze our current situation objectively, in order to make the decision on whether to start it over. Those conditions include the old work we have at hand, the potential of its future progress, the potential of the new work, the resources (time, budget, etc.) left…... and most importantly, the real goals of the project. Generally speaking, starting over is a faster way to achieve greatness for those projects that have met serious problems. So if the developers desire greatness and the project has little limitations in resources, starting over is the choice for them (like the development of Half-Life). While in many cases a safe revenue is the first mission, then they’d better not risk.
Some people may argue that since the old work has been partially finished, it will be easier to reach greatness than a newly started one; while I argue exactly the opposite. When the old work meets serious problems, like the code I debugged for 3 hours, it could be something unfixable (which means only breaking the main architecture or design could fix it), or hiding in the blind zones of the developers. Fixing the former one takes too much time (in programming, usually takes longer than rewriting the architecture), and the later one is really difficult to find. It is just like, shit is always shit. No matter how we polish a shit, it is still shit. We can choose to break its nucleus to turn it into gold (or anything we want), but it is either out of our abilities, or simply costs too much resources.
|Patch up||Start over|
|Shitty code get polished||Who knows|
|Shitty code are always shitty||The possibility to get not-shitty code|
|Need to find your blind zone that hides bugs||Can freely decide a new way to implement|
(1) In Programming
|Patch up||Start over|
|A shitty game gets polished||Who knows|
|Shitty games are always shitty||The possibility to get a not-shitty game|
|Need to find out why the shitty game is shitty||Can freely design a new game|
(2) In Game Development
|Patch up||Start over|
|Shitty boyfriend||No boyfriend|
|Shitty boyfriends are always shitty||The possibility to get not-shitty boyfriends|
|Need to find out why you were so blind to have chosen this shitty boyfriend||Can freely choose from other boys|
(3) In Relationships
Table 1. Cases when Starting over is Better than Patching up
0>0.5; starting over is better than patching up; definitely change boyfriends once we find out the old ones are assholes. The earlier, the happier. Cheers!
 Sunk cost wiki: https://en.wikipedia.org/wiki/Sunk_cost
 The Cabal: Valve’s Design Process For Creating Half-Life: http://www.gamasutra.com/view/feature/3408/the_cabal_valves_design_process_.php