One of the major points of the Joel article is that the best option is usually one you didn&#x27;t name; incrementally fix the &quot;crappy&quot; codebase. At no point do you do a &quot;big rewrite&quot;, at no point do you have a big step back, at no point do you lose the ability to make forward progress because the new code isn&#x27;t ready and the old code is deprecated, etc. Even if it may take somewhat longer to get there, the integral of value over time often still comes out larger for incremental improvement.<p>Developers want the default answer to &quot;abandon the old mess and write a new one&quot; (snarkiness fully on purpose); Joel&#x27;s point is that the default answer ought to be incremental improvement. Not that it&#x27;s <i>always</i> the right answer, but other answers ought to be scrutinized more closely than developers might like.<p>From a professional point of view, it&#x27;s actually <i>perfectly fair</i> to consider that greenfielding a new project with hot new tech (or even &quot;newer&quot;-but-established tech, my personal favorite choice) is more fun than trudging through old code. Human factors matter a lot. But we are also professionally obligated not to overprivilege it.<p>Besides, if you treat it as a serious project instead of a series of hack jobs, in my experience, very serious incremental improvement still offers a lot of engineering challenge and fun. I think one of the biggest mistakes people make is to prejudge incremental improvements as a hack job, when it becomes a self-fulfilling prophecy.