Fenwick Software has had long-term clients; people and companies who have been with us for many many years. Managing tasks for these clients means that at times, I work with a piece of functionality that was created years ago; sometimes by myself and sometimes by other people.
You may have heard about The Writer’s Curse—the writer is never truly happy with their creation because they can always think of a way to make it better. In the Dynamics NAV world we suffer from a similar curse called, The Developer’s Curse—we can always find a better way to do the code than the way it was done years ago. This is hard enough when looking at one’s own old code but it gets even worse when we look at the code produced by someone else.
A piece of code is good quality is if it delivers the functionality that the client expected and if it is flexible to cater for changing processes and market conditions.
Here are the things I have learned: a piece of code is good quality is if it delivers the functionality that the client expected and if it is flexible to cater for changing processes and market conditions.
We manage the first point by asking the relevant questions and documenting the requirements in our internal systems.
We manage the second point by adding configuration parameters that control the functionality.
We also record and track all code changes by using development tools like Object Manager. This allows us to segregate each piece of functionality from others and ensures that we can go back in time.
Following these processes means that I am able to manage my Developer’s Curse and I know that the code will work for the client—not only now but also in the long term. With The Writer’s Curse, there is no turning back once a piece of work is published. Thankfully, the code always remains in the background, so if mistakes occur they can be managed as part of internal quality management processes and clients don’t even know about it and don’t have to pay for it.