Is it tactful to get in touch with a previous developer?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.