First of all, if you have large codebase which hasn't been measured for technical debt I would recommend first setting up SonarQube to have a good baseline for later measurements. It doesn't make sense to setup quality gates that would fail a build, since this can be done only when the codebase is cleaned up.
So, setup SonarQube, create first analysis and then try to make it a habit within development team to check for technical debt periodically (e.g. after every sprint, or even more frequently). SonarQube is quite good in defining the most critical flaws, so it's always good to start with that. Sometimes it gives a false-positives, but these can be easily resolved (within SQ or in code, for example as annotation in Java).
Hi Pavol. Thanks for post. You have mentioned static analysis tool. Can you advice a good setup to measure progress of technical debt resolution?
Thanks!
First of all, if you have large codebase which hasn't been measured for technical debt I would recommend first setting up SonarQube to have a good baseline for later measurements. It doesn't make sense to setup quality gates that would fail a build, since this can be done only when the codebase is cleaned up.
So, setup SonarQube, create first analysis and then try to make it a habit within development team to check for technical debt periodically (e.g. after every sprint, or even more frequently). SonarQube is quite good in defining the most critical flaws, so it's always good to start with that. Sometimes it gives a false-positives, but these can be easily resolved (within SQ or in code, for example as annotation in Java).
Thanks for suggestion :)