How to talk to management about 'genius' code?

Question

EDIT:

Thanks everyone for the great advice, comments, and feedback.

As it turns out, no one was the “bad guy” in this situation. The advice I received here helped me to get back in contact with the former lead on the project. As it turns out, my company, for no discernible reason, had received an early “in development” version of the codebase. The old company sent us a production ready version, and, as a cherry on top, publicly praised me for effectively reverse engineering an incomplete product to the depth which I had.

TL;DR

I inherited a project. Long story short, the code I am tasked to maintain is bad. So bad, in fact, the product is not only incomplete but non-functional and has been for years.

How do I communicate to management, in a way that isn’t embarrassing to them, in a way that doesn’t make me look lazy or stupid, that a valuable product is in a dire state?

---

Clarification: this question vs technical debt

This question has to do with me challenging long-standing beliefs about a product without committing career suicide.

Rather than strictly be about dealing with technical debt, there is this: management suggests that perhaps the code is so complex that I can’t understand it, and posited the mistakes are by design; that the original developer is so meta, that what looks like mistakes are actually strokes of genius.

Perhaps another reason this isn't quite about technical debt is that the difference between 'genius' code and technical debt is that management communicates that I'm not supposed to alter 'genius' code, and that 'genius' code isn't technical debt: it's the secret black magic. I wish management would think of it as technical debt. Instead they don't.

Management isn't concerned with the time, cost, or money directly –– although that is some concern.

---

Details

Most of the time, I wouldn’t be nervous communicating this to management. Unfortunately a long line of piece-meal maintenance by people, some of whom had little development experience, who only “touched” the code long enough to add a patch here or there, then move on, has painted a picture to management over the years that the project is just one step away being production ready.

That is woefully not the case. A short list of issues in the genius code I have come across in the ~1.5Gb code base are...

• There are same function, same variable names of the same scope throughout the code base (in a language which doesn’t support that).
• Functions are defined but never called.
• Out of order variable usage and initialization.
• Incompatible versions of libraries used.
• Hardcoded URIs and IP addresses with no documentation as to what they do.
• Randomly requested API routes which return nothing or gibberish; which are then not used.
• Hard-coded, unencrypted passwords and private ssh keys.

I should add that when I first started working on it, it didn't even compile. And when I got it to compile, it failed at runtime.

It’s a nightmare.

The problem is, the management has received assurance from whom they inherited it, and from previous “gung-ho” developers, that it “works,” so have invested significantly into it... And now the buck is passed to me. And they want it in production in about 2 months.

When I suggest that previous developers may not have been entirely honest or understood the product entirely, management sends mixed signals about “just get it done,” and “why isn’t it done yet” ... and “we’re not really sure it ever worked” to “it was working when you received it,” and “we’ve never seen it work” to “it’s already in production.”

[EDIT: pasted most of the next paragraph into the TL;DR section.]

Management also suggested that perhaps it’s so complex that I can’t understand it, and posited the mistakes are by design; that the original developer is so meta, that what looks like mistakes are actually strokes of genius. Granted, I’m no genius, and maybe that is the case: to which I offer my previous observations about the very fundamental issues I found.

Perhaps there’s politics at play above my level.

Answer 1

It's not "Genius" coding if it's not maintainable by anyone apart from the original coders (if they remember what they did and why).

The implication here is that these geniuses have gone into the code-base, added their changes, unit-tested them without much regard as to whether their slice of genius has interfered with another guy's slice of genius and completely broken it. And I'm guessing (from the gung-ho attitude), that there's no documentation of the changes or updated functional documentation so no one now knows what changes were made, by whom, for what purpose, or who signed them off.

And this is the line you spin to management

It might be genius, but it's unmaintainable.

All you can do for now is somehow make it work before the deadline and then analyze the heck out of it and make it maintainable in stages.

If it really can't be made to work before production, then it's up to you to issue a "No Go" and state the reasons. Hopefully management will understand and delay the roll-out.

Disregard politics in this - that's your manager's job. Just tell him the facts and let him deal with the fallout.

Answer 2

As a general rule, management "want solutions, not problems". As such, saying "there are hardcoded secrets in the code" is a problem, whereas "Resolve hardcoded secrets regulatory failure: 0.5 days" is a solution.

I'd take a few hours to properly assess the code, and document all the things you want to change/fix in it to make it "minimum viable product". If there's any objective static analysis tools that can help you here, then all the better - 100 security issues in Code Climate or whatever are harder to argue with than your professional opinion. However, your opinion counts here, and you're trying to give an honest assessment.

"Minimum viable product" (MVP) is a slightly subjective term. It's really for you to make just about enough to run something up in Production and let some or all of the proposed users take a look at it. The sysadmin may be doing hourly rolling restarts, and there may be hardcoded configs and secrets all through the code, but so long as it doesn't show the wrong person your bank account details, it's ready to go. You'll fix all the bugs and issues and poor practices later.

Now you've got a list (a backlog), which you need to prioritise. Estimates are hard, but try to quantify how much work each item is likely to be. Make sure you mark all this up as estimates and not a commitment.

Get all of this written up - start with a one/two paragraph summary of the issues and solutions. Then your full 'backlog' (with a red line, below which are jobs you could do after you've gone to production). Lastly, appendices with static code analysis or whatever else you've got.

Next, book some time with your boss and anyone else who's really, properly relevant (include enough people, but no one who doesn't 100% have to be there). Include your report as a "pre read" in your meeting invite. Present your findings (in summary - no more than about 10-15 minutes of talking), and wait for the questions. Refer to your report in as many answers as humanly possible.

Lastly, await a decision. How your management responds is important. If they decide to invest in the solutions you've proposed, then you're all good. If they choose not to because they're going to replace the solution with something else, then that's okay. If they try to get you to do something "on the cheap" or "more quickly" than you've proposed, then you should consider your position carefully, as they're asking for unrealistic things and not prepared to provide suitable resources for them either - that's usually a sign that they won't suddenly decide to invest once the code is in Production either.

Answer 3

From a practial viewpoint:

Your management doesn't know anything about code. It's a magic box that does the thing. They were promised the thing, they probably saw a presentation about the thing. The thing is real. They want it. They paid for it and now it has to work.

I've encountered you have to work "around" management, not as much incorporate them into the project or decision making. They don't understand your problems, your needs or what good practise is.
Usually they don't care how, as long as the thing works. The entire thing could be rewritten, as long as on the surface it looks like the thing.

I would suggest you treat this as a fresh project.

• Analyze what the purpose of the thing should be.
• See if you can create the thing in clean code.
• Only use the bad code as reference to glean what was discussed about it and how it should function in theory.
• Salvage usable code, refactor it into something practical.
• Code the thing cleanly in the two months.
• When done say to management, it's done, thing thing works.
• Under no circumstance mention that you "scrapped" the old code. Just say you refactored it to get it up to specifications.

Management looks at the black box and says hurrah.

Answer 4

If you say the code is rubbish, then your management has two choices: Trust you, or fire you. Not trusting you and keeping you on the project is not a rational choice.

And if you don’t understand the code because it’s too clever (I have seen code I didn’t want to understand, but no code that I couldn’t understand), then that code needs to be removed.

Answer 5

Time to bust out your technical writing skills. Create a report. Briefly explain that you will not be able to get the product viable in 2 months. Then propose a solution or solutions in your report and an estimate on time and the pros/cons of those approaches. For example:

'Option 1: a complete rewrite. My initial estimate is that this will take 11 months, but it will leave us with a robust, functional, and maintainable codebase.' (as an aside, good luck getting that approved, every developer in the world coming onto a new project wants to do a complete rewrite)

'Option 2: throw more developers at the problem. We will need X more developers to get this out the door in 2 months. This will cost more, and we'll lose dev time on other projects but we'll (probably) get it out the door'.

'Option 3, I work my hardest, and try to get as much done as possible. I don't believe I can complete the entire product, but here's an example of an MVP that I believe I can do. Are there any features you'd like me to prioritize over the ones I've laid out here?'

And so forth.

Then, as an appendix, briefly describe (in layman's terms) the problems as you've described them to us, and consider providing references so you have some credibility behind your arguments.

The idea is to immediately present solutions so that your managers can prioritize this product. Are they ok waiting longer? Or do they need to throw more resources at it. Be reasonable and professional.

Edited to focus more on offering solutions rather than criticizing the code, per the comments below.

Answer 6

You have to chip away at the magic doodad's reputation.

You can't tell them that it sucks, because then they will feel stupid, and they will decide you are stupid so they can go back to feeling smart.

If you've already made it compile, i'd skip that. It was an opportunity to chip away at the magic doodad, but now that you've fixed it, you don't want to complain about it.

I'd start with the hard-coded, un-encrypted passwords. Bring them up to management and point out that this has the potential to cause a lot of issues. Fix the passwords, and move on.

The uncalled functions and gibberish API's can wait. If they don't actually do anything, they probably can't break anything, either. I'd move on to the IP addresses or libraries.

When you find an issue with the magic doodad, make sure you tell management, then tell them how you fixed it. Over time, you will become their magic doodad, which is a great thing to be.

Answer 7

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

Your presentation

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

"Questions?"

Answer 8

What I would try to do:

Set up a meeting in person with the manager (your boss, project lead, whoever is most responsible for this code). Tell him/her in nice but clear words that the code does not work, and fixing it will not be a matter of weeks. If he/she does not believe you, offer to show it to other developers to get a second opinion.

Answer 9

What you think and what management thinks is not relevant. They have a product they want to deliver and you have a pile of inherited code that has made some attempt at becoming that product.

In its present state it either works correctly as that product or it does not. If it does not, what remains is to develop a plan to make use of the assets to hand (your time and skill plus whatever useful components of the code you've inherited) to produce that product. It doesn't do to dwell on the deficiencies of the code you have inherited - what matters is that you develop a plan to turn it into the product it was meant to be.

Your management would like that to happen within a given timeframe. Either you can manage your time to achieve that goal or you cannot. If you cannot then you require more resources and you need to let them know that. If more resources are not available, then the deadline must be sacrificed. It's really quite that simple. What they want from you is a plan - you need to figure out how it can be done. Dwelling on all the reasons why it cannot be done is not constructive. It is what it is - you have to deal with it and move forward.

Answer 10

There are two things I would do here:

1. Frame the situation. There are some red flags, so it's critical that you don't say anything to lead anyone on, or to reassure them that things will be ready on time. Remember that the problems/condition of the codebase are a result of those who worked on it before, but as soon as you start to take responsibility, it's on you. Don't allow yourself to be a scapegoat.

2. Evaluate what the product does in it's current state against the stated business requirements. The mistake that you're making is that you're focusing too much on code quality, which is subjective (you can't afford to fight this battle now). The people higher up really aren't going to care about that, they care if it works or not. Do this in an objective way. If they were told that something works, and it doesn't, you need to be able to document and demonstrate that. From here you can begin to estimate how much time you actually need, and back it up with facts/real work items.

In summary: be honest, be objective, don't over promise, and evaluate based on business requirements rather than code quality. You also want to be seen as a problem solver, not a problem creator, so be sure to focus on the solution and the path forward.

Answer 11

I'm sorry to be the bearer of cynical news but...

If it was so genius then it would not have been handed off to you 2 months before the launch date unless they think that you possess as much or more genius than the previous developer(s).

This sounds like a setup for failure. Management knows this is a mess but need to pass the buck on to some unsuspecting hard worker so that they can place blame down the line rather than themselves once upper-management starts asking for status updates.

Answer 12

If you have presented the state of this code to management as you have to us, and they are still convinced that it is in perfect working order with only two months needed for delivery...

You cannot change their minds - they are already convinced of this. Or worse yet, they are aware of the problem and are trying to play ignorance so they can pass the buck off to you when it fails.

All you can do at this point, if you want to stay committed to the project, all you can do is to buckle down and do everything in your power to get this code working, up to and including working overtime.

On top of which, I strongly urge that you practice through documentation, both within the code and outside it, so that when failure in the application is blamed on you, you can, at the very least, show that you have gone above and beyond the call of duty to salvage as much of it as you could.

Hopefully, someone in management will be wise enough to recognize a hard-working coder who wants to put the effort in to fixing their disaster project.

---

That being said - this project sounds exceedingly badly managed. I would advise you put some time into brushing up your resume, or looking for a transfer within your company to a new project. Because from what you've said, things do not look good for this one.

Answer 13

As an alternative approach, you could suggest that another developer has a look at this. Two, three, or fifteen people saying it doesn't work and won't soon might convince management.

Only works if there is someone else who isn't concerned with the project and therefore doesn't have to mask the truth.

Answer 14

First of all, don't assume that the code is so "bad".

Virtually every time I have seen a new developer come to a project, they pronounce the code bad, no matter how good or bad it is or who wrote it. Once I had been been working on a product for two years and they hired a new contractor and he told my boss that my code was worthless "spaghetti" code and needed to be rewritten. He got fired about 2 months later for lack of productivity.

In general, you should resist the urge to rewrite everything.

Try to limit your changes to what is necessary. You are not trying to create the Mona Lisa here; start off doing the minimum to accomplish whatever needs to be done. If you think that means rewriting the whole project, you are probably the problem, not the code.

There is absolutely no reason to make editorial remarks about the quality of the code to your boss. You are there to add functionality, not be a film critic. Keep your opinions to yourself, until you have proven your worth.

Answer 15

I feel like I have to add an answer specifically because you already have accepted one. It is not exactly wrong, but, IMO, kind of missing the point.

Forget the code for a moment. It will not be the first nor the last p-o-s code you have to maintain. As suggested, grind at it until you get some semblance of a working code-base, try to match deadlines, and so on.

The part that needs just as much preparation and care is your own situation: you are heading headlong into a critical phase in your life, where you yourself might be going to the dogs if you don't pay attention. The way it is right now, by your description of your situation, everybody upwards of you believes that everything is just fine, that they have a gold mine, and that there really is no problem.

The few quotes you gave already seem to suggest that they don't believe you, and think, well, not exactly badly of you, but at least neutrally; you do not seem to have standing with them. It does not matter how bad the code is. If it does not work at the deadline, it will be your fault, and your fault alone. You can document as much as you want, but the quotes you gave seem clear in that they are not interested in arguments, and don't wholly believe you either.

The problem is not necessarily that they are evil or out to get you. It is a common problem that people on a certain level think very differently from people at another. That's nobodies fault, but that's the way it often is. See; they so often hear technical people complain about how difficult some task is, or how broken some application is, that it's like background noise for them. They don't want to hear it. It's not a valid argument in their mind. And they are correct with that - it is not their job to know the technical details (and code quality is part of a technical detail...). What they do need to know is what you are missing to reach that goal.

So, in an optimal situation, you would have enough clout to tell them "I need 3 more people and an expert in XYZ to make this deadline". They provide what you ask for, you hit the deadline, and all is well.

Unfortunately, I see no sign in your post that you have that clout. They seem predetermined that you, and you alone, will fix the problems. When you miss the deadline (and especially when you then start to blame the code), then, depending on where you live, it's either a new job for you, or at least your career in that company might well be over.

So: get a manager on your side, maybe a team lead who still has roots in the technical side. Find a coach in your company who can speak for/with you, and help you with getting more workers assigned. But more importantly: prepare yourself for a phase of extreme stress, not because you have to work overtime, but because you may meet with discussions which will seem extremely unfair/hurtful to you, and extremely challenging and depressing. Watch for signs of burnout, depression or other stress syndromes (for example: not finding the energy to do sports anymore; not being able to talk normally with your family; etc.), and pull the line before you take damage yourself.

Best of luck!

(Source: BTDT)

Answer 16

This situation is typical of the following having happened:

At point A in time, a set of business rules for a process exists and is known, though not formally documented (or documentation is mistakenly destroyed later, see point D).

At point B in time, these business rules get implemented into code, working together with those that know them. The existence of the code is an incentive to not document the business rules, and to forget about them and/or stop caring about them not being forgotten.

At point C in time, the code is in use, and since it works, there is no NEED to know the business rules behind it most of the time. The code IS the de facto set of business rules now.

At point D in time, a critical amount of people having the knowledge from point A have left the company, or forgotten the business rules, or discarded existing documentation as obsolete. No one notices.

At point E, the code starts showing defects due to changes in environment, or would need functional changes. These needs are worked around instead of satisfied, since while any code extensions or fixes could be technically done, there is no easy way to TEST them, since the business rules that dictated what needs to be considered valid input, and what is valid output, are partially or completely unknown.

---

What makes that situation worse is an eternal conondrum about documentation: Keeping old, outdated documentation is important - at the same time, not knowing at a later point in time whether the documentation you have is even more outdated than what existed, since no one knows whether a more current version might exist and have been misplaced, or might have been destroyed.

Answer 17

May I inquire as to why you want to work here? Your project is a mess, which is bad by itself, but some like the challenge of cleaning up something like this. The real problem here, is that apparently a group of programmers have been allowed to work on a product for months (1.5gb of code, bad or not, is not a few weeks work), they have also apparently all left this project, and management has been so far removed from the project that they don't even know the current state of it.
These are huge red flags to me. How is management going to be able to manage you and allow you to efficiently do your job if they couldn't do it with the previous group? Why are all the previous programmers gone? How will you grow and learn at this company when apparently they don't give a damn about code quality? But perhaps the most important question of all, who is going to be your go-to when problems arise?
As it currently stands you have no assurance you aren't going to be thrown under the bus next time the stakeholders demand a demo. This is a toxic environment and there's a good chance the previous programmers left because of it, and now management is trying to cover that up by claiming it's 'genious code' and 'already in production', anything to distract you from the giant dung heap that is your inherited project.

Answer 18

Your high-level plan should be the following:

1. Architect a way forward. (*)
2. Estimate how long it will take to implement your "way forward".
3. Meet with the business stakeholders and communicate the following:
   1. That you cannot compile/run the current code (if that is still true).
   2. That it will take you 'X' days/weeks to rehabilitate the codebase into a compilable/buildable/runnable state.
   3. That there is additional work, beyond just making that code compilable, that you must do to make the code supportable and extendable.
   4. That it will take you 'X' months to implement your way forward. Then explain your way forward.(**)

--

(**) This is most important because you will need to persuade non-technical, business stakeholders that your plan is solid, feasible, and worthwhile.

--

(*) Here is my recommendation for a way forward, which can begin immediately after you can compile, build, and run the code.

1. Create automated unit tests.
   1. The unit tests will demonstrate that you understand the code.
   2. Code coverage statistics will continuously remind you about which portions of the codebase you understand and which portions you still need to probe.
2. Don't let anyone merge to the master branch without a pull-request that has been approved by at least two people.
   1. The pull requests will socialize your team's evolving understanding of the codebase.
3. Encourage a supportive culture, especially during this difficult time, amongst your developers.
   1. Try not to lose your cool. Other developers will sense your frustration and may become frustrated themselves.
   2. When a developer has difficulty with some tricky, legacy code, encourage other developers to lend a hand, and tackle the difficult code together, perhaps with pair-programming.

Answer 19

Dev here with some input:

Your concerns about the code are semi-valid at best:

There are same function, same variable names of the same scope throughout the code base (in a language which doesn’t support that).

If the language doesn't support it, how is a version of it out then? Seems like you're missing something here.

Functions are defined but never called.

What does this affect? Maybe it was stubbed out for something never implemented? Maybe it's for api completion?

Out of order variable usage and initialization.

This is common in code under maint, while it's not ideal in your situation, again this is common in older code.

Incompatible versions of libraries used.

See #1, how did it ever come up?

Hardcoded URIs and IP addresses with no documentation as to what they do.

Not ideal, but again, what does it affect in terms of delivery?

Randomly requested API routes which return nothing or gibberish; which are then not used.

See #2 again

Hard-coded, unencrypted passwords and private ssh keys.

See #5 again

Now after addressing those concerns as inconvenient, but trivial, I would have a valid concern about you setting any sort of direction, sorry, that's just how it is in the industry from what I've seen.

I do have a bit of advice though: You need a different sort of coding environment, like... a code shop, so look for an e-comm or a tech firm, where coding standards are a lot closer to the life blood of the business than say finance or manufacturing.

As far as bringing your concerns to management go... I like Tschallacka's answer. Just fix what's wrong with it without telling management and chuck it up as career experience you can then line item on a resume. I think I know the kind of management you're talking about (personal opinions aside) and they're there to manage, not innovate, so working around them is the way to go if you want to do the latter.