New employer's code is a timebomb of epic proportions. How to deal with this accordingly? [duplicate]

Question

Using a temp anonymous account because I post regularly on stackoverflow/here under my real name.

So I got a new employer the other week as a software engineer. Friendly team, good employer. No issues there. The issues come from the code itself; it was made by 2 'self made guys' in the past plus another guy who left the company a few months before I joined. The only thing you need to know about the business logic is that it is a very sensitive personal data that of course under no circumstances can be allowed to leak.

I've studied the code and was appalled by what I saw. As in, the only reason the application hasn't been hacked yet is because nobody bothered to look for it. And to make it clear; there are definitely bad guys who would be very interested in abusing this system for their own practical benefit. This isn't a 'crappy app but nobody cares'. It's full of holes everywhere and absolutely bug ridden. Even worse; when something goes wrong the user isn't even informed of this, nor is the error logged. So if a user creates a business object and this fails, the user won't know this until they look for their newly created object and find out it isn't there.

try { save(newItem); } catch(exception ex) { // do nothing }

Even worse, every controller function - like API calls - aren't checked if the user has the correct permissions to get the data. Meaning if you're logged in and know what you're doing, you can do whatever you feel like, even though this environment desperately need a NoTrust-like implementation.

The deployment servers aren't much better. The test and production server are one and the same. On the server over 3 dozen console applications run in the background. "Yes we have some lag every now and then randomly where all apps would run slower", they said. And I almost know for a fact that the test/production applications aren't separated like they should be; I am 99% certain at least one of these production apps is interfacing with a test version of a console application.

Not to mention everything is written in outdated technology, Framework 4.5.x for example.

So, here comes the conundrum; if something goes horribly wrong - and it will sooner of later when the first wise guy figures out the weaknesses of this app - I will be of course on the chopping block. And everything needs to be rewritten in modern technology with a proper tech stack, the correct security implementations and proper error handling. I am inclined to say this isn't up for debate given the sensitivity of the data stored there and the seriousness of how the B2B clients use this application. How can I make this absolutely clear to my non-coder employer, given the fact I only started a week ago? (I do have 4+ years of experience under my belt though)

--

UPDATE I've taken Benjamin's solution and made an analysis of their systems, then presented it to management at my insistence. They were interested to see what I saw, so I told them in plain language the system was wide open for hackers. That they could come in from dozens of angles and what they would be interested in doing, and that I could not fix it without revamping the entire thing. I also explained in plain language to them why the entire system was so laggy and buggy and the fundamental problems that were behind it. Sales/Management actually understood what I was saying and have given me permission to redesign/rebuild the entire thing, no further questions asked, and just said I needed to tell them what I needed. Hurray!

Answer 1

In your message, you are mixing up 3 concerns:

• security
• usability
• maintenance

Managers need 2 things:

• What does this mean?
• How do we solve it?

Example: Once Users are logged in, their permissions aren't checked anymore, which means they can read/write stuff they are not supposed to. For example: (Insert the most horrible concrete example you can think of). E.g. users might see that PayPal account of others, including passwords, and steal money.

The concrete example is important. I once worked on a project which all developers objected to. We told the PMs that the partner company can see all the users data. They said it's fine, the users agree to this via contract. Once a PM found out that all the data included PayPal passwords, the project was shortly thereafter cancelled and never saw the light of day^^ (No, we didn't save PayPal passwords, that partner company did some shopping proxy thing.)

Example Solution: Users permissions must be checked against database every time they do something, and get a permission denied if their permissions aren't sufficient. Estimated effort: 4 weeks (or whatever)

2nd example: Outdated framework - Is it actively maintained with bugfixes? Is there are clear update path? Are there security issues with the old version? There's a difference if we're talking 2 years old version that still gets security fixes, or a 10 year old version that's completely unmaintained.

Same thing: Framework X is used in version 4.5. It doesn't get any security updates anymore. Since there are 4 known security bugs that wont get fixed anymore, we are currently at risk for any hacker who looks at us longer than a few hours. Since a lot of details changed between versions 4.5 and 10, we would need to change a lot of code. This means the whole effort is an estimated 4 months.

Do this for each and every thing you find. Make sure to highlight any uncertainties you have, so that people know 4 months estimate is an estimate, and not a magical solution to fix all problems that 100% wont take a single day longer than 4 months.

After you written all this down, make sure to have a meeting with your appropriate manager, and that this is understood. Take meeting notes.

This does several things: You cover yourself, because you have in writing that you raised this issues. Your managers now have actionable decisions to make. These things can be individually evaluated and prioritised. Other developers can chime in, and propose different solutions.

Answer 2

The world is full of systems similar (one way or another) with the system you describe. Most of the times, they have these 2 faces:

1. The face visible to the developers: it is an unmaintainable time bomb, it has to be rewritten.
2. The face visible to management and customers: it does what is needed, it already fixed all the bugs found in the past.

Additionally, there is never enough documentation describing all the requirements, all the bugs, all the fixed bugs etc.

It means that re-writing the application from scratch with all the benefits and none of the problems is largely impossible.

everything needs to be rewritten in modern technology

Adobe Flash was once a "modern technology" which is now dead beyond doubt, with mostly no chance for revival. A lot of technologies went (and will go) the same way. "Modern" does not necessarily mean better.

I will be of course on the chopping block

That sounds highly exaggerated, in the context:

new employer

So, if you are the new guy, why is your head in danger? If they are even remotely reasonable and intelligent, they already know what they have. If they are not, then you should run away as soon and as fast as possible.

---

New employer's code is a timebomb of epic proportions. How to deal with this accordingly?

There is only one way to do it: evolution, not revolution. Re-write the code one "bug" at a time. Each time make sure that the behavior did not change for the final customer. To guarantee that, get the final customer in the loop - after you have the agreement of your employer.

With enough time and with enough patience, peace will come. Either you will accept and embrace the facts, or you will change the facts for the better. The world can indeed be better.

---

Note: you say there:

I got a new employer

That makes me understand that you are not the right person to re-write that application. A properly-minded person would have written something like:

I just started a new job

or

I am new at this job

But you moved your "new-ness" on the shoulders of your employer.

---

Additionally you wrote:

everything needs to be rewritten

and

How can I make this absolutely clear to my non-coder employer...

The tone of your statements are quite on the offensive side. You already consider that your "4+ years of experience under my belt though" gives you the right to be the boss of your employer and make decisions for him. He might have made some bad decisions in the past, but on the other hand those bad decisions pay for your bread today. You should have a constructive attitude, instead of a dominant one. Just saying.

Answer 3

Security is never an issue. The risk, outcome of breach X probability, is the issue. Maybe someone can make the application crash and so what? Do you need 5 nines uptime? Can sensible data be accessed? Can an invader remote control?

The first thing to do is to casually talk about this to people in charge or on the project from a long time and dissociate the topics. Examples:

• Security: "Hey (Project) Manager. I found a few thing in the code or the infrastructure that may be exploited by hackers. Are you aware of this? What is the stance of the project/client/company on cybersecurity"
• Outdated stack: "Hey X. Do you know why we are still using framework 4.5 that is not supported anymore? Is there a migration plan?

On the security aspect: Maybe people are not aware of the risks. Or maybe they decided it was not worth to do. Is they are not aware you can offer to discuss with them about the risks (probability and outcomes) of leaving it at it is and work with them the potential financial loss. If they already decided the cost is too high, you will just have to accept it.

On the outdated technology aspect: Unfortunately it more often the case than not that companies work with outdated technologies, software or practices. Often the upfront cost to train people or change technology is seen as "too high" when the accumulated cost of maintaining such technology and the loss of productivity is much higher. My experience is that it's a lost cause. Bring it up once, then keep it to yourself of leave if you don't want to lose your skills on up to date stacks. If you are lucky you may be able to talk with someone that both agree with you and have the power to direct the changes.

In both cases it doesn't mean you can't code properly and securely. Just do it for any new code you introduce or old code you have to update but don't try to do more than what you are expected.

Answer 4

You can't do EVERYTHING...you might not be able to completely start over from scratch using a newer code framework, because the management might decide that's too expensive/time consuming.

You definitely can bring the issues up and explain WHY things need to be done.

Definitely, you could go function by function and log into your tracking system your 'issues' with the functions and business logic. E.g. permissions are not checked, so somebody could do something.

One thing you could do is set 'logging' function/service and log errors/exceptions and possibly set logging levels. So, production services might only log 'critical errors' (e.g. crash level errors) while developers could log 'debugging' messages (e.g. I am here calling this function with these values), which would be useful. Then you could track in your system, "I added a logging system" and while you might still be "Doing nothing with exceptions/errors", you would at least be able to say that it was Raised--so if a customer couldn't find their business object and called the help desk/productions support -- maybe the 'issue' could be found faster and resolved, especially if you could find what went wrong.

And adding logging could be a fast/cheap bandaid thing you could justify doing, just to say we want to see what's going on in the code.

Do log / track EVERYTHING wrong...just so you can later say "I told you that this would be an issue and don't blame me if it does, I warned you"... You may not be allowed to do everything you want to, but, at least it'd be documented.

You could try to slowly fix the most egregious issues using the current frameworks and regression testing them...make sure things work 'correctly' and work together.

Answer 5

You have several separate issues here.

First, you have the security issues, which seems like it may be the most pressing issue. Make sure you document, in writing, what those are and what the risks are.

Second, the fact that errors are just "swallowed." This is actually several problems: first, the usability issues for end users. Secondly, the lack of logging makes later debugging difficult or impossible. Third, is there any chance that this could result in inconsistent data?

Third, the lack of separation between QA and Production. It's not clear to me exactly what the problem is here; are you saying that this causes performance problems, that it's a potential security issue, or that you could accidentally introduce problems into Production while you're developing? Make sure that you're as specific as possible about which one it is.

When communicating it, I strongly recommend not communicating it as "the guys who wrote this are incompetent morons." Even if it's true, doing so won't win you any friends. If you can't communicate this to management in a way that they're able to be receptive to, knowing this won't do you any good. Overt hostility is rarely, if ever, helpful to any situation (even if not directed at the listener).

Be sure to explain this to management in a way that they can understand. Deal with each issue separately, and explain why it's an issue. Don't conflate all of the problems you're seeing.

Also, I strongly recommend against a complete rewrite. Complete rewrites are rarely a good idea. Also, you don't need to switch frameworks - just migrate to a newer version of the same framework. You appear to be using .NET; .NET 6 and .NET 7 are available now. I just migrated a .NET Core 3.1 app to .NET 7 and didn't have any problems doing so - it was a simple process that probably took half an hour or so. Be sure to document why you're doing the change (in my case, I just created a Jira task to do the migration, which stated that it needed to be migrated because .NET Core 3.1 went out of long-term support in December 2021).