Mixing
Is it tactful to get in touch with a previous developer?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
14
down vote
favorite
I'm in the position where I have inherited a highly complex codebase predominantly written by developers who have since separated from the company. I am not aware of what circumstances they separated under. The code in question is several years old, and ideally the company would like to update it to take advantage of new solutions that the old developers largely had to home-brew at the time.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
My question is, is it appropriate to get in contact with this previous developer to get some insights into the code, and if so, what would be a tactful way to do it?
There's no denying that getting that Missing Manual™ would be hugely helpful and really speed development time.
software-industry communication documentation
edited Mar 12 '13 at 17:19
Jim G.
11.8k105373
asked Feb 19 '13 at 16:18
DeaconDesperado
328310
migrated from programmers.stackexchange.com Feb 20 '13 at 11:52
This question came from our site for professionals, academics, and students working within the systems development life cycle.
 |Â
show 3 more comments
up vote
14
down vote
favorite
I'm in the position where I have inherited a highly complex codebase predominantly written by developers who have since separated from the company. I am not aware of what circumstances they separated under. The code in question is several years old, and ideally the company would like to update it to take advantage of new solutions that the old developers largely had to home-brew at the time.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
My question is, is it appropriate to get in contact with this previous developer to get some insights into the code, and if so, what would be a tactful way to do it?
There's no denying that getting that Missing Manual™ would be hugely helpful and really speed development time.
software-industry communication documentation
edited Mar 12 '13 at 17:19
Jim G.
11.8k105373
asked Feb 19 '13 at 16:18
DeaconDesperado
328310
migrated from programmers.stackexchange.com Feb 20 '13 at 11:52
This question came from our site for professionals, academics, and students working within the systems development life cycle.
1
This could apply to any job surely? Not sure it is specific enough to programmers.
– Ozz
Feb 19 '13 at 16:28
@Ozz Certainly, though I would think that for programmers the needs are a little more salient when the code is undocumented and what you inherit is largely black-boxed. I suppose that is the context I raise in the question, ideally we'd all document our code fully, but sometimes buisness/time constraints don't allow.
– DeaconDesperado
Feb 19 '13 at 16:30
3
I think that it's your superiors who should take that decision. Simply because they are aware of the circumstances that lead the previous developper to leave but also because more generally I think it would be beneficial for managment poeple to understand that documentation isn't free.
– lollancf37
Feb 19 '13 at 16:46
2
@DeaconDesperado - substitute "code" for "engine", "chemical reaction", "mathmatical calculation" etc. This is a common problem, and NOT strictly related to programming IMHO.
– Ozz
Feb 19 '13 at 17:05
3
You could just off hand ask the previous developer. His reply will be one of these three: "Sure", "No", or "you'll have to pay me for my time". If it's the latter, escalate to management having him come in as a "consultant" to spend a few days getting you familiar with the obscure parts of the code.
– Earlz
Feb 19 '13 at 19:02
 |Â
show 3 more comments
up vote
14
down vote
favorite
up vote
14
down vote
favorite
I'm in the position where I have inherited a highly complex codebase predominantly written by developers who have since separated from the company. I am not aware of what circumstances they separated under. The code in question is several years old, and ideally the company would like to update it to take advantage of new solutions that the old developers largely had to home-brew at the time.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
My question is, is it appropriate to get in contact with this previous developer to get some insights into the code, and if so, what would be a tactful way to do it?
There's no denying that getting that Missing Manual™ would be hugely helpful and really speed development time.
software-industry communication documentation
edited Mar 12 '13 at 17:19
Jim G.
11.8k105373
asked Feb 19 '13 at 16:18
DeaconDesperado
328310
I'm in the position where I have inherited a highly complex codebase predominantly written by developers who have since separated from the company. I am not aware of what circumstances they separated under. The code in question is several years old, and ideally the company would like to update it to take advantage of new solutions that the old developers largely had to home-brew at the time.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
My question is, is it appropriate to get in contact with this previous developer to get some insights into the code, and if so, what would be a tactful way to do it?
There's no denying that getting that Missing Manual™ would be hugely helpful and really speed development time.
software-industry communication documentation
edited Mar 12 '13 at 17:19
Jim G.
11.8k105373
asked Feb 19 '13 at 16:18
DeaconDesperado
328310
edited Mar 12 '13 at 17:19
Jim G.
11.8k105373
edited Mar 12 '13 at 17:19
Jim G.
11.8k105373
edited Mar 12 '13 at 17:19
Jim G.
11.8k105373
11.8k105373
asked Feb 19 '13 at 16:18
DeaconDesperado
328310
asked Feb 19 '13 at 16:18
DeaconDesperado
328310
asked Feb 19 '13 at 16:18
DeaconDesperado
328310
328310
migrated from programmers.stackexchange.com Feb 20 '13 at 11:52
This question came from our site for professionals, academics, and students working within the systems development life cycle.
migrated from programmers.stackexchange.com Feb 20 '13 at 11:52
This question came from our site for professionals, academics, and students working within the systems development life cycle.
1
This could apply to any job surely? Not sure it is specific enough to programmers.
– Ozz
Feb 19 '13 at 16:28
@Ozz Certainly, though I would think that for programmers the needs are a little more salient when the code is undocumented and what you inherit is largely black-boxed. I suppose that is the context I raise in the question, ideally we'd all document our code fully, but sometimes buisness/time constraints don't allow.
– DeaconDesperado
Feb 19 '13 at 16:30
3
I think that it's your superiors who should take that decision. Simply because they are aware of the circumstances that lead the previous developper to leave but also because more generally I think it would be beneficial for managment poeple to understand that documentation isn't free.
– lollancf37
Feb 19 '13 at 16:46
2
@DeaconDesperado - substitute "code" for "engine", "chemical reaction", "mathmatical calculation" etc. This is a common problem, and NOT strictly related to programming IMHO.
– Ozz
Feb 19 '13 at 17:05
3
You could just off hand ask the previous developer. His reply will be one of these three: "Sure", "No", or "you'll have to pay me for my time". If it's the latter, escalate to management having him come in as a "consultant" to spend a few days getting you familiar with the obscure parts of the code.
– Earlz
Feb 19 '13 at 19:02
 |Â
show 3 more comments
1
This could apply to any job surely? Not sure it is specific enough to programmers.
– Ozz
Feb 19 '13 at 16:28
@Ozz Certainly, though I would think that for programmers the needs are a little more salient when the code is undocumented and what you inherit is largely black-boxed. I suppose that is the context I raise in the question, ideally we'd all document our code fully, but sometimes buisness/time constraints don't allow.
– DeaconDesperado
Feb 19 '13 at 16:30
3
I think that it's your superiors who should take that decision. Simply because they are aware of the circumstances that lead the previous developper to leave but also because more generally I think it would be beneficial for managment poeple to understand that documentation isn't free.
– lollancf37
Feb 19 '13 at 16:46
2
@DeaconDesperado - substitute "code" for "engine", "chemical reaction", "mathmatical calculation" etc. This is a common problem, and NOT strictly related to programming IMHO.
– Ozz
Feb 19 '13 at 17:05
3
You could just off hand ask the previous developer. His reply will be one of these three: "Sure", "No", or "you'll have to pay me for my time". If it's the latter, escalate to management having him come in as a "consultant" to spend a few days getting you familiar with the obscure parts of the code.
– Earlz
Feb 19 '13 at 19:02
1
1
This could apply to any job surely? Not sure it is specific enough to programmers.
– Ozz
Feb 19 '13 at 16:28
This could apply to any job surely? Not sure it is specific enough to programmers.
– Ozz
Feb 19 '13 at 16:28
@Ozz Certainly, though I would think that for programmers the needs are a little more salient when the code is undocumented and what you inherit is largely black-boxed. I suppose that is the context I raise in the question, ideally we'd all document our code fully, but sometimes buisness/time constraints don't allow.
– DeaconDesperado
Feb 19 '13 at 16:30
@Ozz Certainly, though I would think that for programmers the needs are a little more salient when the code is undocumented and what you inherit is largely black-boxed. I suppose that is the context I raise in the question, ideally we'd all document our code fully, but sometimes buisness/time constraints don't allow.
– DeaconDesperado
Feb 19 '13 at 16:30
3
3
I think that it's your superiors who should take that decision. Simply because they are aware of the circumstances that lead the previous developper to leave but also because more generally I think it would be beneficial for managment poeple to understand that documentation isn't free.
– lollancf37
Feb 19 '13 at 16:46
I think that it's your superiors who should take that decision. Simply because they are aware of the circumstances that lead the previous developper to leave but also because more generally I think it would be beneficial for managment poeple to understand that documentation isn't free.
– lollancf37
Feb 19 '13 at 16:46
2
2
@DeaconDesperado - substitute "code" for "engine", "chemical reaction", "mathmatical calculation" etc. This is a common problem, and NOT strictly related to programming IMHO.
– Ozz
Feb 19 '13 at 17:05
@DeaconDesperado - substitute "code" for "engine", "chemical reaction", "mathmatical calculation" etc. This is a common problem, and NOT strictly related to programming IMHO.
– Ozz
Feb 19 '13 at 17:05
3
3
You could just off hand ask the previous developer. His reply will be one of these three: "Sure", "No", or "you'll have to pay me for my time". If it's the latter, escalate to management having him come in as a "consultant" to spend a few days getting you familiar with the obscure parts of the code.
– Earlz
Feb 19 '13 at 19:02
You could just off hand ask the previous developer. His reply will be one of these three: "Sure", "No", or "you'll have to pay me for my time". If it's the latter, escalate to management having him come in as a "consultant" to spend a few days getting you familiar with the obscure parts of the code.
– Earlz
Feb 19 '13 at 19:02
 |Â
show 3 more comments
7 Answers
7
active
oldest
votes
up vote
27
down vote
accepted
Why don't you discuss this with your superiors?
Under normal circumstances, I'd consider providing emergency support for projects worked on at previous employers a standard thing, but since you don't know the circumstances, I would not assume anything - if they parted on friendly terms, you won't have a problem, and if they didn't, you'll have to bite the bullet, but at least you won't create any problems for yourself that way.
Thanks, and this was the first thing that occurred to me. Unfortunately, we're going back far enough that even the superiors in question weren't with the company at the same time.
– DeaconDesperado
Feb 19 '13 at 16:25
16
It doesn't matter that your boss was not their boss, the copmany should decide if the developers should be contacted. What if one of them works for a competitor? What if one of them is in a leagal battle with the company or left under bad terms. This is a decision for your boss.
– HLGEM
Feb 20 '13 at 16:32
add a comment |Â
up vote
13
down vote
If you asked me to help you with code that I had written more than 6 months ago, I'm not sure I would be of much help. The same may well be the case when asking someone else about code they wrote years ago.
Let's say though, that I do remember writing the code in question. If you can ask me a few questions which will take me no more than 15 to 20 minutes to answer off the top of my head, then I'd be happy to help, but any amount of effort beyond that, I would only answer if I was paid for my time.
So, assuming the person you ask remembers the code, and is willing to help, do your best to ask the questions in such a way that they will be easy to answer in a very limited amount of time.
add a comment |Â
up vote
10
down vote
Is it appropriate to get in contact with this previous developer to get some insights into the code...
Sure. Understand that you're making a personal request. Understand also that the previous developer may not remember why things were coded a certain way.
and if so, what would be a tactful way to do it?
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
add a comment |Â
up vote
4
down vote
Is it tactful to get in touch with a previous developer?
Yes, provided that you have the support of your superiors.
Is it prudent to get in touch with a previous developer?
It completely depends.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
Clearly you have sufficient reason to contact the previous developer. But it still helps to ask yourself, "What do we hope to gain from this reacquaintance?"
Here's what I mean:
- Your reacquaintance will likely be short (unless you're trying to persuade the previous developer to rejoin your company).
- In consideration of its brevity, you certainly need to maximize your usage of the time.
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
[From @Gilbert LeBlanc's answer]
In most cases, I would advise against this tactic.
Why?
Because this is a professional reacquaintance; not a social call. You're not trying to wine and dine this previous developer; you're trying to gain important, mission-critical information about your software application (that unfortunately went undocumented for way too long).
With that being said, you need to pay this previous developer an hourly fee for his/her time. That way, you can be completely pragmatic and demand value for this developer's time. This keeps things on the level and avoids any misunderstanding about the purpose of this reacquaintance. In order to maximize your usage of the time, do your due diligence before the meeting so that you can ask specific and targeted questions about the portion of the software application that you don't understand.
edited Apr 13 '17 at 12:48
Community♦
1
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
add a comment |Â
up vote
2
down vote
With adequate monetary compensation for consultation regarding the system, the person in question is bound to indulge your insatiable desire to unravel the all but forgotten secrets of a code from a more civilized era.
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
add a comment |Â
up vote
1
down vote
Whether or not it is appropriate depends on
- How they left the company (fired / quit / still golfs with the CEO)
- The domain you are in, given it's social media it probably isn't going to be mission critical to the company but if it is then you have reason to.
At the end of the day it is up to the developer themselves to decide whether or not they respond to you : they have no obligation to the company they are no longer working at and may only be able to answer one or two emails given that they have probably moved onto something else.
My advice is to really treat this as a last resort.
As an aside I have fielded queries about my code after I left a company but as I was part of a consulting firm at the time I still had the obligation to help out as I still had other members of my company there, I don't know if this applies to you but if it does that is another route you can try.
add a comment |Â
up vote
1
down vote
No, it is almost never appropriate for you to contact someone who now works elsewhere to help you. You would be effectively asking them to do more work for their past employer (your current employer) for free, while working at their new job as well.
This documentation you so badly need now should have been done while they were still present. The management should have made sure that it was.
Now, it may be appropriate for your superiors who have worked with this person to ask them to have some sort of knowledge transfer, and only they can be the judge of whether that is a good idea or not, or on what terms it would happen.
Here is a story to put things in perspective:
This one time I was a contractor on a project that was late, under-resourced, but still very much required by business. At some point I threw my hands up and said: "Guys, wait. What we are doing is unmaintainable. We should really put some effort into making sure that this project can survive if I we all get hit by a bus while carpooling to lunch." And the responce that I got from management was: "We don't care, just kick it out the door ASAP and make sure it works." - so that's what we did. Once it was in production, all the expensive contractors were cut loose before the contract terms were up. Generally speaking, this was a case of dealing with pointy-haired bosses that were clearly trying to squeeze every dollar out of the budget. Now, do I feel bad for the poor guy maintaining that mess? I sure do. Am I going to give an extra hour to the company in question? No way, even if they ask nicely.
So... how do you know you're not that poor guy maintaining that project? You can't ever be sure what the circumstances were when someone left, so the thing to do is not make any assumptions.
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
1
But...if he asks the guy via his social media presence, he could find out.
– Amy Blankenship
Mar 12 '13 at 21:54
He could, and it might work out, but I wouldn't consider it tactful. What happens if the situation with the ex-employee was similar to my story above? Someone is being bugged on google+ by a person they never met asking for help on behalf of a company they want nothing to do with. A little uncool, right? But then a year passes, there is a new poor soul maintaining the same code, they come to this site, assume it's ok and bug the same person again! If this was a common widespread practice, it would be terrible. That's why I don't think it's tactful.
– MrFox
Mar 13 '13 at 13:35
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
27
down vote
accepted
Why don't you discuss this with your superiors?
Under normal circumstances, I'd consider providing emergency support for projects worked on at previous employers a standard thing, but since you don't know the circumstances, I would not assume anything - if they parted on friendly terms, you won't have a problem, and if they didn't, you'll have to bite the bullet, but at least you won't create any problems for yourself that way.
Thanks, and this was the first thing that occurred to me. Unfortunately, we're going back far enough that even the superiors in question weren't with the company at the same time.
– DeaconDesperado
Feb 19 '13 at 16:25
16
It doesn't matter that your boss was not their boss, the copmany should decide if the developers should be contacted. What if one of them works for a competitor? What if one of them is in a leagal battle with the company or left under bad terms. This is a decision for your boss.
– HLGEM
Feb 20 '13 at 16:32
add a comment |Â
up vote
27
down vote
accepted
Why don't you discuss this with your superiors?
Under normal circumstances, I'd consider providing emergency support for projects worked on at previous employers a standard thing, but since you don't know the circumstances, I would not assume anything - if they parted on friendly terms, you won't have a problem, and if they didn't, you'll have to bite the bullet, but at least you won't create any problems for yourself that way.
Thanks, and this was the first thing that occurred to me. Unfortunately, we're going back far enough that even the superiors in question weren't with the company at the same time.
– DeaconDesperado
Feb 19 '13 at 16:25
16
It doesn't matter that your boss was not their boss, the copmany should decide if the developers should be contacted. What if one of them works for a competitor? What if one of them is in a leagal battle with the company or left under bad terms. This is a decision for your boss.
– HLGEM
Feb 20 '13 at 16:32
add a comment |Â
up vote
27
down vote
accepted
up vote
27
down vote
accepted
Why don't you discuss this with your superiors?
Under normal circumstances, I'd consider providing emergency support for projects worked on at previous employers a standard thing, but since you don't know the circumstances, I would not assume anything - if they parted on friendly terms, you won't have a problem, and if they didn't, you'll have to bite the bullet, but at least you won't create any problems for yourself that way.
Why don't you discuss this with your superiors?
Under normal circumstances, I'd consider providing emergency support for projects worked on at previous employers a standard thing, but since you don't know the circumstances, I would not assume anything - if they parted on friendly terms, you won't have a problem, and if they didn't, you'll have to bite the bullet, but at least you won't create any problems for yourself that way.
answered Feb 19 '13 at 16:22
tdammers
Thanks, and this was the first thing that occurred to me. Unfortunately, we're going back far enough that even the superiors in question weren't with the company at the same time.
– DeaconDesperado
Feb 19 '13 at 16:25
16
It doesn't matter that your boss was not their boss, the copmany should decide if the developers should be contacted. What if one of them works for a competitor? What if one of them is in a leagal battle with the company or left under bad terms. This is a decision for your boss.
– HLGEM
Feb 20 '13 at 16:32
add a comment |Â
Thanks, and this was the first thing that occurred to me. Unfortunately, we're going back far enough that even the superiors in question weren't with the company at the same time.
– DeaconDesperado
Feb 19 '13 at 16:25
16
It doesn't matter that your boss was not their boss, the copmany should decide if the developers should be contacted. What if one of them works for a competitor? What if one of them is in a leagal battle with the company or left under bad terms. This is a decision for your boss.
– HLGEM
Feb 20 '13 at 16:32
Thanks, and this was the first thing that occurred to me. Unfortunately, we're going back far enough that even the superiors in question weren't with the company at the same time.
– DeaconDesperado
Feb 19 '13 at 16:25
Thanks, and this was the first thing that occurred to me. Unfortunately, we're going back far enough that even the superiors in question weren't with the company at the same time.
– DeaconDesperado
Feb 19 '13 at 16:25
16
16
It doesn't matter that your boss was not their boss, the copmany should decide if the developers should be contacted. What if one of them works for a competitor? What if one of them is in a leagal battle with the company or left under bad terms. This is a decision for your boss.
– HLGEM
Feb 20 '13 at 16:32
It doesn't matter that your boss was not their boss, the copmany should decide if the developers should be contacted. What if one of them works for a competitor? What if one of them is in a leagal battle with the company or left under bad terms. This is a decision for your boss.
– HLGEM
Feb 20 '13 at 16:32
add a comment |Â
up vote
13
down vote
If you asked me to help you with code that I had written more than 6 months ago, I'm not sure I would be of much help. The same may well be the case when asking someone else about code they wrote years ago.
Let's say though, that I do remember writing the code in question. If you can ask me a few questions which will take me no more than 15 to 20 minutes to answer off the top of my head, then I'd be happy to help, but any amount of effort beyond that, I would only answer if I was paid for my time.
So, assuming the person you ask remembers the code, and is willing to help, do your best to ask the questions in such a way that they will be easy to answer in a very limited amount of time.
add a comment |Â
up vote
13
down vote
If you asked me to help you with code that I had written more than 6 months ago, I'm not sure I would be of much help. The same may well be the case when asking someone else about code they wrote years ago.
Let's say though, that I do remember writing the code in question. If you can ask me a few questions which will take me no more than 15 to 20 minutes to answer off the top of my head, then I'd be happy to help, but any amount of effort beyond that, I would only answer if I was paid for my time.
So, assuming the person you ask remembers the code, and is willing to help, do your best to ask the questions in such a way that they will be easy to answer in a very limited amount of time.
add a comment |Â
up vote
13
down vote
up vote
13
down vote
If you asked me to help you with code that I had written more than 6 months ago, I'm not sure I would be of much help. The same may well be the case when asking someone else about code they wrote years ago.
Let's say though, that I do remember writing the code in question. If you can ask me a few questions which will take me no more than 15 to 20 minutes to answer off the top of my head, then I'd be happy to help, but any amount of effort beyond that, I would only answer if I was paid for my time.
So, assuming the person you ask remembers the code, and is willing to help, do your best to ask the questions in such a way that they will be easy to answer in a very limited amount of time.
If you asked me to help you with code that I had written more than 6 months ago, I'm not sure I would be of much help. The same may well be the case when asking someone else about code they wrote years ago.
Let's say though, that I do remember writing the code in question. If you can ask me a few questions which will take me no more than 15 to 20 minutes to answer off the top of my head, then I'd be happy to help, but any amount of effort beyond that, I would only answer if I was paid for my time.
So, assuming the person you ask remembers the code, and is willing to help, do your best to ask the questions in such a way that they will be easy to answer in a very limited amount of time.
answered Feb 19 '13 at 16:31
Tad Donaghe
add a comment |Â
add a comment |Â
up vote
10
down vote
Is it appropriate to get in contact with this previous developer to get some insights into the code...
Sure. Understand that you're making a personal request. Understand also that the previous developer may not remember why things were coded a certain way.
and if so, what would be a tactful way to do it?
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
add a comment |Â
up vote
10
down vote
Is it appropriate to get in contact with this previous developer to get some insights into the code...
Sure. Understand that you're making a personal request. Understand also that the previous developer may not remember why things were coded a certain way.
and if so, what would be a tactful way to do it?
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
add a comment |Â
up vote
10
down vote
up vote
10
down vote
Is it appropriate to get in contact with this previous developer to get some insights into the code...
Sure. Understand that you're making a personal request. Understand also that the previous developer may not remember why things were coded a certain way.
and if so, what would be a tactful way to do it?
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
Is it appropriate to get in contact with this previous developer to get some insights into the code...
Sure. Understand that you're making a personal request. Understand also that the previous developer may not remember why things were coded a certain way.
and if so, what would be a tactful way to do it?
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
answered Feb 19 '13 at 16:22
Gilbert Le Blanc
20914
20914
add a comment |Â
add a comment |Â
up vote
4
down vote
Is it tactful to get in touch with a previous developer?
Yes, provided that you have the support of your superiors.
Is it prudent to get in touch with a previous developer?
It completely depends.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
Clearly you have sufficient reason to contact the previous developer. But it still helps to ask yourself, "What do we hope to gain from this reacquaintance?"
Here's what I mean:
- Your reacquaintance will likely be short (unless you're trying to persuade the previous developer to rejoin your company).
- In consideration of its brevity, you certainly need to maximize your usage of the time.
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
[From @Gilbert LeBlanc's answer]
In most cases, I would advise against this tactic.
Why?
Because this is a professional reacquaintance; not a social call. You're not trying to wine and dine this previous developer; you're trying to gain important, mission-critical information about your software application (that unfortunately went undocumented for way too long).
With that being said, you need to pay this previous developer an hourly fee for his/her time. That way, you can be completely pragmatic and demand value for this developer's time. This keeps things on the level and avoids any misunderstanding about the purpose of this reacquaintance. In order to maximize your usage of the time, do your due diligence before the meeting so that you can ask specific and targeted questions about the portion of the software application that you don't understand.
edited Apr 13 '17 at 12:48
Community♦
1
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
add a comment |Â
up vote
4
down vote
Is it tactful to get in touch with a previous developer?
Yes, provided that you have the support of your superiors.
Is it prudent to get in touch with a previous developer?
It completely depends.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
Clearly you have sufficient reason to contact the previous developer. But it still helps to ask yourself, "What do we hope to gain from this reacquaintance?"
Here's what I mean:
- Your reacquaintance will likely be short (unless you're trying to persuade the previous developer to rejoin your company).
- In consideration of its brevity, you certainly need to maximize your usage of the time.
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
[From @Gilbert LeBlanc's answer]
In most cases, I would advise against this tactic.
Why?
Because this is a professional reacquaintance; not a social call. You're not trying to wine and dine this previous developer; you're trying to gain important, mission-critical information about your software application (that unfortunately went undocumented for way too long).
With that being said, you need to pay this previous developer an hourly fee for his/her time. That way, you can be completely pragmatic and demand value for this developer's time. This keeps things on the level and avoids any misunderstanding about the purpose of this reacquaintance. In order to maximize your usage of the time, do your due diligence before the meeting so that you can ask specific and targeted questions about the portion of the software application that you don't understand.
edited Apr 13 '17 at 12:48
Community♦
1
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
add a comment |Â
up vote
4
down vote
up vote
4
down vote
Is it tactful to get in touch with a previous developer?
Yes, provided that you have the support of your superiors.
Is it prudent to get in touch with a previous developer?
It completely depends.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
Clearly you have sufficient reason to contact the previous developer. But it still helps to ask yourself, "What do we hope to gain from this reacquaintance?"
Here's what I mean:
- Your reacquaintance will likely be short (unless you're trying to persuade the previous developer to rejoin your company).
- In consideration of its brevity, you certainly need to maximize your usage of the time.
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
[From @Gilbert LeBlanc's answer]
In most cases, I would advise against this tactic.
Why?
Because this is a professional reacquaintance; not a social call. You're not trying to wine and dine this previous developer; you're trying to gain important, mission-critical information about your software application (that unfortunately went undocumented for way too long).
With that being said, you need to pay this previous developer an hourly fee for his/her time. That way, you can be completely pragmatic and demand value for this developer's time. This keeps things on the level and avoids any misunderstanding about the purpose of this reacquaintance. In order to maximize your usage of the time, do your due diligence before the meeting so that you can ask specific and targeted questions about the portion of the software application that you don't understand.
edited Apr 13 '17 at 12:48
Community♦
1
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
Is it tactful to get in touch with a previous developer?
Yes, provided that you have the support of your superiors.
Is it prudent to get in touch with a previous developer?
It completely depends.
The code is mostly uncommented, and certain parts are wholly undocumented. The developer in question maintains a pretty sizable social media presence and is still involved with software engineering at other companies.
Clearly you have sufficient reason to contact the previous developer. But it still helps to ask yourself, "What do we hope to gain from this reacquaintance?"
Here's what I mean:
- Your reacquaintance will likely be short (unless you're trying to persuade the previous developer to rejoin your company).
- In consideration of its brevity, you certainly need to maximize your usage of the time.
Invite him out to dinner, or some equivalent that shows you're appreciative of his time. After the fact, send him a gift card with a thank you note.
[From @Gilbert LeBlanc's answer]
In most cases, I would advise against this tactic.
Why?
Because this is a professional reacquaintance; not a social call. You're not trying to wine and dine this previous developer; you're trying to gain important, mission-critical information about your software application (that unfortunately went undocumented for way too long).
With that being said, you need to pay this previous developer an hourly fee for his/her time. That way, you can be completely pragmatic and demand value for this developer's time. This keeps things on the level and avoids any misunderstanding about the purpose of this reacquaintance. In order to maximize your usage of the time, do your due diligence before the meeting so that you can ask specific and targeted questions about the portion of the software application that you don't understand.
edited Apr 13 '17 at 12:48
Community♦
1
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
1
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
answered Mar 12 '13 at 17:10
Jim G.
11.8k105373
11.8k105373
add a comment |Â
add a comment |Â
up vote
2
down vote
With adequate monetary compensation for consultation regarding the system, the person in question is bound to indulge your insatiable desire to unravel the all but forgotten secrets of a code from a more civilized era.
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
add a comment |Â
up vote
2
down vote
With adequate monetary compensation for consultation regarding the system, the person in question is bound to indulge your insatiable desire to unravel the all but forgotten secrets of a code from a more civilized era.
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
add a comment |Â
up vote
2
down vote
up vote
2
down vote
With adequate monetary compensation for consultation regarding the system, the person in question is bound to indulge your insatiable desire to unravel the all but forgotten secrets of a code from a more civilized era.
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
With adequate monetary compensation for consultation regarding the system, the person in question is bound to indulge your insatiable desire to unravel the all but forgotten secrets of a code from a more civilized era.
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
answered Mar 13 '13 at 12:02
Juha Untinen
1,5261018
1,5261018
add a comment |Â
add a comment |Â
up vote
1
down vote
Whether or not it is appropriate depends on
- How they left the company (fired / quit / still golfs with the CEO)
- The domain you are in, given it's social media it probably isn't going to be mission critical to the company but if it is then you have reason to.
At the end of the day it is up to the developer themselves to decide whether or not they respond to you : they have no obligation to the company they are no longer working at and may only be able to answer one or two emails given that they have probably moved onto something else.
My advice is to really treat this as a last resort.
As an aside I have fielded queries about my code after I left a company but as I was part of a consulting firm at the time I still had the obligation to help out as I still had other members of my company there, I don't know if this applies to you but if it does that is another route you can try.
add a comment |Â
up vote
1
down vote
Whether or not it is appropriate depends on
- How they left the company (fired / quit / still golfs with the CEO)
- The domain you are in, given it's social media it probably isn't going to be mission critical to the company but if it is then you have reason to.
At the end of the day it is up to the developer themselves to decide whether or not they respond to you : they have no obligation to the company they are no longer working at and may only be able to answer one or two emails given that they have probably moved onto something else.
My advice is to really treat this as a last resort.
As an aside I have fielded queries about my code after I left a company but as I was part of a consulting firm at the time I still had the obligation to help out as I still had other members of my company there, I don't know if this applies to you but if it does that is another route you can try.
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Whether or not it is appropriate depends on
- How they left the company (fired / quit / still golfs with the CEO)
- The domain you are in, given it's social media it probably isn't going to be mission critical to the company but if it is then you have reason to.
At the end of the day it is up to the developer themselves to decide whether or not they respond to you : they have no obligation to the company they are no longer working at and may only be able to answer one or two emails given that they have probably moved onto something else.
My advice is to really treat this as a last resort.
As an aside I have fielded queries about my code after I left a company but as I was part of a consulting firm at the time I still had the obligation to help out as I still had other members of my company there, I don't know if this applies to you but if it does that is another route you can try.
Whether or not it is appropriate depends on
- How they left the company (fired / quit / still golfs with the CEO)
- The domain you are in, given it's social media it probably isn't going to be mission critical to the company but if it is then you have reason to.
At the end of the day it is up to the developer themselves to decide whether or not they respond to you : they have no obligation to the company they are no longer working at and may only be able to answer one or two emails given that they have probably moved onto something else.
My advice is to really treat this as a last resort.
As an aside I have fielded queries about my code after I left a company but as I was part of a consulting firm at the time I still had the obligation to help out as I still had other members of my company there, I don't know if this applies to you but if it does that is another route you can try.
answered Feb 19 '13 at 19:18
ahjmorton
add a comment |Â
add a comment |Â
up vote
1
down vote
No, it is almost never appropriate for you to contact someone who now works elsewhere to help you. You would be effectively asking them to do more work for their past employer (your current employer) for free, while working at their new job as well.
This documentation you so badly need now should have been done while they were still present. The management should have made sure that it was.
Now, it may be appropriate for your superiors who have worked with this person to ask them to have some sort of knowledge transfer, and only they can be the judge of whether that is a good idea or not, or on what terms it would happen.
Here is a story to put things in perspective:
This one time I was a contractor on a project that was late, under-resourced, but still very much required by business. At some point I threw my hands up and said: "Guys, wait. What we are doing is unmaintainable. We should really put some effort into making sure that this project can survive if I we all get hit by a bus while carpooling to lunch." And the responce that I got from management was: "We don't care, just kick it out the door ASAP and make sure it works." - so that's what we did. Once it was in production, all the expensive contractors were cut loose before the contract terms were up. Generally speaking, this was a case of dealing with pointy-haired bosses that were clearly trying to squeeze every dollar out of the budget. Now, do I feel bad for the poor guy maintaining that mess? I sure do. Am I going to give an extra hour to the company in question? No way, even if they ask nicely.
So... how do you know you're not that poor guy maintaining that project? You can't ever be sure what the circumstances were when someone left, so the thing to do is not make any assumptions.
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
1
But...if he asks the guy via his social media presence, he could find out.
– Amy Blankenship
Mar 12 '13 at 21:54
He could, and it might work out, but I wouldn't consider it tactful. What happens if the situation with the ex-employee was similar to my story above? Someone is being bugged on google+ by a person they never met asking for help on behalf of a company they want nothing to do with. A little uncool, right? But then a year passes, there is a new poor soul maintaining the same code, they come to this site, assume it's ok and bug the same person again! If this was a common widespread practice, it would be terrible. That's why I don't think it's tactful.
– MrFox
Mar 13 '13 at 13:35
add a comment |Â
up vote
1
down vote
No, it is almost never appropriate for you to contact someone who now works elsewhere to help you. You would be effectively asking them to do more work for their past employer (your current employer) for free, while working at their new job as well.
This documentation you so badly need now should have been done while they were still present. The management should have made sure that it was.
Now, it may be appropriate for your superiors who have worked with this person to ask them to have some sort of knowledge transfer, and only they can be the judge of whether that is a good idea or not, or on what terms it would happen.
Here is a story to put things in perspective:
This one time I was a contractor on a project that was late, under-resourced, but still very much required by business. At some point I threw my hands up and said: "Guys, wait. What we are doing is unmaintainable. We should really put some effort into making sure that this project can survive if I we all get hit by a bus while carpooling to lunch." And the responce that I got from management was: "We don't care, just kick it out the door ASAP and make sure it works." - so that's what we did. Once it was in production, all the expensive contractors were cut loose before the contract terms were up. Generally speaking, this was a case of dealing with pointy-haired bosses that were clearly trying to squeeze every dollar out of the budget. Now, do I feel bad for the poor guy maintaining that mess? I sure do. Am I going to give an extra hour to the company in question? No way, even if they ask nicely.
So... how do you know you're not that poor guy maintaining that project? You can't ever be sure what the circumstances were when someone left, so the thing to do is not make any assumptions.
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
1
But...if he asks the guy via his social media presence, he could find out.
– Amy Blankenship
Mar 12 '13 at 21:54
He could, and it might work out, but I wouldn't consider it tactful. What happens if the situation with the ex-employee was similar to my story above? Someone is being bugged on google+ by a person they never met asking for help on behalf of a company they want nothing to do with. A little uncool, right? But then a year passes, there is a new poor soul maintaining the same code, they come to this site, assume it's ok and bug the same person again! If this was a common widespread practice, it would be terrible. That's why I don't think it's tactful.
– MrFox
Mar 13 '13 at 13:35
add a comment |Â
up vote
1
down vote
up vote
1
down vote
No, it is almost never appropriate for you to contact someone who now works elsewhere to help you. You would be effectively asking them to do more work for their past employer (your current employer) for free, while working at their new job as well.
This documentation you so badly need now should have been done while they were still present. The management should have made sure that it was.
Now, it may be appropriate for your superiors who have worked with this person to ask them to have some sort of knowledge transfer, and only they can be the judge of whether that is a good idea or not, or on what terms it would happen.
Here is a story to put things in perspective:
This one time I was a contractor on a project that was late, under-resourced, but still very much required by business. At some point I threw my hands up and said: "Guys, wait. What we are doing is unmaintainable. We should really put some effort into making sure that this project can survive if I we all get hit by a bus while carpooling to lunch." And the responce that I got from management was: "We don't care, just kick it out the door ASAP and make sure it works." - so that's what we did. Once it was in production, all the expensive contractors were cut loose before the contract terms were up. Generally speaking, this was a case of dealing with pointy-haired bosses that were clearly trying to squeeze every dollar out of the budget. Now, do I feel bad for the poor guy maintaining that mess? I sure do. Am I going to give an extra hour to the company in question? No way, even if they ask nicely.
So... how do you know you're not that poor guy maintaining that project? You can't ever be sure what the circumstances were when someone left, so the thing to do is not make any assumptions.
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
No, it is almost never appropriate for you to contact someone who now works elsewhere to help you. You would be effectively asking them to do more work for their past employer (your current employer) for free, while working at their new job as well.
This documentation you so badly need now should have been done while they were still present. The management should have made sure that it was.
Now, it may be appropriate for your superiors who have worked with this person to ask them to have some sort of knowledge transfer, and only they can be the judge of whether that is a good idea or not, or on what terms it would happen.
Here is a story to put things in perspective:
This one time I was a contractor on a project that was late, under-resourced, but still very much required by business. At some point I threw my hands up and said: "Guys, wait. What we are doing is unmaintainable. We should really put some effort into making sure that this project can survive if I we all get hit by a bus while carpooling to lunch." And the responce that I got from management was: "We don't care, just kick it out the door ASAP and make sure it works." - so that's what we did. Once it was in production, all the expensive contractors were cut loose before the contract terms were up. Generally speaking, this was a case of dealing with pointy-haired bosses that were clearly trying to squeeze every dollar out of the budget. Now, do I feel bad for the poor guy maintaining that mess? I sure do. Am I going to give an extra hour to the company in question? No way, even if they ask nicely.
So... how do you know you're not that poor guy maintaining that project? You can't ever be sure what the circumstances were when someone left, so the thing to do is not make any assumptions.
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
answered Mar 12 '13 at 21:01
MrFox
11.8k33857
11.8k33857
1
But...if he asks the guy via his social media presence, he could find out.
– Amy Blankenship
Mar 12 '13 at 21:54
He could, and it might work out, but I wouldn't consider it tactful. What happens if the situation with the ex-employee was similar to my story above? Someone is being bugged on google+ by a person they never met asking for help on behalf of a company they want nothing to do with. A little uncool, right? But then a year passes, there is a new poor soul maintaining the same code, they come to this site, assume it's ok and bug the same person again! If this was a common widespread practice, it would be terrible. That's why I don't think it's tactful.
– MrFox
Mar 13 '13 at 13:35
add a comment |Â
1
But...if he asks the guy via his social media presence, he could find out.
– Amy Blankenship
Mar 12 '13 at 21:54
He could, and it might work out, but I wouldn't consider it tactful. What happens if the situation with the ex-employee was similar to my story above? Someone is being bugged on google+ by a person they never met asking for help on behalf of a company they want nothing to do with. A little uncool, right? But then a year passes, there is a new poor soul maintaining the same code, they come to this site, assume it's ok and bug the same person again! If this was a common widespread practice, it would be terrible. That's why I don't think it's tactful.
– MrFox
Mar 13 '13 at 13:35
1
1
But...if he asks the guy via his social media presence, he could find out.
– Amy Blankenship
Mar 12 '13 at 21:54
But...if he asks the guy via his social media presence, he could find out.
– Amy Blankenship
Mar 12 '13 at 21:54
He could, and it might work out, but I wouldn't consider it tactful. What happens if the situation with the ex-employee was similar to my story above? Someone is being bugged on google+ by a person they never met asking for help on behalf of a company they want nothing to do with. A little uncool, right? But then a year passes, there is a new poor soul maintaining the same code, they come to this site, assume it's ok and bug the same person again! If this was a common widespread practice, it would be terrible. That's why I don't think it's tactful.
– MrFox
Mar 13 '13 at 13:35
He could, and it might work out, but I wouldn't consider it tactful. What happens if the situation with the ex-employee was similar to my story above? Someone is being bugged on google+ by a person they never met asking for help on behalf of a company they want nothing to do with. A little uncool, right? But then a year passes, there is a new poor soul maintaining the same code, they come to this site, assume it's ok and bug the same person again! If this was a common widespread practice, it would be terrible. That's why I don't think it's tactful.
– MrFox
Mar 13 '13 at 13:35
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f9785%2fis-it-tactful-to-get-in-touch-with-a-previous-developer%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
This could apply to any job surely? Not sure it is specific enough to programmers.
– Ozz
Feb 19 '13 at 16:28
@Ozz Certainly, though I would think that for programmers the needs are a little more salient when the code is undocumented and what you inherit is largely black-boxed. I suppose that is the context I raise in the question, ideally we'd all document our code fully, but sometimes buisness/time constraints don't allow.
– DeaconDesperado
Feb 19 '13 at 16:30
3
I think that it's your superiors who should take that decision. Simply because they are aware of the circumstances that lead the previous developper to leave but also because more generally I think it would be beneficial for managment poeple to understand that documentation isn't free.
– lollancf37
Feb 19 '13 at 16:46
2
@DeaconDesperado - substitute "code" for "engine", "chemical reaction", "mathmatical calculation" etc. This is a common problem, and NOT strictly related to programming IMHO.
– Ozz
Feb 19 '13 at 17:05
3
You could just off hand ask the previous developer. His reply will be one of these three: "Sure", "No", or "you'll have to pay me for my time". If it's the latter, escalate to management having him come in as a "consultant" to spend a few days getting you familiar with the obscure parts of the code.
– Earlz
Feb 19 '13 at 19:02