Pulling the issues you're seeing into a structured form related to their practical business impact, will help you a lot:
Think through the issues and evidence that you can find, and group them this way:
- Observations that suggest, if its put to market, it will fail in use and backlash. It can't be compiled. There are logical errors in the code. Input isn't validated. Data isn't processed in a pathway that ensures a high likelihood of non-corruption. Security aspects aren't in place and data could be exfiltrated/hacked. Key functions can't be guaranteed to work for good reason, or you can show the few you've checked out of all of them, often do not actually work as intended. That sort of thing.
- Observations suggesting there may well be issues that won't reveal themselves in testing but carry a substantial risk of problems if put to market. Like above, but #1 is stuff you've found, this is evidence that suggests significant non-found issues are to be expected /anticipated/considered a significant risk. For example, if you've fixed edge cases related to misprocessing in some cases of data validation, that suggests other cases may exist and not be known which could lead to loss/corruption of data. If they used known deprecated/dubious approaches to one issue, that suggests they did the same on other issues. If the database is subject to race conditions/non atomic updates in one area, it suggests this could be an issue in the code generally. And if it's multiuser but the server side processing doesn't allow for multiple users' input/processes to collide in subtle ways, that suggests it could fall over under proper loads.
- Observations suggesting that the original crew deceived management (deliberately or not, or perhaps just by not being forceful and too easily overridden/ignored: it could have been managements fault not theirs!). Right now the previous crew are god's gift to management because they've delivered a shiny product. You are dubious to them because even though its a great product, you aren't happy, can't make it work, don't understand it, etc. But if you have observations that directly contradict things they have stated, then you become the one who knows what's up and the shoe turns against them. Your job then gets easier. For example, if they told management that the project has proper webUI security, and you observe places where they didn't validate input /cross scripting/SQL injection, or management believe the project can handle some significant thing and you can show specifically it can't and never could have done, you can show management they were deceived.
- Observations that show that, if put into the market, usual follow-through/expectation/service levels will be impractical/unfeasible, or costs will be much more than expected. For example if the code is too poor or lacks debugging aspects, then when a client has an issue, there will be no practical way to bug trace and whatever the issue is, it might take weeks not hours to remedy. If code is repeated then this means changing validation or enhancing data structures can't be done "just in one place". If it's undocumented or poorly structured, then attempts to enhance or improve it will be hampered badly because there will be no practical way to make significant development and be sure things won't break, or else checking for breakage will take so much time as to be uneconomical. If its a bad mess, then once in the market they will depend on you personally each time an issue arises; as you can't guarantee to be there at weekends and 11pm just because of some client deadline hit by a bug, or you might fall under a bus, what will they do? If data can be pushed around but needs excessive manual attention, then in production your support may not be able to scale to provide that, or to guarantee it can be kept simple enough, so processing errors may be higher risk. If it depends on specific platforms and those platforms aren't clearly managed in the code, then changes to platforms (windows updates, browser releases, library versions) might not be feasible in usual or commercial timescales, or fixing whatever they break may be complex, leaving clients unable to maintain or use their platforms as expected.
- Observations that just annoy you. That's your job. If they don't fall into the above categories, fix them as best you can in spare time. Management's problem is the first 4 items above, not this.
These will help you to align your technical and "hands on" perspective with their business perspective. If you can show that there are issues in the first 4 categories above, and set them out plainly, you'll be well on the way to moving your own problem - by showing them good reasons why it's their problem, and not your lack of competence.
If you put a list like this together and it looks compelling, make a presentation, present it to them, and walk them through example issues - including specific code or data flow snippets that exemplify the point.
To make it effective,
- Find some other coder they trust - or ask permission to bring in a colleague for a day - and have someone who is prepared to support you. That way its not all your say-so; you have someone else who can say, "Yes, he showed me this code, and I'm sorry, he isn't exaggerating the seriousness."
- Expect to have to educate a bit - briefly. They aren't coders but have commonsense. "This is why we use structured code, exactly so we can do each task once only, isolate the parts, and be sure how the pieces interact. But these guys did not, look here, here, and here. So the problem arises that in their code, you can not see how the pieces interact, or if there are logical errors or inconsistencies, and you can not be sure independent parts really are independent, or what all needs to be changed elsewhere if something needs changing, or even that it will behave under real world loads, as it does during testing. Assuming we can realistically test this as well as fixing it in less than 3 years of full time work by a team of ten, which is dubious. That's exactly why professionals code in a careful way - because we know the business impact is severe otherwise."
- Expect to be pressured or coerced to say its not that bad.
Speak plainly. "I'm sorry, whatever they had told you, clearly what you believe to be the case is not. I appreciate that is a shock, but as a professional, that is also how it is." Tell them, "No, it isn't high quality work, it is criminally sloppy work and you've been lied to, all the way." (Yes you can say that for emphasis, its not like you're saying they are criminals!!) Say "Yes, sorry, but I am sure".
- Go in with specifics. If you just say "Ssh keys are in plain text", that's great for someone on your level and seeing it as you do. For management under pressure and believing its great and why the fuss, it's way too non-specific. Instead: "Encryption keys used to prevent the client config panel for remote users are stored insecurely, in a way that anyone with slight knowledge would say is bordering on criminally sloppy. (Again, yes you can say that for emphasis, its not like you're saying they are criminals!!). If you look here (OK they can't follow code but pull up the code and point to that bit anyhow, for credibility) you'll see the key is stored in open format. They haven't even done basic 1990s encryption. Put this online and client/user data will be hacked as soon as anyone thinks its worth the 10 minutes it'll take." Show them "Over here, here and here you can see a routine system call [API] that may or may not break in various cases, because it is given incorrect data for the call." Tell them "These are basic fundamental errors. It's like that everywhere." Show them "In this module they use this library, but over here they use that library. But the manufacturer makes clear that the two libraries aren't actually compatible. They should never, ever both be used in the same code, because it can leave data incorrect/can corrupt data/because the output of one will be processed wrongly/corrupted/mishandled if given to the other." Like that, in terms so they can make sense of it and see the importance of it. Tell them "Can I fix it? Well, put it another way, if this bit's so dire, how realistic do you think redoing the entire security infrastructure for the project in under 6 months is?" That sort of approach. Make them see it.
- Go with a pre-thought solution. What would you do in their shoes? In fact, go with 3 solutions, and pros/cons/rough estimates of impact of these. Never forget that "do nothing" or "go ahead anyway" is an option, include that (and its pros/cons/risks) in your list too.
- Give them time to be shocked, upset, in denial, and in blame mode. It's human and they too have pressures. Expect this to happen, and either sit through it, accept their shock, guide them past it, remind them gently that blame searching and autopsies can wait; they don't actually solve the company's issues. Be their advisor.
- If needed, after a while simply say, "I have some proposed solutions. None are ideal - ideal would be that this mess didn't exist. But they are viable. Its been a heavy session. Let's grab 10 minutes/Can we meet again after a short coffee break/after lunch/I have a meeting, let's meet after that, to focus on solutions, and what we do to fix this." Putting this into a separate meeting after a mental "change of scene" - even just the far side of a coffee break - will help a lot.
- Saying that you have solutions can often wait a bit, until the first explosions have happened, because the human reaction will often be to ignore it or deny the need, in the early stages. Only once they disperse some of their upset (if they are that type) is it worth saying this, because in so many people, they just won't hear it if it's said when they are still in heated angry embarrassed blame mode. If that's not an issue then go straight onto solutions after explaining the seriousness/risk of impact, if you think they are listening.
Carefully avoid anything that could imply you're being perfectionist or doing any more than minimum for market viability. Anything more than the essentials, at this point, just isn't a priority.
Prethought solutions and pitch
As for a prethought solution, mine would be, extra resources. If they don't believe you, it's all dead anyway (assuming you're right). The software will tank, and you'll be burned by association: look for new work starting now. But if after your presentation, they do believe you, they are worried, or they are looking to you to fix it, this turns to your benefit.
Because what you need is a team. Pitch it something like this:
"Sorry guys, but 1.5 G of code like this, without basics or documentation, will take a year or so just to understand, maybe 5 years to fix. Maybe a rewrite will be needed and we can save what can be reused, maybe only parts of the GUI, the basic data flow concepts, to not reinvent the wheel, and then redo the back end and everything else."
"The first priority as I see it is assessment. I can see it's bad, but how bad, and what's the minimum to make it safe to go production?" [reflects back their top-level concern]
"As I see it, we need to know that within 4 to 6 weeks - I'd say 3 weeks but its a major task in its own right and needs line by line review. 4 to 6 weeks with a team of 3, and we'll know how bad the damage is." [If you can't, or its too huge, substitute whatever is sensible instead]
"Then, we need to fix it. I can burn the candles figuring what to do, but I need hands on keyboards. Anything from 4 to 6 of them , for up to 6 months."
[If relevant, add: "And I need a competent #2 for it. I can't review everything they put in, single handed, if I'm also navigating the issues and fixes as well." ]
"Its a pain that it's that severe, but it is what it is, and we need to dig out of the hole first, and do blame and litigation later. For that, give me 2 people for now, and budget for another 2 or 4 in about 4 -6 weeks, and I'll get you it, done right. Or at least minimally workable." [Again, if you can't, or its too huge, substitute whatever is sensible instead]
"You might also want to ask [name of a contact they know, who's a director in some suitable IT business] to send someone along for a day, to double check my initial view, approach, and timing, before committing a budget. That'll be good and also reassuring. But if it checks out - and it will - then we need to move fast, and the only thing that'll save our time to market is throwing resources at it fast and heavily."
"That would be, in my view, the sensible solution. We cant use it as it is, and we lose more by delay and damage, than we save by paying for contractors or pulling staff off other work."
"I'm sorry to bring bad news. The good news is, we can dig out of the hole."