Mixing
IT consultant left and no one can understand his style of programming [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
19
down vote
favorite
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?
management ethics developer failure consulting
edited Sep 23 '15 at 12:28
Peter Mortensen
45547
asked Sep 22 '15 at 21:16
Rose
20224
closed as off-topic by Lilienthal♦, alroc, scaaahu, gnat, The Wandering Dev Manager Sep 23 '15 at 11:09
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – scaaahu, gnat, The Wandering Dev Manager
 |Â
show 2 more comments
up vote
19
down vote
favorite
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?
management ethics developer failure consulting
edited Sep 23 '15 at 12:28
Peter Mortensen
45547
asked Sep 22 '15 at 21:16
Rose
20224
closed as off-topic by Lilienthal♦, alroc, scaaahu, gnat, The Wandering Dev Manager Sep 23 '15 at 11:09
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – scaaahu, gnat, The Wandering Dev Manager
8
This might be a question for programmers.stackexchange.com since it's more about how to decipher code than the workplace. However, can you get the consultant in for a day to explain his code?
– Jane S♦
Sep 22 '15 at 21:19
79
The consultant was overqualified. His advanced ways of programming...This does not sound like an overqualified individual, but rather a lone wolf. A programmer who makes complicated, hard-to-understand code is not a good programmer, no matter how well that code works.
– Martin Carney
Sep 22 '15 at 21:20
2
I'm voting to close this question as off-topic because it does not seem to be about navigating the workplace as defined in the help center.
– Lilienthal♦
Sep 22 '15 at 21:42
15
@Lilienthal The asker has an issue with a former employee not providing handover information about a corporate resource - this is very much a workplace issue
– user9158
Sep 23 '15 at 2:51
29
Just a side note, reading and understanding bad code is part of your job as a programmer. Everyone else's code sucks. Even yours from a few weeks ago sucks. All code sucks. Don't ever expect it not to suck.
– corsiKa
Sep 23 '15 at 8:33
 |Â
show 2 more comments
up vote
19
down vote
favorite
up vote
19
down vote
favorite
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?
management ethics developer failure consulting
edited Sep 23 '15 at 12:28
Peter Mortensen
45547
asked Sep 22 '15 at 21:16
Rose
20224
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?
management ethics developer failure consulting
edited Sep 23 '15 at 12:28
Peter Mortensen
45547
asked Sep 22 '15 at 21:16
Rose
20224
edited Sep 23 '15 at 12:28
Peter Mortensen
45547
edited Sep 23 '15 at 12:28
Peter Mortensen
45547
edited Sep 23 '15 at 12:28
Peter Mortensen
45547
45547
asked Sep 22 '15 at 21:16
Rose
20224
asked Sep 22 '15 at 21:16
Rose
20224
asked Sep 22 '15 at 21:16
Rose
20224
20224
closed as off-topic by Lilienthal♦, alroc, scaaahu, gnat, The Wandering Dev Manager Sep 23 '15 at 11:09
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – scaaahu, gnat, The Wandering Dev Manager
closed as off-topic by Lilienthal♦, alroc, scaaahu, gnat, The Wandering Dev Manager Sep 23 '15 at 11:09
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." – scaaahu, gnat, The Wandering Dev Manager
8
This might be a question for programmers.stackexchange.com since it's more about how to decipher code than the workplace. However, can you get the consultant in for a day to explain his code?
– Jane S♦
Sep 22 '15 at 21:19
79
The consultant was overqualified. His advanced ways of programming...This does not sound like an overqualified individual, but rather a lone wolf. A programmer who makes complicated, hard-to-understand code is not a good programmer, no matter how well that code works.
– Martin Carney
Sep 22 '15 at 21:20
2
I'm voting to close this question as off-topic because it does not seem to be about navigating the workplace as defined in the help center.
– Lilienthal♦
Sep 22 '15 at 21:42
15
@Lilienthal The asker has an issue with a former employee not providing handover information about a corporate resource - this is very much a workplace issue
– user9158
Sep 23 '15 at 2:51
29
Just a side note, reading and understanding bad code is part of your job as a programmer. Everyone else's code sucks. Even yours from a few weeks ago sucks. All code sucks. Don't ever expect it not to suck.
– corsiKa
Sep 23 '15 at 8:33
 |Â
show 2 more comments
8
This might be a question for programmers.stackexchange.com since it's more about how to decipher code than the workplace. However, can you get the consultant in for a day to explain his code?
– Jane S♦
Sep 22 '15 at 21:19
79
The consultant was overqualified. His advanced ways of programming...This does not sound like an overqualified individual, but rather a lone wolf. A programmer who makes complicated, hard-to-understand code is not a good programmer, no matter how well that code works.
– Martin Carney
Sep 22 '15 at 21:20
2
I'm voting to close this question as off-topic because it does not seem to be about navigating the workplace as defined in the help center.
– Lilienthal♦
Sep 22 '15 at 21:42
15
@Lilienthal The asker has an issue with a former employee not providing handover information about a corporate resource - this is very much a workplace issue
– user9158
Sep 23 '15 at 2:51
29
Just a side note, reading and understanding bad code is part of your job as a programmer. Everyone else's code sucks. Even yours from a few weeks ago sucks. All code sucks. Don't ever expect it not to suck.
– corsiKa
Sep 23 '15 at 8:33
8
8
This might be a question for programmers.stackexchange.com since it's more about how to decipher code than the workplace. However, can you get the consultant in for a day to explain his code?
– Jane S♦
Sep 22 '15 at 21:19
This might be a question for programmers.stackexchange.com since it's more about how to decipher code than the workplace. However, can you get the consultant in for a day to explain his code?
– Jane S♦
Sep 22 '15 at 21:19
79
79
The consultant was overqualified. His advanced ways of programming... This does not sound like an overqualified individual, but rather a lone wolf. A programmer who makes complicated, hard-to-understand code is not a good programmer, no matter how well that code works.– Martin Carney
Sep 22 '15 at 21:20
The consultant was overqualified. His advanced ways of programming... This does not sound like an overqualified individual, but rather a lone wolf. A programmer who makes complicated, hard-to-understand code is not a good programmer, no matter how well that code works.– Martin Carney
Sep 22 '15 at 21:20
2
2
I'm voting to close this question as off-topic because it does not seem to be about navigating the workplace as defined in the help center.
– Lilienthal♦
Sep 22 '15 at 21:42
I'm voting to close this question as off-topic because it does not seem to be about navigating the workplace as defined in the help center.
– Lilienthal♦
Sep 22 '15 at 21:42
15
15
@Lilienthal The asker has an issue with a former employee not providing handover information about a corporate resource - this is very much a workplace issue
– user9158
Sep 23 '15 at 2:51
@Lilienthal The asker has an issue with a former employee not providing handover information about a corporate resource - this is very much a workplace issue
– user9158
Sep 23 '15 at 2:51
29
29
Just a side note, reading and understanding bad code is part of your job as a programmer. Everyone else's code sucks. Even yours from a few weeks ago sucks. All code sucks. Don't ever expect it not to suck.
– corsiKa
Sep 23 '15 at 8:33
Just a side note, reading and understanding bad code is part of your job as a programmer. Everyone else's code sucks. Even yours from a few weeks ago sucks. All code sucks. Don't ever expect it not to suck.
– corsiKa
Sep 23 '15 at 8:33
 |Â
show 2 more comments
7 Answers
7
active
oldest
votes
up vote
64
down vote
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.
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
27
Good answer. I'd just like to add that unless the Consultant invented a new language there are resources everywhere for pretty much every language out there. I don't understand why your team wasn't active in thoroughly learning the new language or at least enough to perform simple management and alteration. If I understand it, he was there for years, but at the end of the day he was a Consultant. What did your team/Boss think was going to happen? Color me baffled. I guess count it as a learning experience, do what Kent said, and explain it to your Boss as best you can.
– zfrisch
Sep 22 '15 at 23:09
6
Just realize there isn't a prerequisite for the coder to be super smart to not understand their code. They can be super dumb and people also won't understand the code.
– Nelson
Sep 23 '15 at 5:33
1
For #2, I suggest you also start figuring out how to add tests (or run the existing ones) so that as you modify things, you know if you've broken anything as you come up to speed and make changes. Writing this test infrastructure will also help you learn to understand how it works. This will help you gain confidence with the code base.
– rrauenza
Sep 23 '15 at 6:47
12
I've seen this both ways. Programmers who thought they were super-clever and created an overly-complex mess, and programmers who got slapped for trying to use current techniques in a shop that was stuck in the past. For some shops dependency injection and functional programming look like Martian.
– kevin cline
Sep 23 '15 at 6:52
2
Might be worth emphasizing the importance of being honest about any lack of skills in the team. If it is a new language or style of coding it can be difficult for people to pick up. You have the background of saying we were never given much time to interact with the consultant or code so there is a gap in our knowledge. If you are willing to learn then ask for time &/or training to help. If you are not then highlight the need for a new team member with a different skill set.
– TafT
Sep 23 '15 at 9:24
 |Â
show 5 more comments
up vote
7
down vote
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.
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
4
I think this is a bad solution, especially for a small business where the cost of a gaffe like this can't just be absorbed.
– Martin Carney
Sep 22 '15 at 21:37
4
ignoring it is a worse solution, see a problem, fix it, or take it to someone who can, is my policy anyway. Especially for a small business which has limited resources. And the sooner the better if you want to keep costs as low as possible in the long run.
– Kilisi
Sep 22 '15 at 21:38
2
@KentAnderson good point, I could have worded it better, I meant it more in terms of 'it is a problem that the boss needs to be aware of'
– Kilisi
Sep 22 '15 at 22:00
suggest improvements |Â
up vote
4
down vote
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? :)
answered Sep 23 '15 at 3:00
guest
43122
suggest improvements |Â
up vote
4
down vote
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).
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
suggest improvements |Â
up vote
2
down vote
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.
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
2
This seems a very intensive solution to the code part of this particular problem, but a nice explanation of refactoring
– Kilisi
Sep 23 '15 at 9:04
When you said: "probably you will need a specialist consultant to do it" I thought that was hilarious. Not sure, was that a joke? Seems that everyone missed it, including you if you did not intend it as one!
– user37746
Apr 13 '16 at 13:21
I was just trying to be polite.
– Jonathan Rosenne
Apr 14 '16 at 15:47
suggest improvements |Â
up vote
1
down vote
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.
answered Sep 23 '15 at 2:39
Keltari
1,83621218
suggest improvements |Â
up vote
-1
down vote
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.
answered Sep 23 '15 at 8:35
MACMAN
991
suggest improvements |Â
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
64
down vote
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.
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
27
Good answer. I'd just like to add that unless the Consultant invented a new language there are resources everywhere for pretty much every language out there. I don't understand why your team wasn't active in thoroughly learning the new language or at least enough to perform simple management and alteration. If I understand it, he was there for years, but at the end of the day he was a Consultant. What did your team/Boss think was going to happen? Color me baffled. I guess count it as a learning experience, do what Kent said, and explain it to your Boss as best you can.
– zfrisch
Sep 22 '15 at 23:09
6
Just realize there isn't a prerequisite for the coder to be super smart to not understand their code. They can be super dumb and people also won't understand the code.
– Nelson
Sep 23 '15 at 5:33
1
For #2, I suggest you also start figuring out how to add tests (or run the existing ones) so that as you modify things, you know if you've broken anything as you come up to speed and make changes. Writing this test infrastructure will also help you learn to understand how it works. This will help you gain confidence with the code base.
– rrauenza
Sep 23 '15 at 6:47
12
I've seen this both ways. Programmers who thought they were super-clever and created an overly-complex mess, and programmers who got slapped for trying to use current techniques in a shop that was stuck in the past. For some shops dependency injection and functional programming look like Martian.
– kevin cline
Sep 23 '15 at 6:52
2
Might be worth emphasizing the importance of being honest about any lack of skills in the team. If it is a new language or style of coding it can be difficult for people to pick up. You have the background of saying we were never given much time to interact with the consultant or code so there is a gap in our knowledge. If you are willing to learn then ask for time &/or training to help. If you are not then highlight the need for a new team member with a different skill set.
– TafT
Sep 23 '15 at 9:24
 |Â
show 5 more comments
up vote
64
down vote
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.
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
27
Good answer. I'd just like to add that unless the Consultant invented a new language there are resources everywhere for pretty much every language out there. I don't understand why your team wasn't active in thoroughly learning the new language or at least enough to perform simple management and alteration. If I understand it, he was there for years, but at the end of the day he was a Consultant. What did your team/Boss think was going to happen? Color me baffled. I guess count it as a learning experience, do what Kent said, and explain it to your Boss as best you can.
– zfrisch
Sep 22 '15 at 23:09
6
Just realize there isn't a prerequisite for the coder to be super smart to not understand their code. They can be super dumb and people also won't understand the code.
– Nelson
Sep 23 '15 at 5:33
1
For #2, I suggest you also start figuring out how to add tests (or run the existing ones) so that as you modify things, you know if you've broken anything as you come up to speed and make changes. Writing this test infrastructure will also help you learn to understand how it works. This will help you gain confidence with the code base.
– rrauenza
Sep 23 '15 at 6:47
12
I've seen this both ways. Programmers who thought they were super-clever and created an overly-complex mess, and programmers who got slapped for trying to use current techniques in a shop that was stuck in the past. For some shops dependency injection and functional programming look like Martian.
– kevin cline
Sep 23 '15 at 6:52
2
Might be worth emphasizing the importance of being honest about any lack of skills in the team. If it is a new language or style of coding it can be difficult for people to pick up. You have the background of saying we were never given much time to interact with the consultant or code so there is a gap in our knowledge. If you are willing to learn then ask for time &/or training to help. If you are not then highlight the need for a new team member with a different skill set.
– TafT
Sep 23 '15 at 9:24
 |Â
show 5 more comments
up vote
64
down vote
up vote
64
down vote
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.
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
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.
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
answered Sep 22 '15 at 21:53
Kent A.
19.2k75575
19.2k75575
27
Good answer. I'd just like to add that unless the Consultant invented a new language there are resources everywhere for pretty much every language out there. I don't understand why your team wasn't active in thoroughly learning the new language or at least enough to perform simple management and alteration. If I understand it, he was there for years, but at the end of the day he was a Consultant. What did your team/Boss think was going to happen? Color me baffled. I guess count it as a learning experience, do what Kent said, and explain it to your Boss as best you can.
– zfrisch
Sep 22 '15 at 23:09
6
Just realize there isn't a prerequisite for the coder to be super smart to not understand their code. They can be super dumb and people also won't understand the code.
– Nelson
Sep 23 '15 at 5:33
1
For #2, I suggest you also start figuring out how to add tests (or run the existing ones) so that as you modify things, you know if you've broken anything as you come up to speed and make changes. Writing this test infrastructure will also help you learn to understand how it works. This will help you gain confidence with the code base.
– rrauenza
Sep 23 '15 at 6:47
12
I've seen this both ways. Programmers who thought they were super-clever and created an overly-complex mess, and programmers who got slapped for trying to use current techniques in a shop that was stuck in the past. For some shops dependency injection and functional programming look like Martian.
– kevin cline
Sep 23 '15 at 6:52
2
Might be worth emphasizing the importance of being honest about any lack of skills in the team. If it is a new language or style of coding it can be difficult for people to pick up. You have the background of saying we were never given much time to interact with the consultant or code so there is a gap in our knowledge. If you are willing to learn then ask for time &/or training to help. If you are not then highlight the need for a new team member with a different skill set.
– TafT
Sep 23 '15 at 9:24
 |Â
show 5 more comments
27
Good answer. I'd just like to add that unless the Consultant invented a new language there are resources everywhere for pretty much every language out there. I don't understand why your team wasn't active in thoroughly learning the new language or at least enough to perform simple management and alteration. If I understand it, he was there for years, but at the end of the day he was a Consultant. What did your team/Boss think was going to happen? Color me baffled. I guess count it as a learning experience, do what Kent said, and explain it to your Boss as best you can.
– zfrisch
Sep 22 '15 at 23:09
6
Just realize there isn't a prerequisite for the coder to be super smart to not understand their code. They can be super dumb and people also won't understand the code.
– Nelson
Sep 23 '15 at 5:33
1
For #2, I suggest you also start figuring out how to add tests (or run the existing ones) so that as you modify things, you know if you've broken anything as you come up to speed and make changes. Writing this test infrastructure will also help you learn to understand how it works. This will help you gain confidence with the code base.
– rrauenza
Sep 23 '15 at 6:47
12
I've seen this both ways. Programmers who thought they were super-clever and created an overly-complex mess, and programmers who got slapped for trying to use current techniques in a shop that was stuck in the past. For some shops dependency injection and functional programming look like Martian.
– kevin cline
Sep 23 '15 at 6:52
2
Might be worth emphasizing the importance of being honest about any lack of skills in the team. If it is a new language or style of coding it can be difficult for people to pick up. You have the background of saying we were never given much time to interact with the consultant or code so there is a gap in our knowledge. If you are willing to learn then ask for time &/or training to help. If you are not then highlight the need for a new team member with a different skill set.
– TafT
Sep 23 '15 at 9:24
27
27
Good answer. I'd just like to add that unless the Consultant invented a new language there are resources everywhere for pretty much every language out there. I don't understand why your team wasn't active in thoroughly learning the new language or at least enough to perform simple management and alteration. If I understand it, he was there for years, but at the end of the day he was a Consultant. What did your team/Boss think was going to happen? Color me baffled. I guess count it as a learning experience, do what Kent said, and explain it to your Boss as best you can.
– zfrisch
Sep 22 '15 at 23:09
Good answer. I'd just like to add that unless the Consultant invented a new language there are resources everywhere for pretty much every language out there. I don't understand why your team wasn't active in thoroughly learning the new language or at least enough to perform simple management and alteration. If I understand it, he was there for years, but at the end of the day he was a Consultant. What did your team/Boss think was going to happen? Color me baffled. I guess count it as a learning experience, do what Kent said, and explain it to your Boss as best you can.
– zfrisch
Sep 22 '15 at 23:09
6
6
Just realize there isn't a prerequisite for the coder to be super smart to not understand their code. They can be super dumb and people also won't understand the code.
– Nelson
Sep 23 '15 at 5:33
Just realize there isn't a prerequisite for the coder to be super smart to not understand their code. They can be super dumb and people also won't understand the code.
– Nelson
Sep 23 '15 at 5:33
1
1
For #2, I suggest you also start figuring out how to add tests (or run the existing ones) so that as you modify things, you know if you've broken anything as you come up to speed and make changes. Writing this test infrastructure will also help you learn to understand how it works. This will help you gain confidence with the code base.
– rrauenza
Sep 23 '15 at 6:47
For #2, I suggest you also start figuring out how to add tests (or run the existing ones) so that as you modify things, you know if you've broken anything as you come up to speed and make changes. Writing this test infrastructure will also help you learn to understand how it works. This will help you gain confidence with the code base.
– rrauenza
Sep 23 '15 at 6:47
12
12
I've seen this both ways. Programmers who thought they were super-clever and created an overly-complex mess, and programmers who got slapped for trying to use current techniques in a shop that was stuck in the past. For some shops dependency injection and functional programming look like Martian.
– kevin cline
Sep 23 '15 at 6:52
I've seen this both ways. Programmers who thought they were super-clever and created an overly-complex mess, and programmers who got slapped for trying to use current techniques in a shop that was stuck in the past. For some shops dependency injection and functional programming look like Martian.
– kevin cline
Sep 23 '15 at 6:52
2
2
Might be worth emphasizing the importance of being honest about any lack of skills in the team. If it is a new language or style of coding it can be difficult for people to pick up. You have the background of saying we were never given much time to interact with the consultant or code so there is a gap in our knowledge. If you are willing to learn then ask for time &/or training to help. If you are not then highlight the need for a new team member with a different skill set.
– TafT
Sep 23 '15 at 9:24
Might be worth emphasizing the importance of being honest about any lack of skills in the team. If it is a new language or style of coding it can be difficult for people to pick up. You have the background of saying we were never given much time to interact with the consultant or code so there is a gap in our knowledge. If you are willing to learn then ask for time &/or training to help. If you are not then highlight the need for a new team member with a different skill set.
– TafT
Sep 23 '15 at 9:24
 |Â
show 5 more comments
up vote
7
down vote
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.
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
4
I think this is a bad solution, especially for a small business where the cost of a gaffe like this can't just be absorbed.
– Martin Carney
Sep 22 '15 at 21:37
4
ignoring it is a worse solution, see a problem, fix it, or take it to someone who can, is my policy anyway. Especially for a small business which has limited resources. And the sooner the better if you want to keep costs as low as possible in the long run.
– Kilisi
Sep 22 '15 at 21:38
2
@KentAnderson good point, I could have worded it better, I meant it more in terms of 'it is a problem that the boss needs to be aware of'
– Kilisi
Sep 22 '15 at 22:00
suggest improvements |Â
up vote
7
down vote
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.
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
4
I think this is a bad solution, especially for a small business where the cost of a gaffe like this can't just be absorbed.
– Martin Carney
Sep 22 '15 at 21:37
4
ignoring it is a worse solution, see a problem, fix it, or take it to someone who can, is my policy anyway. Especially for a small business which has limited resources. And the sooner the better if you want to keep costs as low as possible in the long run.
– Kilisi
Sep 22 '15 at 21:38
2
@KentAnderson good point, I could have worded it better, I meant it more in terms of 'it is a problem that the boss needs to be aware of'
– Kilisi
Sep 22 '15 at 22:00
suggest improvements |Â
up vote
7
down vote
up vote
7
down vote
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.
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
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.
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
edited Sep 22 '15 at 22:03
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
answered Sep 22 '15 at 21:30
Kilisi
94.7k50216377
94.7k50216377
4
I think this is a bad solution, especially for a small business where the cost of a gaffe like this can't just be absorbed.
– Martin Carney
Sep 22 '15 at 21:37
4
ignoring it is a worse solution, see a problem, fix it, or take it to someone who can, is my policy anyway. Especially for a small business which has limited resources. And the sooner the better if you want to keep costs as low as possible in the long run.
– Kilisi
Sep 22 '15 at 21:38
2
@KentAnderson good point, I could have worded it better, I meant it more in terms of 'it is a problem that the boss needs to be aware of'
– Kilisi
Sep 22 '15 at 22:00
suggest improvements |Â
4
I think this is a bad solution, especially for a small business where the cost of a gaffe like this can't just be absorbed.
– Martin Carney
Sep 22 '15 at 21:37
4
ignoring it is a worse solution, see a problem, fix it, or take it to someone who can, is my policy anyway. Especially for a small business which has limited resources. And the sooner the better if you want to keep costs as low as possible in the long run.
– Kilisi
Sep 22 '15 at 21:38
2
@KentAnderson good point, I could have worded it better, I meant it more in terms of 'it is a problem that the boss needs to be aware of'
– Kilisi
Sep 22 '15 at 22:00
4
4
I think this is a bad solution, especially for a small business where the cost of a gaffe like this can't just be absorbed.
– Martin Carney
Sep 22 '15 at 21:37
I think this is a bad solution, especially for a small business where the cost of a gaffe like this can't just be absorbed.
– Martin Carney
Sep 22 '15 at 21:37
4
4
ignoring it is a worse solution, see a problem, fix it, or take it to someone who can, is my policy anyway. Especially for a small business which has limited resources. And the sooner the better if you want to keep costs as low as possible in the long run.
– Kilisi
Sep 22 '15 at 21:38
ignoring it is a worse solution, see a problem, fix it, or take it to someone who can, is my policy anyway. Especially for a small business which has limited resources. And the sooner the better if you want to keep costs as low as possible in the long run.
– Kilisi
Sep 22 '15 at 21:38
2
2
@KentAnderson good point, I could have worded it better, I meant it more in terms of 'it is a problem that the boss needs to be aware of'
– Kilisi
Sep 22 '15 at 22:00
@KentAnderson good point, I could have worded it better, I meant it more in terms of 'it is a problem that the boss needs to be aware of'
– Kilisi
Sep 22 '15 at 22:00
suggest improvements |Â
up vote
4
down vote
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? :)
answered Sep 23 '15 at 3:00
guest
43122
suggest improvements |Â
up vote
4
down vote
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? :)
answered Sep 23 '15 at 3:00
guest
43122
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
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? :)
answered Sep 23 '15 at 3:00
guest
43122
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? :)
answered Sep 23 '15 at 3:00
guest
43122
answered Sep 23 '15 at 3:00
guest
43122
answered Sep 23 '15 at 3:00
guest
43122
answered Sep 23 '15 at 3:00
guest
43122
43122
suggest improvements |Â
suggest improvements |Â
up vote
4
down vote
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).
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
suggest improvements |Â
up vote
4
down vote
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).
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
suggest improvements |Â
up vote
4
down vote
up vote
4
down vote
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).
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
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).
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
edited Sep 23 '15 at 8:58
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
answered Sep 23 '15 at 8:52
gnasher729
70.9k31131222
70.9k31131222
suggest improvements |Â
suggest improvements |Â
up vote
2
down vote
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.
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
2
This seems a very intensive solution to the code part of this particular problem, but a nice explanation of refactoring
– Kilisi
Sep 23 '15 at 9:04
When you said: "probably you will need a specialist consultant to do it" I thought that was hilarious. Not sure, was that a joke? Seems that everyone missed it, including you if you did not intend it as one!
– user37746
Apr 13 '16 at 13:21
I was just trying to be polite.
– Jonathan Rosenne
Apr 14 '16 at 15:47
suggest improvements |Â
up vote
2
down vote
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.
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
2
This seems a very intensive solution to the code part of this particular problem, but a nice explanation of refactoring
– Kilisi
Sep 23 '15 at 9:04
When you said: "probably you will need a specialist consultant to do it" I thought that was hilarious. Not sure, was that a joke? Seems that everyone missed it, including you if you did not intend it as one!
– user37746
Apr 13 '16 at 13:21
I was just trying to be polite.
– Jonathan Rosenne
Apr 14 '16 at 15:47
suggest improvements |Â
up vote
2
down vote
up vote
2
down vote
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.
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
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.
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
answered Sep 23 '15 at 8:17
Jonathan Rosenne
1954
1954
2
This seems a very intensive solution to the code part of this particular problem, but a nice explanation of refactoring
– Kilisi
Sep 23 '15 at 9:04
When you said: "probably you will need a specialist consultant to do it" I thought that was hilarious. Not sure, was that a joke? Seems that everyone missed it, including you if you did not intend it as one!
– user37746
Apr 13 '16 at 13:21
I was just trying to be polite.
– Jonathan Rosenne
Apr 14 '16 at 15:47
suggest improvements |Â
2
This seems a very intensive solution to the code part of this particular problem, but a nice explanation of refactoring
– Kilisi
Sep 23 '15 at 9:04
When you said: "probably you will need a specialist consultant to do it" I thought that was hilarious. Not sure, was that a joke? Seems that everyone missed it, including you if you did not intend it as one!
– user37746
Apr 13 '16 at 13:21
I was just trying to be polite.
– Jonathan Rosenne
Apr 14 '16 at 15:47
2
2
This seems a very intensive solution to the code part of this particular problem, but a nice explanation of refactoring
– Kilisi
Sep 23 '15 at 9:04
This seems a very intensive solution to the code part of this particular problem, but a nice explanation of refactoring
– Kilisi
Sep 23 '15 at 9:04
When you said: "probably you will need a specialist consultant to do it" I thought that was hilarious. Not sure, was that a joke? Seems that everyone missed it, including you if you did not intend it as one!
– user37746
Apr 13 '16 at 13:21
When you said: "probably you will need a specialist consultant to do it" I thought that was hilarious. Not sure, was that a joke? Seems that everyone missed it, including you if you did not intend it as one!
– user37746
Apr 13 '16 at 13:21
I was just trying to be polite.
– Jonathan Rosenne
Apr 14 '16 at 15:47
I was just trying to be polite.
– Jonathan Rosenne
Apr 14 '16 at 15:47
suggest improvements |Â
up vote
1
down vote
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.
answered Sep 23 '15 at 2:39
Keltari
1,83621218
suggest improvements |Â
up vote
1
down vote
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.
answered Sep 23 '15 at 2:39
Keltari
1,83621218
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
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.
answered Sep 23 '15 at 2:39
Keltari
1,83621218
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.
answered Sep 23 '15 at 2:39
Keltari
1,83621218
answered Sep 23 '15 at 2:39
Keltari
1,83621218
answered Sep 23 '15 at 2:39
Keltari
1,83621218
answered Sep 23 '15 at 2:39
Keltari
1,83621218
1,83621218
suggest improvements |Â
suggest improvements |Â
up vote
-1
down vote
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.
answered Sep 23 '15 at 8:35
MACMAN
991
suggest improvements |Â
up vote
-1
down vote
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.
answered Sep 23 '15 at 8:35
MACMAN
991
suggest improvements |Â
up vote
-1
down vote
up vote
-1
down vote
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.
answered Sep 23 '15 at 8:35
MACMAN
991
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.
answered Sep 23 '15 at 8:35
MACMAN
991
answered Sep 23 '15 at 8:35
MACMAN
991
answered Sep 23 '15 at 8:35
MACMAN
991
answered Sep 23 '15 at 8:35
MACMAN
991
991
suggest improvements |Â
suggest improvements |Â
8
This might be a question for programmers.stackexchange.com since it's more about how to decipher code than the workplace. However, can you get the consultant in for a day to explain his code?
– Jane S♦
Sep 22 '15 at 21:19
79
The consultant was overqualified. His advanced ways of programming...This does not sound like an overqualified individual, but rather a lone wolf. A programmer who makes complicated, hard-to-understand code is not a good programmer, no matter how well that code works.– Martin Carney
Sep 22 '15 at 21:20
2
I'm voting to close this question as off-topic because it does not seem to be about navigating the workplace as defined in the help center.
– Lilienthal♦
Sep 22 '15 at 21:42
15
@Lilienthal The asker has an issue with a former employee not providing handover information about a corporate resource - this is very much a workplace issue
– user9158
Sep 23 '15 at 2:51
29
Just a side note, reading and understanding bad code is part of your job as a programmer. Everyone else's code sucks. Even yours from a few weeks ago sucks. All code sucks. Don't ever expect it not to suck.
– corsiKa
Sep 23 '15 at 8:33