<story><title>The True Cost of Rewrites</title><url>https://8thlight.com/blog/doug-bradbury/2018/11/27/true-cost-rewrites.html</url></story><parent_chain><item><author>jacquesm</author><text>A good rewrite is done bit-by-bit releasing the rewritten work immediately. This forces you to focus on deliverable chunks rather than code-for-code&amp;#x27;s-sake and to test your assumptions instantly. If you do not release your work there is a very large chance that it will all be for nothing.&lt;p&gt;A good rewrite happens so subtly that end-users and operators will never really realize that a rewrite is underway.&lt;p&gt;There are only very rare cases where a rewrite in big-bang fashion is indicated and even then the bulk of those will be incompetence on the part of the tech crew because they see no way to turn the job into an incremental one (or do not want to see a way).</text></item></parent_chain><comment><author>TimJYoung</author><text>This is 100% correct.  We&amp;#x27;re in the process of doing this now with our products (and our internal systems, also), and it works well.&lt;p&gt;When you have products and systems that have been around for a decade or more, major portions of them become outdated and need to be rewritten (or largely rewritten, the two are synonymous to me).  Best practices in crypto change, operating systems and hardware improve&amp;#x2F;change, etc., and if you want to keep generating value, you had better change along with it.  You can see where organizations &lt;i&gt;don&amp;#x27;t&lt;/i&gt; do this: the developers force weird constraints on IT like needing to use old, obsolete versions of operating systems because the software won&amp;#x27;t run on newer versions.&lt;p&gt;Along these lines, one of the problems that I think exists with the software industry today is an inability among developers to recognize that software sticks around a lot longer than one might originally envision.  And this phenomenon only gets worse (better, for the end user) as the value provided by the software increases.  It&amp;#x27;s a bit of a Faustian bargain: everyone wants their software to be used and provide value, but often don&amp;#x27;t realize the &amp;quot;soft commitments&amp;quot; being made in the background that can tie you (or the business) to the code for years (or decades).</text></comment>
<story><title>The True Cost of Rewrites</title><url>https://8thlight.com/blog/doug-bradbury/2018/11/27/true-cost-rewrites.html</url></story><parent_chain><item><author>jacquesm</author><text>A good rewrite is done bit-by-bit releasing the rewritten work immediately. This forces you to focus on deliverable chunks rather than code-for-code&amp;#x27;s-sake and to test your assumptions instantly. If you do not release your work there is a very large chance that it will all be for nothing.&lt;p&gt;A good rewrite happens so subtly that end-users and operators will never really realize that a rewrite is underway.&lt;p&gt;There are only very rare cases where a rewrite in big-bang fashion is indicated and even then the bulk of those will be incompetence on the part of the tech crew because they see no way to turn the job into an incremental one (or do not want to see a way).</text></item></parent_chain><comment><author>agumonkey</author><text>It makes me think of a dual of modular system design, a rewrite should aim at finding or validating minimal interfaces so a subsystem can be rewritten (the goal of modules I believe) at minimal cost and uncertainty.</text></comment>