40

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?

Improve this question
5
  • 17
    It's ironic that in a question about not playing the blame game, you spend 3 full paragraphs comprising about 50% of your question ranting about the previous team. And tagged the question [bad-code] and [bad-programmer].
    – Aaronaught
    Commented Jul 27, 2011 at 15:51
  • 8
    @Aaronaught, Okay I'll bite, I labeled it bad-code because the code is indeed causing bugs and issues. I labeled it bad-programmer because I am afraid I am becoming one by blaming the previous team, a tired and cliched excuse that we have all heard before. As far as the first three paragraphs are considered perhaps I didn't need to be that descriptive but I wanted to paint an accurate picture of my immediate situation and give the history of what I gathered so far.
    – maple_shaft ♦
    Commented Jul 27, 2011 at 16:03
  • 3
    ... So is there an element of rant in there? Yeah, I guess so but I'm sick of being the nanny to an application that performs like an ADHD child with a death wish.
    – maple_shaft ♦
    Commented Jul 27, 2011 at 16:04
  • 2
    I sympathize with you. I do. But we have a chat system if you want to rant or blow off steam. Constructive questions should have a neutral tone and omit such unnecessary details.
    – Aaronaught
    Commented Jul 27, 2011 at 16:22
  • Hero opportunity! But management is key. 1. Boss: "give it a try, nobody's been able to fix that for years". I re-wrote the key programs - HERO!. 2. New division w/ new boss who was truely incompetent both as a manager and software guy (and a conspiracy theorist). His boss had a psychopathic streak (yes, really) with "smile to your face and stab you in the back" vindictiveness. I solved existing problems and much more. Net result? I'm fired for spelling errors in development code; organizing a show and tell; strip waxing the roaches off the floor. Nitchie said "hell is other people."
    – radarbob
    Commented Dec 23, 2015 at 17:03

3 Answers 3

Reset to default
47

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".

Improve this answer
7
  • 4
    +1 for a really good non-blaming explanation of how a project could choose (correctly!) to get into technical debt.
    – Joris Timmermans
    Commented Jul 27, 2011 at 14:36
  • Wow, how insightful! I make it seem par for the course and chalk it up to growing pains.
    – maple_shaft ♦
    Commented Jul 27, 2011 at 14:45
  • 1
    @Nemi: One important difference between technical debt and financial debt is that it is much easier to quantify the latter. It's much easier to know how much financial debt you have left to pay off (even factoring in interest accumulation and recurring financial obligations) then it is to do so with technical debt. I only point this out because that's one thing that exacerbates maple_shaft's problem.
    – Ben Hocking
    Commented Jul 27, 2011 at 18:48
  • 2
    @Ben - you are absolutely correct. As with all analogies, this one breaks down under a microscope. However, the comparison is still solid on a high level. It essentially dispenses with the details and talks to management on their level - as a business problem, not a technical problem. Essentially any long-running project accumulates a certain amount of technical debt and as such it means there is an added expense to development as time goes on. Since this is hidden (and not even well understood), it is in everyone's best interest to make sure it is talked about.
    – Nemi
    Commented Jul 27, 2011 at 21:34
  • 1
    @radarbob I disagree - just like financial debt, it doesn't matter whether accumulating it was done intentionally, due to bad luck or stupidity - someone has to pay for it in the future. The term is inherently neutral in regard to the cause.
    – Hulk
    Commented Dec 23, 2015 at 14:34
24

IMO you are already mostly going about this in the right way: you are not suggesting a ground-up-rewrite because "the old code sucks", but fixing one thing at a time.

To avoid feeling like you are blaming the old team, just imagine that they probably had to produce this code under great time pressure. Management at that time probably didn't really understand that just because the code "more or less works" doesn't mean that any maintenance is possible without a lot of pain and rework.

Appreciate the old team for managing to make a product that actually delivers some business value - it would not be in use anymore if it didn't. You might be surprised at how often a project fails to deliver business value, even if it is beautifully written.

Improve this answer
8
  • 3
    +1: blame the old management who failed in delivering a quality product, then (hopefully) the new management will get the message (or get rid of you, both cases are a win as far as you are concerned)
    – gbjbaanb
    Commented Jul 27, 2011 at 14:00
  • 15
    @gbjbaanb - don't blame anyone! Go out of your way NOT to blame anyone. Just establish the current situation and the desired situation, and make a logical argument of how and why you need to get there.
    – Joris Timmermans
    Commented Jul 27, 2011 at 14:03
  • Eh, make sure there IS new management. The same boss might still be there. And even if he moved on, he's somewhere out there. Make sure you find out before you go around throwing people under the bus.
    – Philip
    Commented Jul 27, 2011 at 14:12
  • I wish it was as simple as not blaming anyone. Management insists on someone/something to point the finger at. If I dont point to a person or group of people who do I point to?
    – maple_shaft ♦
    Commented Jul 27, 2011 at 14:15
  • 4
    @maple_shaft - so make the argument I made in my answer to management, and if they still insist on "blaming", post your resumé up on as many sites as you can find, because things are going to go very badly for you when they decide to start blaming you for lack of anyone else to point the finger at.
    – Joris Timmermans
    Commented Jul 27, 2011 at 14:16
7

When asked to comment on the current state of a problem product, I always fall back on, "it is what it is," and then start talking about plans for improving it.

You don't know all the factors that went into the decision that created this problem - perhaps they were even reasonable at the time. All you can do is move forward and make things better tomorrow. And it sounds like you're doing a good job - you have the right attitude for this situation.

Focus on just reporting facts when asked. You don't have to add narrative or commentary; just say "the system fails in case X" or "the reports are incorrect for case Y." Then quickly add how you plan to improve the current situation.

Improve this answer
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.