A surprising number of quality, scalability, and load problems have been occurring on an application I currently support that I did not originally write. Thankfully I have new projects that I have been doing from the ground up to retain some semblance of my sanity.
The original team consisted of 20 some developers (most of them with outdated skill sets), no business requirement documents or quality assurance testers, and poorly managed from the very beginning in a waterfall fashion. The early days of production were an embarrassing nightmare that involved patching brittle procedural-like code with even more brittle fixes. Features were added later that were sledgehammered into a datamodel that was never meant to support them and it is not uncommon to see the same code duplicated 10 times over and to see resources not being safely closed and ORM queries that fetch tens of thousands of entities just to throw out all but a handful.
It is just me now and everytime there is a new problem that crops out I rewrite a module to better standards and make it MUCH more stable but Management needs a proper explanation as to why all of this is occurring.
They seem shocked and perplexed at the notion that this application is of poor quality and drowning in technical debt. Fortunately they understand the concept of technical debt and support me in my quest to eradicate it and they are very supportive and appreciative of me, but I feel as if I just keep blaming the original team (who all left to ruin another project in a different division).
The bottom line is that I don't want to be "That Guy" who always complains about the developers on the project before him. I have seen this attitude before from people in my career who I personally felt were being ignorant and not considering the circumstances and design influences that encouraged things to be the way that they were.
Usually I see this attitude of blaming the previous team for poor design and implementation from idealistic junior developers who have not had the life experiences that more senior members have had and benefitted from.
Do you feel that there is a better way, perhaps softer way of doing of reporting these kinds of problems to management without stepping on the reputation of the person/team before you?
Best Answer
Technical debt is like financial debt. You take it on (hopefully) strategically in the development of a program with the intention that it will be paid off in the future. Sometimes people make poor technical debt decisions (such as running up a credit card), but sometimes a certain amount of technical debt is just normal. Deciding not to devote the time to make something the "right" way today with the assumption that it will need to be changed in the future is completely normal and should be anticipated. Of course there is a fine line, but thinking that you will make it the right way the first time can cause its own set of problems (analysis paralysis).
Bottom line, any non-trivial project that lasts more than a couple of years will need to devote some new development time paying down technical debt. The thing is, this is true even if you write your application the right way. If you don't you are piling debt on debt, and management can certainly understand that if you present it that way.
Explain this to management and instead of "blaming" the previous team all the time you can present this as "business as usual".