re: How often do you have to go back and just focus on technical debt? VIEW POST


For me and where I work it is kind of a case by case basis. Sometimes if it is a small scope change we will simply make the change and do a full regression. For bigger changes it usually requires more planning and meetings to determine if we can make the change within our schedule.

As far as what technical debt is, well it is simply code that is hard to maintain and add new features to. One perfect example for my company is a web page where the user can enter a lot of different data and select many options resulting in something like 50 million combinations of options. The way this code is written means that if more than 1 person works on it there is pretty much guaranteed to be horrible merge conflicts, incompatibilities, and hidden edge case bugs that can only get found in production. This wastes a lot of time and makes maintenance difficult.

code of conduct - report abuse