I had to fix a loose railing on the deck, so I took out my trusty cordless drill/driver and a couple of screws, and presto, tested and fixed. The following week I had to fix a loose section of fence in my yard, so I took out the same gadget, along with longer screws that required a different driver bit. Now I could have went out and bought another drill/driver because I needed to use a different bit, but why do that when I had one that already works, all I needed to do was change the bit, right?
The same applies to accomplishing a programming task. During the process of developing a module, you realize that you need to perform a specific operation. You search through the source and find a method does almost exactly what you need, except for one statement, which needs to behave differently. So, you wade through your limited supply of options, which are:
1. Make a copy of the method and change the one line of code that needs to be changed;
2. Factor out the method to a common library, changing the method to accept a parameter to control the behavior of the one statement
Anyone who has taken a course on software development was taught the second choice is the appropriate one. Improving the maintainability and reliability of the code is the correct move to make. However, to this day I see developers taking the “easy” way out by copying and pasting that same piece of code into their module.
I’m guilty of similar actions, having just changed only the bit in my trusty drill/driver. But in some instances cutting corners works, fixing code is not one of those instances. The goal is to produce applications free and clear of bugs that bring productivity to a standstill and affect revenue.
But, code defects are inevitable. And it can be challenging to resolve these when the application behaves unexpectedly once released into production. When building applications, developers need to be able to reproduce production problems as fast as possible – especially in today’s DevOps environments. To do that, diagnostic solutions should be used in the User Acceptance Testing (UAT) phase. When the same diagnostic tools are used both in UAT and production this becomes easier as the communication between operations and development can be more precise. Using diagnostic tools, like AutoPilot, allows developers to rapidly reproduce issues in order to improve release quality.
Granted, no application will ever be 100 percent healthy all of the time, but when those issues creep up, the time to reproduce and resolve can be fast and accurate without resolving to shortcuts that will cause pain later such as copying and pasting that line of code.