I have had the same conversation with countless customers and developers over the years: “You should really look at your code and refactor it or some of it during the upgrade.” Rarely, you get a “great, it sounds like a good idea. I am willing to pay for it.”. Usually, you get resistance to the additional time and cost that is involved with that. And often, even developers don’t see the need for it. “I’ve been doing it the same way for the last 10 years; you can’t tell me that it was all bad – it works.”
Yes, it did work and it does work. But just like technology changes and you adapt to it, development patterns and best practices change as well and you should adapt to those as well. I wanted to take the time to go through the reasons why refactoring is important, how to include it in an upgrade project, and how to approach it. Since all of this will be too long for one port, I will focus on the why and how to sell it to a customer. Next time, I will go through some examples on how to refactor code.
What is code refactoring?
The traditional way of developing functionality for Dynamics NAV – or customizing existing functionality – was to just add your code in standard objects, to create a couple functions and add all possible functionality into the functions. You would wind up with working code and good looking functionality. So, what is wrong with this? It is not easy to debug, not easy to fix any “undocumented features” (aka bugs), and it also makes upgrading expensive.
When you are refactoring this code, you basically go through the existing modifications and change the way the functionality was implemented. You move as much code out of standard objects as you can and split up larger blocks of code in meaningful and reusable functions. Obviously, this is just a high-level definition; we will look at the “How” during the next blog.
Why refactoring code?
Microsoft has created tools that assist in upgrades. But those tools fail or do not do a great job in those scenarios. So, the upgrades are still often done “by hand” – copying and pasting code from one version to another. This takes a lot of time and costs therefore also money. Once it is refactored, you can use those tools for most changes, which will save a lot of time and therefore make upgrades a lot more affordable.
Upgrades are one big advantage. Obviously, easier upgrades make for less errors during the upgrade and a better upgrade experience for the customer. But think of the other advantages. If you create reusable functions, you can reuse the same code in multiple places and, if there is an issue in one of the code pieces, you don’t have to fix it all over.
So, what this means is: refactoring code allows for easier upgrades, easier bug fixes, better debugging, but also – easier unit testing. It is much easier to test one function at a time to validate that they work as expected rather than testing a large block of “spaghetti code” inside of some standard block. Imagine you are adding some code to the posting routine to update some custom table. If the code is somewhere in the middle of the posting routine, you always have to post a document to test this little piece of code and have to debug through a lot of code. Now, if this would be in a separate function, you could just test this function by filling in proper parameters and validating the result. Isn’t that easier?
It is also easier to replace parts of your functionality with standard functionality in a new version when additional standard functionality becomes available. And this is the goal of any upgrade: make your customizations work with the new version, but also reduce the amount of customizations by using more standard functionality.
How to sell it to a customer?
Customers are cost conscious and don’t want to pay for anything they don’t perceive value in. How is there value in spending a lot of money on something that doesn’t give me new functionality, doesn’t fix a pain that I have? Successfully convincing a customer to spend money on code refactoring basically has to answer those two questions.
Last year at Summit, the Dynamics User Group conference, I have talked about making upgrades more affordable. And the common response from the end user audience was that they would upgrade more often, if the price was less. Think about that – the ability to upgrade a customer to every new version, instead of only every 5 years. This means that you ultimately get more revenue, since there are always additional services included with the upgrade: New functionality will be implemented, maybe the customer changed their business and requires additional modifications.
If you find a way to make the refactoring affordable, you win. And the best way to do this is to focus on the biggest modifications first, or focus on the largest number of standard objects with only smaller changes first. Ideally, you take a few modifications at a time and refactor those. Then implement the changes (obviously following normal procedures with testing them) and move on to the next. So, over the course of a year or a few upgrades, you can make quite an impact this way and refactor a lot of code – and make every new upgrade less expensive.
Overall, your customer wins, because they will be able to upgrade more often and stay current to take advantage of the latest changes in NAV. You win, because you increased your services through the refactoring effort, more upgrades, additional training and implementation services. But you also decreased the number of issues you will have with upgrades. And since you can’t always charge for issues that you resolve, you also won here.
In the next post, I will take a look at the different ways to refactor code and how to go about it also discussing some pros and cons of the different approaches.