<story><title>Things You Should Never Do, Part I (2000)</title><url>https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/</url></story><parent_chain><item><author>bdw5204</author><text>The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else&amp;#x27;s code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself.&lt;p&gt;This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated design for seemingly no reason. Usually, these turn out to be unreadable messes as well a generation later once everybody has moved onto the latest and &amp;quot;greatest&amp;quot; coding style trend.&lt;p&gt;Instead of doing rewrites, you can just refactor code. That means, among other things, deleting obsolete code for platforms you no longer support and, in the case of C&amp;#x2F;C++, converting macros to functions. You can also document the codebase (with comments not commit messages) so that developers understand what the code does and why it is there. But a full rewrite is usually a bad idea that will just introduce new bugs and remove existing functionality.&lt;p&gt;Refactor vs rewrite is basically the software development equivalent of reform vs revolution in political science and everybody with even a minimal knowledge of history knows that revolutions usually end badly with an even worse regime taking power. Likewise, the failure to accept the need for reform (i.e. refusing to allow refactoring) inevitably leads to revolution.</text></item></parent_chain><comment><author>ehnto</author><text>This is why I recommend using a framework in commercial projects, and following it&amp;#x27;s idioms as closely as makes sense for your project.&lt;p&gt;It means there is a shared idiomatic approach across your team and all the documentation for it is just the framework documentation. It is also easier to hire devs, if you can vet their ability to write idiomatic code in a specific framework then you can better assume they will mesh well with yor codebase.&lt;p&gt;It is a communication and empathy problem at its heart. You are being empathetic to future devs and future you by acknowledging the knowledge they would need to work on your code. Then the communication of your idioms is baked into the framework ecosystem and docs.</text></comment>
<story><title>Things You Should Never Do, Part I (2000)</title><url>https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/</url></story><parent_chain><item><author>bdw5204</author><text>The main reason why developers do rewrites is because it is easier to read your own code than it is to read somebody else&amp;#x27;s code. Doing a rewrite means you only have to work with code that was written by your current coworkers or by yourself.&lt;p&gt;This is also the core motivation behind all of the schemes to force a single coding style on all developers at the cost of performance and usually with an extremely complicated design for seemingly no reason. Usually, these turn out to be unreadable messes as well a generation later once everybody has moved onto the latest and &amp;quot;greatest&amp;quot; coding style trend.&lt;p&gt;Instead of doing rewrites, you can just refactor code. That means, among other things, deleting obsolete code for platforms you no longer support and, in the case of C&amp;#x2F;C++, converting macros to functions. You can also document the codebase (with comments not commit messages) so that developers understand what the code does and why it is there. But a full rewrite is usually a bad idea that will just introduce new bugs and remove existing functionality.&lt;p&gt;Refactor vs rewrite is basically the software development equivalent of reform vs revolution in political science and everybody with even a minimal knowledge of history knows that revolutions usually end badly with an even worse regime taking power. Likewise, the failure to accept the need for reform (i.e. refusing to allow refactoring) inevitably leads to revolution.</text></item></parent_chain><comment><author>SoftTalker</author><text>In 2000, refactoring was not really a thing as few projects had many automated unit tests and any change to the code had to be tested manually.</text></comment>