The life of every SAP system begins the same way. A clean, fresh start with no data, no customizing, and no custom development. One could argue it is all downhill from there. The moment you begin to implement your processes the technical debt starts to build up. There are dozens of reasons why this happens. Be it a quick fix that becomes a permanent fixture, a small hack to meet a deadline or simply a gap in the knowledge necessary to implement the best solution.
Whatever the reason, now we are in debt and if we don’t pay it back it starts to build up and accumulate interest. Now you must choose your course of action. When you ignore the debt, there will be a slow increase of development cost and time, that will become significant in the long run. Also, you will experience new and exciting ways in which your software breaks, as all the little and not so little issues start to build up.
The other approach is what I like to call the Lannister method. As we all know, a Lannister always pays their tech debts. Of course, there are many ways one can start managing and repaying their debt and it would take much more than a LinkedIn article to give you even a comprehensive overview. So, I would like to start your journey towards a leaner and cleaner SAP System with a few measures that in my opinion are quick wins with a great cost/benefit ratio.
Code Reviews
One of the best tools that is available for tackling tech debts are code reviews. Having developers read, understand, and critique each other’s code brings with it a lot of benefits including:
- Developers tend to be more conscientious about producing clean and efficient code when they know that somebody will check it.
- A second pair of eyes will help to catch bugs that might go unnoticed otherwise.
- It can be a great learning experience for both the developer and the reviewer since both can see and discuss approaches to problems, they may not have thought of on their own.
- You have a second person in your organization that understands the basics of the implementation. So, when the initial developer is not available you have a backup that has an easier time to get into the code.
- It just produces cleaner, easier to understand code.
Just a quick warning: To use this you must have a robust feedback culture in place already. It is necessary for all involved, to be able to give and receive constructive and professional feedback. Otherwise, you can expect a lot of tensions and hurt feelings.
Quick Fix? Quick Fix!
I understand, sometimes you just need to get stuff done. Be it a tight deadline, you wouldn’t be able to meet otherwise or a hotfix that needs to go to production yesterday, sometimes speed trumps quality. Thankfully we are building software and not houses, so it is relatively easy for us to fix the code afterwards. Let’s do this as soon as possible. When you implement a quick fix, also immediately create and schedule a ticket for it’s clean up. That workaround for the legacy system that will be shut down in three months? Plan the removal of it right now, with a concrete timeline and the necessary resources. As our moms always said: If you make a mess, you must clean up after yourself.
Always refactor
In over a decade working in IT I have yet to meet a developer, that is completely happy with the code they wrote a couple of years ago. We all have something we want to go back to and improve. So, let’s do it. Whenever changes in an existing implementation are necessary, always set aside some time and budget for refactoring. Give the developers the chance to apply their new knowledge, be it from a technology or process perspective, to the existing code. The code base will be improved, and the developer will be happy to finally fix the thing that was bugging them all along.
Just get rid of it
You know how you can ensure that you have less bad code? Just make sure you have less code in general. So, whenever you have the chance to delete something you should. Since it is not used, it has no business bloating your code base. If you are not sure that you might need something again later, you probably won’t.
So, let’s get started today with tidying up our SAP systems. I hope that my suggestions motivate you to implement some changes to your development process to keep your system as pristine as possible. And let me know of any ideas and experiences you have with repaying tech debt, because I am always looking forward to learning something new. Together we can ensure that our solutions keep sparking joy.
LINK: (2) Does it spark joy? – The magic of tidying up your SAP system. | LinkedIn