He knows

1. New code takes time (and money)

Writing new code is an investment. Time and money will be spent on designing, implementation and code review. These introductory investments are however only a minor part of the total cost of writing new code. The code must be well documented and maintained. The code must be integrated to other parts of the systems. Last but not least, the code must be tested, and writing tests usually involves writing, well, more new code.

2. New code means new bugs

Even through our best efforts and testing, bugs will be found and will need fixing. Numbers on this seem to vary a lot, Code Complete by Steve McConnel estimates an industry average of 15-50 bugs per 1 000 lines of code.

3. We write what we know

Perhaps the most compelling reason to reconsider and resist the code-writing is not in the numbers and statistics, but in the simple realization that we usually write new code using our current knowledge.

Pausing for a while and spending time investigating on the current best practices and methods of solving the issue we are aiming to solve with our new code may not only save us and our business owners valuable resources, but also increase our knowledge base thanks to that investigation.

How I did it wrong

One of the first RStudio addins I have written for my own use was to run a script open in RStudio with R --vanilla via a keyboard shortcut and open a file with the script’s output in RStudio. If I had to guess, my thought process was likely similar to the following:

• I will to write a new function to serve as the addin binding
• I will to write a new function to serve as command executor for both Unix-like systems via system and Windows via shell
• I will to write a new function to create the command to be executed by the above
• Maybe some utilities, like the ones converting ~ to a full path, figure out integrating the 4 together, passing arguments, etc.

So, there I was, some time and 92 lines of code and doc later, with a new useful RStudio addin. Oh and yes, there was also 102 lines of test code, fixed a couple of times, too.

How could I do it better

After a second look a few months later when actually reviewing this supposedly good functionality, I realized that

• There is a base function called system2, which seems like a much more user-friendly and easy to use version of system (and shell), with no real need to write system-specific code and even though less configurable than system, still perfectly sufficient for my purpose
• I do not actually need to make the command, as extra options can be passed to system2 as arguments, including redirecting output
• Oh, and I definitely do not need a function to convert ~ to full path, there is path.expand

So after a quick rewrite, we end up with a very similar functionality, only we suddenly need 35 rows of code, doc included and the tests shrink to 10 lines, as there is only 1 function to test instead of 4. That is less than a quarter of the original amount of code to be maintained and bug-fixed, with 0 new dependencies added.

This was of course a very trivial example. Real life problems of real-life projects will be much more difficult to solve. However, as complexity scales, the potential amount of time and resources saved will also scale.

Good luck resisting that urge the next time it comes 😉

Did you find the article helpful or interesting? Help others find it by sharing