IT consultant left and no one can understand his style of programming [closed]

Question

There are a small group of programmers where I work. A few years ago our boss brought a consultant in to help us move to a newer programming language. Since then our boss was 'resigned' and we now have a new boss. The consultant has recently left and everything he was working on has been divided between the existing developers. This consultant mainly 'worked on his own' while we all sat back wondering what he was doing, he was taking direction only from the boss who is now gone. All of their meetings seemed secret, none of the existing developers had any say or input in any way.

The problem is that none of the existing developers can work on the new code because they do not understand how it works. The consultant was overqualified. His advanced ways of programming has left us in a situation where even most simple requests can not be completed.

We now need to manage this resource internally, but we have not been given the experience or knowledge to do so. How can we manage this issue?

Answer 1

It's a very common situation that comes up in the workplace - the all-knowing superhero is now gone (for good or bad, and for whatever reasons), and the team of just regular everyday normal people is left to pick up and keep going.

Step 1. Talk to your management and let them know the facts. Don't accuse, judge, or criticize. Just explain that as you and the team have started going through the software, you're finding it very difficult to follow and it will take additional time to become familiar with what is there. New work will be slower for a period of time as a result.

Step 2. Divide and Conquer. As a team, divide up the software in any way that you can agree upon and each of you commit to becoming the team expert on your portion of the code. Dive in. Make small changes, try to predict the results, rebuild, and see whether you predicted correctly. Give yourself a deadline (maybe 1 or 2 weeks). Create documentation for yourselves.

Step 3. Teach each other your findings. Get together regularly to discuss what you're finding. Hold each other accountable for producing good documentation that can be combined into some sort of manual. Send the documentation to your management for them to see that you're making progress.

Step 4. Repeat until competent.

In Step 2, you might include getting actual work done as one way to dive in and figure out how everything works.

It's a lie that the guru was overqualified for the job. What's actually happened is that you and the rest of the team have allowed him to take on everything, and you have not applied yourselves to learning the system like you should have. It might be the worst designed software ever, or it might be a work of art. But you'll never know until you take ownership of it, both professionally and emotionally.

Answer 2

Seems simple enough. Tell your new boss, it's a problem that he needs to be aware of. And the sooner the better because this could quickly escalate into a very serious problem for the company if urgent work was needed and no one knew where to start.

Explain to the new boss basically what you have just told us and then let him handle it. With a bit of luck you might even get some paid training to upskill yourself with at the companies expense.

It's always best to have a solution in mind when speaking of problems to a boss. In this case upskilling is an option I would bring up which would mean time off from other duties so you or another developer could concentrate better.

Another possible solution to mention is a consultant to be brought in short term to work with the developers.

Then basically let the boss do his job and make his decisions.

Answer 3

What you need is an overview of the architecture, and the best person to give it is the consultant. If talking to him is is not leading anywhere, let him prepare diagrams, how everything is linked together, on a high level.

With this information, look at the code, try to identify things or where you would make changes. Then in a second round, let him describe in more detail the things you want to change and where to do that.

You give him a list of features A-F and for each feature he tells you the file and maybe function name. Then you try to implement your changes. Try to involve him as little as possible, so you better understand where your deficits are and what you have to learn.

Don't try to directly migrate things to your known languages. There is a reason he was brought in and his language might be better. Try to learn it, so you can make an eductated decission which parts to keep maintaining and which parts to move to a familiar language, or a completely different one.

Also try to figure out which parts of his code are standard for that language and which one he has just hacked together. Try to switch to standard solutions where you see fit. That makes future maintenance a lot easier and will reduce training for new coworkers who already know the language and the standard way of doing things.

Just out of curiosity, what technology are we talking about? :)

Answer 4

80% of the answer belongs into software development (probably programming.stackexchange).

The 20%: You need to tell your new manager or new boss as soon as possible what is happening. Probably the best way for him to fix the problem is hiring an experienced contractor for a month to assess that person's code (just because you think he was overqualified doesn't make it so; a highly qualified person would leave code that you can pick up).

After that month, the company needs to either decide that this person's code is just rubbish and cannot be salvaged, or to ask that contractor to stay for another few months, put the code into a shape that can be maintained, and train a few of you guys to be able to take on the work.

On the other hand, that assessment might be very quick: As an example, I write lots of code in Objective-C with blocks, and if you have never seen this, it looks frightening. It takes a week to learn it and two weeks to love it. So in that situation someone could come in and say "this is just ordinary Objective-C code, you just have to learn it" (would apply to any other language).

Answer 5

Refactoring is the way to go. It will cost time and money, and probably you will need a specialist consultant to do it.

What it means is the you take the complicated and impenetrable code and modify it step by small step, preferably using tools but also by hand, and regression testing each step. Refactoring ranges from relatively simple things like renaming variables and procedures to more understandable names, to restructuring the code. Each step individually is manageable and does not change to results of the code. Of course you keep the original code separately as it will be your yardstick and reference point.

By the way, in the process you will most likely discover bugs in the original code and it is a tough decision when to fix them - during the refactoring or after it is complete - because if you fix them too early you may lose the option to compare the output of the refactored code with the output of the original code.

Good luck.

Answer 6

This is not uncommon. I have been in similar situations and it can feel overwhelming. Talk to your supervisor and explain the situation, as other people have said.

The first thing I would do is ask the former consultant if he would be willing to come back and explain his code. He might be amiable and do it for free. However, he might only come back if you pay him.

At this point the onus is on you and your development team to take copious notes and ask as many questions as possible. Learn as much as you can about how and why he wrote his code the way he did.

Answer 7

First check the style of coding. Did he use a framework? If so first check the framework documentation and try to understand the concept. A good code review is the next thing you have to do. A code review will reveal how and why a certain code is implemented. A special task force can be entrusted with the R&D and code review. Once they find coding flow it is a matter of starting from there.