The old adage \u2018if it\u2019s not broken, don\u2019t fix it\u2019 was coined in the days when technology was beginning to enter people\u2019s houses, in an age when trying to get rid of a whirring sound in your refrigerator could end up with a great deal of melting ice cream. It is also a saying that many if not most developers have heard at least once in reference to code.<\/p>\n\n\n\n
On the surface, it appears to be not just correct but self-evident: if a piece of code is doing what it should be, then surely there can be no reason to change it. But is that really true?<\/p>\n\n\n\n
The short answer is no<\/em>. Not wanting to improve code is a sign that one is afraid of the consequences of changing it, which happens almost exclusively when one doesn\u2019t properly understand the code. And you should always understand the code you are working on, or at least strive to understand it.<\/strong><\/p>\n\n\n\n The longer answer is\u2026 it depends<\/em>.<\/p>\n\n\n\n The trouble with applying this adage to the world of programming is that it\u2019s harder to say when exactly changing code qualifies as \u2018fixing\u2019 it. If I rewrite part of a project to simplify it and make it easier to read, but I keep its fundamental logic and functions intact, am I really fixing<\/em> it? Or am I simply giving it a new sheen?<\/p>\n\n\n\n Leaving aside issues related to the code\u2019s legibility, there are in my opinion 3 main cases in which amending functional code qualifies as a fix. The first is when code is made more efficient<\/em>, which is necessary when the code is indeed working, but not as quickly or as well as it could. The second is when the code does what it should, but its maintenance is inordinately difficult. The third and most important is when the code only appears<\/em> to be working, meaning that it passes most tests but cannot deal with edge cases, or else it can handle data at a certain scale but not outside of it. In these circumstances, you should definitely consider fixing code that works.<\/p>\n\n\n\n In addition, you should consider that refactoring is an excellent way to train new teammates. This may not be as essential as in the 3 examples above, but it can help new developers understand the architecture of the code while simultaneously improving it, killing two birds with one stone.<\/p>\n\n\n\n Another famous adage says that perfect is the enemy of good<\/em>, and this certainly applies to coding. Before deciding whether to fix code which can stumble along without being touched, you should ask yourself three questions.<\/p>\n\n\n\n The first is how much time<\/strong> will this take me?<\/em> In a business context, time is expensive. Will the hours invested in the \u2018fix\u2019 be commensurate to the rewards said fix will yield, either in terms of user experience or profitability? As importantly, do you have a deadline or a presentation coming up in the immediate future? In that case, you may want to think carefully before changing anything. Recall that introducing new features usually means introducing new bugs too \u2013 and you\u2019ll want the time to find and get rid of them before showing your final product to others!<\/p>\n\n\n\n The second is how substantial<\/strong> is the fix?<\/em> Will it make a tangible change to the final product, or is it mostly superficial? Are you improving performance by 50%, or by 2%? If changing the code means building a useful new feature, then you\u2019re clearly adding value to the project. If you\u2019re simply making it more elegant, then that\u2019s nice, but is it really indispensable?<\/p>\n\n\n\n Finally, before making any changes you should always ask yourself, do I have a robust testing architecture<\/strong> for my code?<\/em> This should be a given, but sometimes you may find yourself dealing with inherited code that comes without that sort of architecture. In that case, the order should be to build your tests first and then<\/em> implement your fixes, lest you find yourself with all sorts of unexpected, intractable bugs. If you don\u2019t have the time to do both things, then you don\u2019t have time to \u2018fix the code\u2019 in the first place.<\/p>\n\n\n\n If you have considered all of these criteria and determined that changing the code is time-efficient and worthwhile, then go for it! You should always look for ways to make your code as easy to read and to maintain as possible.<\/p>\n\n\n\n On the other hand, if it looks like you\u2019re setting yourself up for a time-consuming process which is as likely to create new problems as it is to solve the old ones, then that\u2019s when you should listen to popular wisdom, and simply don\u2019t fix what isn\u2019t broken.<\/p>\n","protected":false},"excerpt":{"rendered":" The saying was originally meant for refrigerators and TVs. Does it hold true for computer software as well?<\/p>\n","protected":false},"author":17,"featured_media":46352,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[42],"tags":[],"class_list":["post-11919","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-coding"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts\/11919","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/comments?post=11919"}],"version-history":[{"count":1,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts\/11919\/revisions"}],"predecessor-version":[{"id":62610,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/posts\/11919\/revisions\/62610"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/media\/46352"}],"wp:attachment":[{"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/media?parent=11919"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/categories?post=11919"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.wbscodingschool.com\/de\/wp-json\/wp\/v2\/tags?post=11919"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Reasons to change working code<\/h2>\n\n\n\n
How to assess when code should be changed<\/h2>\n\n\n\n