{"id":260,"date":"2018-03-13T01:17:32","date_gmt":"2018-03-13T01:17:32","guid":{"rendered":"http:\/\/freedville.com\/blog\/?p=260"},"modified":"2019-04-12T14:04:19","modified_gmt":"2019-04-12T14:04:19","slug":"beware-the-allure-of-rewriting-code","status":"publish","type":"post","link":"https:\/\/freedville.com\/blog\/2018\/03\/13\/beware-the-allure-of-rewriting-code\/","title":{"rendered":"Beware the allure of rewriting code"},"content":{"rendered":"<p>I was recently reading some code and there was a subroutine that felt about twice as long as it should have been.&nbsp; As I pondered this subroutine, and wondered why nobody rewrote a shorter version of it, I remembered a great line from a Joel Spolsky article (<a href=\"https:\/\/www.joelonsoftware.com\/2000\/04\/06\/things-you-should-never-do-part-i\/\">Things You Should Never Do, Part I<\/a>):<\/p>\n<blockquote><p>Back to that two page function. Yes, I know, it\u2019s just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I\u2019ll tell you why: those are bug fixes.<\/p><\/blockquote>\n<p>Those are bug fixes!&nbsp; I first discovered this article over ten years ago, but as I progressed in my career this advice rang truer every day.&nbsp; Some code may truly be unmaintainable, but the fact of the matter is that more bug fixes, more complexity,&nbsp; and more edge cases are built into any system as it matures.<\/p>\n<p>It takes patience to examine code in this careful way, rather than declaring a rewrite is necessary.&nbsp; I used to think the desire to rewrite code was entirely tied to NIH (<a href=\"https:\/\/en.wikipedia.org\/wiki\/Not_invented_here\">Not Invented Here<\/a>), but Spolsky truly gets to the root of it.<\/p>\n<blockquote><p>We\u2019re programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We\u2019re not excited by incremental renovation: tinkering, improving, planting flower beds.<\/p>\n<p>There\u2019s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation:&nbsp;<i>they are probably wrong.<\/i>The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:<\/p>\n<p>It\u2019s harder to read code than to write it.<\/p><\/blockquote>\n<p>None of this is meant to say that all code you inherit is perfect.&nbsp; Quite the opposite, in fact.&nbsp; After you take a fair stock of the pros in the inherited code, it&#8217;s completely reasonable to address the cons.&nbsp; Refactoring is the best way to improve code while retaining its best characteristics.&nbsp; This is made much easier when the code is covered by a high-quality automated test suite &#8211; I am so glad we have more of these now, compared to the bad old days before test automation was popular!<\/p>\n<p>Spolsky addresses several forms of refactoring: for cosmetics, for performance, and architectural refactoring.&nbsp; This advice was as true at its publication in 2000 as it is now.&nbsp; The architectural advice has changed a bit &#8211; maybe you want to wrapper or refactor some code out to a microservice.&nbsp; <a href=\"https:\/\/www.ibm.com\/developerworks\/cloud\/library\/cl-refactor-microservices-bluemix-trs-1\/index.html\">Refactoring a monolith to microservices<\/a> is a much better approach than simply rewriting the monolith from scratch.<\/p>\n<p>Lastly, consider that while you are rewriting code, you are probably not delivering value to your users.&nbsp;&nbsp;<a href=\"http:\/\/freedville.com\/blog\/2018\/02\/18\/work-in-progress-delivers-no-value\/\">Work in progress delivers no value<\/a> &#8211; and a major rewrite causes major work-in-progress.<\/p>\n<p>Software code can always be improved, and it&#8217;s rare that a complete rewrite is the way to improve it.&nbsp; Consider the above advice before changing more than you need to.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I was recently reading some code and there was a subroutine that felt about twice as long as it should have been.&nbsp; As I pondered this subroutine, and wondered why nobody rewrote a shorter version&#8230;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[11],"_links":{"self":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/260"}],"collection":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/comments?post=260"}],"version-history":[{"count":4,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/260\/revisions"}],"predecessor-version":[{"id":406,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/posts\/260\/revisions\/406"}],"wp:attachment":[{"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/media?parent=260"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/categories?post=260"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/freedville.com\/blog\/wp-json\/wp\/v2\/tags?post=260"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}