40

I have joined a new company recently and am in a bit of a bad situation. The company wants me to develop with their ERP system among other projects. However, it is this one particular thing, where I am just stuck. The thing is, that ERP system is partly serviced by a small firm that develops and sells this system, and partly by an internal employee who is retiring next month.

Employee responsible for this system is blocking passing info. They just share meaningless info about historic anecdotes and only share knowledge that I already had to discover.

They have an undocumented code base, coding style of 70s (lose txt dump, all loops with GOTO), no documentation apart from a few inline comments.

Retiring employee won't document anything, even after multiple requests by me. They are leaving next month and releasing information in a salami tactics way.

On top of that, they gave code execution permission to employees who never coded in their life and don't know what they are doing when they copy paste the scripts.

Time is running out, my boss asks me how this particular project is going and I can only hint that I only recently discovered I'd need more permissions for the system (because retiring employee did not tell me).

Now to my question:

How do I approach my superiors about this without risking to look like an asshole / being fired for badmouthing. Remember, I am still on probation and will be for another 3 months.

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – Lilienthal
    Jun 29 at 20:59

12 Answers 12

160
  1. Why would you "hint" to your boss about the situation instead of being completely honest with them about what's blocking your progress? Be honest and direct. Explain to your boss that you've been unable to make progress due to this other employee blocking your efforts to gain knowledge about this system. This isn't your battle to fight, so don't fight it.

  2. Why would you look like an asshole for bringing this to the attention of your boss? Bringing a problem to the attention of management, even if it's a problem due to another employee, isn't being an asshole, it's being a responsible employee.

  3. You can bring this to the attention of your boss without bad mouthing the other employee. Just speak to the problem. You don't need to put any negative spin on it.

  4. If your boss has told you to go to the other employee, and if you've done that, and if you still haven't received the information you need, then you need to go back to your boss and tell them. You can't force the other employee to share the information and if they continue to refuse to then this is a problem for management to solve, not for you to solve. If your boss won't take responsibility for this then they're shirking their responsibilities as a manager.

15
  • 58
    If you put it that way, then yes you might look like an asshole, but you being a professional wouldn't put it that way, right? You can describe the problem without being negative and without throwing the other employee under the bus. "These are the problems with the existing codebase. I've been trying to work with XXX but haven't been able to make any progress getting the information I need."
    – joeqwerty
    Jun 27 at 15:50
  • 9
    That's direct and to the point. Stating the facts (that you're not getting the information you need from the other employee) is neither being an asshole nor throwing the other employee under the bus. These are the facts. These facts are preventing you from doing your job. State it as such.
    – joeqwerty
    Jun 27 at 16:11
  • 15
    @testerJester Saying that the other employee is a non-coder from the 70’s is being an asshole, saying there’s problems with the existing code base isn’t. It doesn’t matter why there are problems, only that they exist. Every single problem might have a root cause where you would say “That is exactly what I would do under those circumstances today”, but that wouldn’t make them less of a problem for you. Brilliance, incompetence, dedication, indifference, priorities, funding, available tools, all irrelevant to today’s problems..
    – jmoreno
    Jun 27 at 16:42
  • 9
    @testerJester Don't ask verbally : make specific requests in writing (by email) to the employee in question and indicate that you need responses in writing. Identify what you need to know, start at a top level and go into lower level detail later in follow-ups. Make clear you need their help - show gratitude - it's probably a lot of hard grinding work done by the retiree over decades that you're expecting as a gift. I've worked on 20+ year old code bases devoid of documentation by people who were actually dead - your situation is actually not as unusual as you may think.
    – StephenG
    Jun 28 at 4:03
  • 22
    @testerJester "[...] eventually take any disciplinary action". Why should you even mention that? You shouldn't care about whatever happens to employee XXX. You should only care about the codebase. I think that is the root of your problem: focus on the codebase, not the employee. Do not defend him, do not throw him under the bus either, and do not hope for some disciplinary action. This is just noise in your head, and that is what could eventually lead to you being badly judged by other employees.
    – dim
    Jun 28 at 9:58
46

I know you're still on probation now, but the more you wait before sounding the alarm, the worse it's going to end up for you. I pretty much guarantee it.

With that said, when approaching your boss with a problem, you should also have a set of potential solutions you can propose as well. If you don't have good solutions to propose, then your boss may try to come up with their own solution(s) on the spot and their solution(s) will either be incomplete or totally unrealistic.

So ask yourself, what could possibly work in a case like this? The guy is retiring. Your boss has little leverage over him. Can you start pair programming with him? If you're not in the same room, can you move your desk closer to him? If he likes chocolate, can you buy him a box of chocolate? If he likes sports, can you learn about sports so you have a common interest to chit-chat about? Or if the rest of your workload is too high, can you ask your boss to reduce it for a couple of months until this transition is complete?

Obviously, my own ideas are half-baked, but you get the idea. You need to brainstorm and think through a number of potential solutions yourself first.

And if there is any bad news to be delivered, it needs to be delivered now, not later. If you wait for things to get out of hand before you tell your boss what happened, your boss won't ever trust you again.

Additionally to that, they gave code execution permission to employees who never coded in their life and don't know what they are doing when they copy paste the scripts.

Interesting. Are those scripts under version control? If nothing is under version control, that's the first thing I would do. I would put everything under version control. What about tests? Could those scripts benefit from better automated testing? Or from being wired up to some monitoring software like Nagios?

Also, do not assume malicious intent. That person may just have a better relationship with those other people he gave execution access to. Or perhaps, he didn't want to be bothered, and simply gave it to them because it was the most expeditious thing to do.

Pair programming is the first thing I asked for. I wanted to make a meeting where they show me how to just simply go about designing and programming a simple query for this ERP system. However, the second meeting they said they were not prepared and gave excuses that this is not doable and everything is well documented.

This is very serious. Raise the alarm! Ask your manager to do pair programming with the two of you.

But prepare your manager in advance, if this guy comes up with the same excuses and says that everything is well documented, have your manager ask you to take over his keyboard and test you on the spot while the other guy is watching.

Tell your manager that he can blame you for being incompetent. In other words, tell your manager to be as hard on you as possible in front of this other guy, since he can't really apply pressure on him directly.

Then have your manager come back the next day and do the same thing again. Even if the guy promises to help you, he's probably not going to do it consistently. That's why your manager needs to make the commitment to follow up and do some pair programming with the two of you once a day or once every two days for the next 30 days.

In other words, you need to hash out a plan for your manager, and think things through carefully, just like if you were playing a chess game 6 moves in advance. Think things through, take some notes, and make sure your manager is fully prepared before he even tries to address this situation.

As for version control: The scripts are stored as .txt on hdd and copy pasted into a shell of the ERP program for execution. There is no version control, no tests not anything modern software development would do.

Are there regular backups? If there are no backups, make your very backup at the very least, put it somewhere else, and label your zipped folder with backup_year_mm_dd

And come up with a longterm plan to progressively modernize the rest of these issues.

8
  • 5
    Yes, we say at my company "bad news never gets better with time". It's never fun to have to deliver bad news, but better to quickly say something will take longer than expected than to wait right before the deadline.
    – Kat
    Jun 27 at 22:56
  • @Kat I think this is great advice. I will take note of it and keep it in my head. Thank you :) Jun 28 at 18:59
  • 1
    Pair programming is the first thing I asked for. I wanted to make a meeting where they show me how to just simply go about designing and programming a simple query for this ERP system. However, the second meeting they said they were not prepared and gave excuses that this is not doable and everything is well documented. As for version control: The scripts are stored as .txt on hdd and copy pasted into a shell of the ERP program for execution. There is no version control, no tests not anything modern software development would do. Jun 28 at 19:04
  • @testerJester, I've edited my answer with my reply. Jun 28 at 20:21
  • thanks for your edited answer @StephanBranczyk. I think the long term plan is to set up good documentation and a git repository for all the code. It is backed up because the .txt also lie on a network folder and these get automatically backed up by IT. While I can see the direct confrontation might be a good thing in certain situations. Right here I think it will not fit. Because my boss has no programming background and this will be too time-consuming for my manager just to accompany us. Therefor I rather have my boss involved via email than with pair programming. Jun 28 at 20:34
30

The tone of your question seems to blame the retiring employee. "Salami tactics." "Blocking." "Meaningless history." Have you considered that the legacy system might have been a millstone around the neck of the other employee who is glad to be finally rid of this junk, and who got lots of information on other systems to pass on before retirement? You do this ERP among other things. What is the colleague doing among other things?

I know about situations where the management decided to run a legacy system with minimum maintenance until the replacement was ready. Which got postponed again and again. Staff got reassigned, staff left, and then someone is being held responsible for the legacy system who has the least tenuous connection to it. Recreating documentation in a case like this can take man-years, and those man-years are not available any more. Have they ever been made available?

What I'm trying to say is find out from your manager, and the retiree's manager, what the priority of this system is. Only if it is top priority for both of you things might work out as you seem to expect. If it is top priority for you but not the retiree, someone higher up has to resolve this.

And if it is not top priority, that decision has outcomes which your managers should know. It isn't your decision to make.

1
  • Thank you for providing me with this different perspective. The way you point it out, it can be perceived very negatively. The thing is, I got other projects with other departments whose ppl are very forthcoming. They show the docs, they call and ask back if their advice they gave me helped me etc. Only this employee is completely blocking. The system sure is legacy, the ERP system not (the ERP is continually updated by IT). AFAIK the colleague is just doing that system and occasionally vacation replacement for an IT guy (i.e. handing out new computers, system installs etc). Jun 28 at 19:09
15

Just tell your manager you don't have the relevant documentation and the system is out of date in terms of protocols etc, so will be difficult to work with without proper documentation. Go in to a bit of detail, not too much unless asked to clarify.

This is what gets things moving. When their system is called in to question they will soon jump to prove it's up to scratch and bend over backwards to make sure you have everything you need. The alternative is they might lose the client. Don't worry about the old guy too much, he's almost irrelevant, he has no incentive to do anything for you.

9
  • I am not too worried about the old employee. I am worried that calling this employee out will shine a bad light on me. Sadly that old employee is the only one that developed this particular "system" which kept the company somehow going. Jun 27 at 11:44
  • You don't call him out, you call out the system. Let the service providers do the work for you.
    – Kilisi
    Jun 27 at 12:21
  • 2
    You are NOT the budget for the system. You do not have the authority to be the budget for the next two years. Simply report all the information you have to your manager and let them handle the situation. Be as transparent to your manager as you can.
    – David R
    Jun 27 at 13:53
  • 5
    You are asssuming "they will jump to prove its up the scratch". In fact, they might welcome the opportunity to just ditch a customer who is stubbornly hanging on to an obsolete product written decades ago and not earning them any meaningful revenue.
    – alephzero
    Jun 27 at 20:51
  • 1
    @alephzero which would confirm the OP's misgivings and pass the problem higher up. Not the OP's problem.
    – Kilisi
    Jun 28 at 2:03
9

This is classic S.E.P. Kick it up the tree as quickly as you can. Time is of the essence & you can't achieve anything.

Realistically (and, again, this is not your problem), if the company wants this done, the quickest and cheapest way is probably to rehire him immediately as a consultant (this may even be what he is angling for).

In defence work, if I had an <x> for every time I have seen this happen, then I would have a very large heap of <x>.

3
  • 1
    Thanks for pointing that out. That is what I already discovered and why I looked for help here. My question was how to go about kicking it up the tree. Not that I am knocked down by it. And considering the consultant thing: I think that would be the only motif for them, because they gain nothing by hindering that process apart from being needed after entering retirement. Jun 28 at 19:12
  • "how to go about kicking it up the tree"? You inform your boss, in writing. If nothing happens, you _could_ consider going over his head, but why bother? 1) your email has protected your donkey 2) you risk micturating off your boss (otoh, he is likely to be POed when the excrement strikes the oscillating ventilation device & you produce your "get out of jail free" email. Only you know your relationship with your immediate boss, so do what you judge to be best, but 1) create an audit trail, and 2) look after yourself first & foremost, because, sure as eggs is eggs, no one else will) Jun 29 at 6:26
  • @testerJester What they gain is not having to go do research and create documentation. Imagine you have worked for a long time and are finally ready to retire. You just have to survive a little longer and then you can be rid of this crummy system and management who don't invest in upgrades for internal systems. And now someone wants you to spend that time working incredibly hard to research exact details of what the system does and write it down in a nice, clean form for them, so that they don't have to research the system themselves. Jun 29 at 16:53
8

I heard a story about this from an intern who got the assignment to add a feature to the program a business was using. The program was build and maintained by one guy who was also about to retire. The guy refused to work with the intern making things very difficult. In the end the intern, boss and university supervisor talked with the guy. The guy just wanted some extra money before retiring and after getting said money he was very co-operative.

4
  • 3
    A risky approach. Some companies would fire you just on principle, and hire someone experienced to get the code up to scratch and documented.
    – gnasher729
    Jun 28 at 9:30
  • 1
    But who is more experienced in that particular project? He has them over a barrel & will most likely be rehired next week as a "consultant". Jun 28 at 11:18
  • 1
    @gnasher729 Hire someone experienced just on principle? It is just totally laughable. For code that is internal, complicated and has been around for a long long time, where do you find this mythical experienced person that just happened to magically be experienced with it? Jun 28 at 15:34
  • @stackoverblown - i am with you here. If this code is not maintained and properly documented it will be nearly like a complete rewrite. Problem is, the company is reliant on this system and has to stay operable. So the timeframe is really tight to impossible if a new system from scratch should be instated. Jun 28 at 20:39
5

Welcome to the real world of software development.

  • Your real task is very different.
  • Make your boss understand your real task.
  • Your predecessor is your friend.

You were thrown into the cold water of reality of software development.

In academic contexts, you always start development at the first step of development.
In practical software development, you normally start after others have worked on the first steps, and you base on their result.

In your situation, you expect to do that by finding out what you need to know, and start to work from that, building on it, maintaining it or working with it.

In many if not most real world cases, this is just not possible. The information that you need to know does not exist in a form that could be written down.

People who were able to work with the system in some way, like maintaining it or continuing development, did that based on their experience with the system to some degree. They know how it is structured, how it works and how to use it. They learned it from others, from developing parts themselves, and from actual experience.

This is hard to impossible to write down.
There are parts that can be written down of course, procedures of installing it in a local system, starting it, shutting it down, find message logs etc.

You see your task as to pick up development where your predecessor left it. And that may even be how your job is described and what is actually expected from you.

But this is not possible.

You need to understand the existing system first, and that is usually hard. And it may be a much larger task than the original task of "Add feature X".

You need to explain it to your boss. He has to understand that "Add feature X" needs to be replaced by "Understand system", "Add feature X".

An important aspect is that you should not see your predecessor as an adversary. He cooperates with you, he is your friend, he has the same goal: The success of the company. You cooperate with him.

If he does not give you a certain information, or does not give you a meaningful answer to questions like "How does this part work", or "Why is this the way it is" it is because he can not. He can not give you the information you need.

So, you have some basic information about the system, but you need much more. You just can not get that information in a straight forward way. If that means that you can not solve your task: Relax, it's normal. Large part of your job is to handle this kind of problems, it would be unusual that you could just solve tasks that are given to you in a straight forward way.And do not be surprised if you need skills that you did not learn as part of your education. You will get used to it - it is somewhat stressful in the beginning, but in part a question of perspective.

So:

  • Accept that software development in the real world is often messy and frustrating.
  • Explain to your boss that there is an very significant task before you can continue the work.
  • Do not forget that your predecessor is cooperating with you, and you cooperate with him. To do this, even if he is grumpy, is part of your work.
11
  • 2
    +1 - The ultimate trustworthy documentation is the code itself. It takes longer to understand than design documentation (if it exists) or notes of how others think the system works, but it is the only documentation actually guaranteed to match the implementation (most of the time - memory corruption or self-modifying code excepted!). There may be thousands of questions similar to "how does the widget get frobbed?". Familiarity means one can know roughly where the code for GetWidget, GetFrobber, ApplyFrobberToWidget is, and a simple search does the rest with the code explaining exactly.
    – Steve
    Jun 29 at 7:39
  • Better to have a few "example questions" with details of how those answers were found in the code, than the near impossible task of completely documenting an undocumented system within a few weeks. It will probably take years to gain sufficient familiarity to find such answers quickly. Any changes done going forwards, or any important questions that were difficult to find answers to can of course be documented to current standards (with the documentation maintained as the codebase or understanding changes - incorrect or out of date documentation can be worse than no documentation!)
    – Steve
    Jun 29 at 7:49
  • Debug mode is your friend. Line breaks are you friends. Grep is your best friend! Jun 29 at 16:48
  • 1
    @testerJester I mean it in the sense of the transition from well structured environment, like academia or a startup company or just a good work environment into something that is different. An extreme case would be to find yourself in a cold and loud server room, where you need to "fix some problem" - without even knowing how the system works if you sit on your desk. A situation where you literally can not apply a single competency you have. Of course, the transition is less harsh, normally, but it is a sudden change. Jun 29 at 23:38
  • 1
    @testerJester One example is the question of accepting the situation. In this case, you say your predecessor is actively malicious. That is a problem, but not your problem. For you, it is just reality, without any ethical aspects. Somebody else may bring him to court, or in this case threaten to do it, but you should not think about that - only report your technical problem with it. In this case, you may not get access to an existing technical document you know exists, for example. Jun 29 at 23:42
3

Turn information into documentation, and the "interviews" into collaborative steps of a structured process. The end result is the delivery of the ERP documentation, and providing the information you need is part of fulfilling tasks in the project.

With this framing you will be able to show progress or lack thereof, measure the time it's taking the employee to fulfil those tasks, and, most importantly, create a paper trail if critical information is not being shared by the employee before retirement or termination.

5
  • 1
    I really like this idea. But this being a side project and my boss not caring a lot about documentation such a route will be difficult to pursue. They are rather about numbers. Like what impact (i.e. time / cost savings) this or that system could provide. And the effect of documentation - while i agree with you is of enormous importance - can not be easily measured Jun 27 at 15:55
  • 1
    It's not the documentation that's important, it's the discovery process you go through to produce the documentation. This is how you learn how the system works and how to maintain it. Jun 27 at 16:09
  • 1
    @testerJester "the effect of documentation - while i agree with you is of enormous importance - can not be easily measured" Sure, it can be. How much time do you think you're going to waste trying to figure the system out without the documentation? How much time would it take you to recode the whole thing from scratch using modern coding standards? Multiply that time by your salary to get a cost estimate, and show it to your boss.
    – nick012000
    Jun 27 at 20:11
  • 1
    @testerJester, You said "this being a side project". Do you mean to say this project is not important to your boss and the company ? Are you also working concurrently on other projects that are more important ? Jun 27 at 23:11
  • @Job_September_2020 this project is not generating visible revenue. It was somehow working in the past and is expected to work in the future. The internal processes are reliant on this thing and the boss does not see the mid- long term problems that may arise from this. While maybe I get that particular employee to explain one single thing, it could be that at end of year, when system is really needed, things are not going as expected. And then disaster already struck. That is the situation I want to avoid Jun 28 at 20:42
3

Could I suggest you make a questionnaire that is listing main components of the system.

Like:
Permissions
Apis
Databases
Functions
Stakeholders
...

Then partially fill it in with the stuff you have discovered already, CC your manager, and sent it to the guy asking him to fill in the gaps.

Be as detailed as you can about stuff you don't know, this way if there is info missing higherups will see that you asked and that info wasn't provided, or provided incomplete, false, etc.

Then if he comes back with missing info resend back with extra questions.

1

There's a lot of stuff in the other answers. They all point to "going to the boss" and that's partially correct. @joequerty's answer basically says "go to your boss" in several different ways. Of course you have to communicate what is going on to your boss, and yes, that is risky for you but not as risky as letting this slide until the retiree is gone and you're left "holding the bag".

The problem with most of the answers, however, is that "the boss" won't necessarily be able to do anything. The guy is retiring presumably after a long career. The only leverage available is perhaps some kind of cut-off of his exit package (if there even is one) for failing to cooperate. There's probably nothing for him to lose and it seems like the individual could be disgruntled or burned out. If you've tried developing rapport and communicating with him and tried leveraging management-- there's not much more you can do with this person! Write him off.

The other problem with some of the answers is that they assume this is a mere "hand-off" requiring some hours of very structured "knowledge transfer". It's not. This is an ERP system. It's guaranteed to be an ugly bloated piece of enterprise software that, figuratively speaking, has many layers of duct-tape that were wrapped around it in haste under pressure from bean-counters in both your company and from the ERP vendor. These systems always have to adapt in ad-hoc ways to unforeseen and ever-changing business requirements. It takes time to get through that history and understand why things are the way they are. There are no shortcuts, you'll never get a phone-book-sized knowledge dump. The best you can hope for is enough fluency to be able to research the system and come up with solutions after a lot of effort.

Here are some other things you can do:

  • Since this is an ERP system with a vendor behind it, you should be able to make contact with the vendor and arrange for onboarding support. It will cost money, but that's OK if it helps you get to success. ERP's have their tentacles in every part of the company and they're vital to operations. As much as the people with the purse-strings may feign economy, they will gladly to shovel money towards the ERP vendor to keep things going smoothly. Your engagement with the vendor will likely last for a significant amount of time, so be sure to take care of the relationship.

  • On your company's side of things, there are other people you'll want to get to know: the power users of the system. They are the people that will help you get oriented when things aren't going right. If you know all of them and develop relationships with the right ones, they're invaluable to making sure everything is running properly. They are your customers and that should be taken very seriously. These are likely the folks who have been given "code execution" permission. Find out what their workflow is. They know what they're doing domain-wise (better than you ever will) and have been given special permissions because they're trusted. Learn to trust them too! And learn as much as you can from them. It doesn't matter if they've never coded anything-- you have bigger problems now.

0

Assuming you had a talk with this employee regarding this issue and the employee basically you are certain you cannot have any more collaboration from them...

Then the next step is having a written record of your interactions with them.

Start writing emails to this employee and always CC your bosses. If the employee replies without the CC, reply again adding the CC of your boss (I often just reply writing simply "+ ), citing the old email so that your bosses have a complete history of your communications with them.

Whenever you speak with them send a summary email about what you talked about and any pending action point on both parts and keep your boss CC'ed at all times. If the employee does not fully satisfy your requests send an email, maybe attach what they provided and explain what is lacking etc.

If your boss tells you that you are annoying them tell them this the CC is needed because the other employee wasn't collaborating productively without it and you need a clear written record of interactions in case things go sour.


Be aware that this employee may really don't give an F about anything given their situation. They might be trying to delay the knowledge transfer to after they retire so that they can force your boss to hire them as consultant at 5 times the pay grade... if that's the case it will not be possible to fulfill your job and there is nothing you can do to change this and this is why it is so important that you document all your interactions notifying your boss, so that they can understand where the blame lies.

1
  • Thank you for pointing out the email etiquette. I already use the cc bit. The emailing back with cc-ing my boss when they just reply with me is a good hint. Jun 28 at 19:14
0

You need to book a full day for a proper system handover where you talk to each other, mailing back an forth just isn't working here.

If you can't get the information you need, ask your boss for some consultant hours from the company that developed the system. It'll be way cheaper than having you try to figure everything out on your own.

1
  • 1
    More likely will need at least a year of paired programming, no point pretending the impossibly is possible.
    – Ian
    Jun 29 at 16:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .