16

This is not my first time coming in after a previous contractor got half way through production of an application, only to have him leave suddenly. Before I get in a rut of doing it the best way I see, I would like some input on some best practices on coming into a situation like this again.

Of course, the fist thing is to find out what the intended goal of the application was/is.

When do you tell your boss that the previous programmer had no idea what she/he was doing and bailed before he/she was found out?

What are the steps you take to establish confidence in your new boss that you can do the job?

To follow up on my personal situation, the contract is finished. I was not the Anne Sullivan for the previous Helen Keller programmer. I finished the first application, in a working manner. There was a glitch that I could not fix, created by the previous programmer, but it otherwise worked. The second program, I started from the beginning, and restarted after a design request change, and restarted a third time after a higher up wanted something completely different. All I can say is, "I am glad that project is over."

| improve this question | | | | |
  • First thing I would do would be the determine why the work had been done the way it had been. Did the previous programmer really not know what they were doing or were they doing something in a specific way to accomplish a specific goal? After that if I determined that a new approach were called for I would start with a presentation to the boss with clear reasons why the previous approach was the wrong one and what benefits will come from yours. – JasonJ Jun 29 '16 at 17:43
  • 19
    Don't forget to publicly and repeateadly blame the replaced computer programmer for the bad program structure and compare his/her coding skills to those of a cow in an uninspired day. It might seem not fair, but it is what the tradition mandates in these cases! :-p – SJuan76 Jun 29 '16 at 21:14
  • 1
    Try also programmers.stackexchange.com – tymtam Jun 29 '16 at 22:22
  • 1
    To follow up on my personal situation, the contract is finished. I was not the Anne Sullivan for the previous Helen Keller programmer. I finished the first application, in a working manner. There was a glitch that I could not fix, created by the previous programmer, but it otherwise worked. The second program, I started from the beginning, and restarted after a design request change, and restarted a third time after a higher up wanted something completely different. All I can say is, "I am glad that project is over." – Sensii Miller Oct 26 '16 at 18:12
  • Please edit your follow-up into the question. Comments will get automatically purged and the update will just disappear. – Nelson Oct 27 '16 at 1:48
37

I just had a very interesting discussion at a seminar last week about this very issue. I added a few things to my checklist for taking contract jobs as a result:

  • Step 1: Ask to talk with the previous developer. If he is not available, ask why. It is far more likely the contractor fired the client than the other way around. That's something you'd want to know.

  • Step 2: If the previous developer is unavailable due to anything other than death or alien abduction, seriously rethink taking on the project. I'm not saying this is always the case, but my experience in "taking over" abandoned projects has been mixed. Only one was because of a developer seriously out of his depth. Most have been because of political issues, prior mismanagement, and divergent perceptions of the "goal" of the project.

  • Step 3: Ask for the previous 3 months' communication with the project owner and the developer in order to get into context. If you're lucky, it's in JIRA or something similar. If it's not been well-managed, you're going to get a pile of emails.
  • Step 4: Then do a cursory review of the business requirements, and then look through the project and document the architecture. Read the communications, then go back and look at the project again to see if you can start matching all these elements up.
  • Step 5: By this time, you should have about 20 questions for the developer, so see if you can get half an hour of their time for a conference call. The other developer may bill for this time, so keep it pithy.
  • Step 6: Put together a report of the requirements, what's been done on each (break it down to development, testing, and user acceptance, at least), and what remains to be done. Adding scalability and "brittleness" evaluations of what's been completed is good, too, if you have time.

At this point, you should have a meeting with your boss and break this down. Then you should ask for priorities. He's going to push you on resource/time requirements at this meeting, but you're still not in deep enough to say with certainty. Be sure your boss understands this.

Best I can do for a "Generic - Get Started" procedure.

Worth reading - some humor, some truth: http://wikibon.org/wiki/v/Prepare_three_envelopes

| improve this answer | | | | |
  • 2
    +1, for "alien abduction" alone. Seriously, good answer. I particularly like the part about finding out as much as possible about the previous programmer. It's true, if there were issues during their work, you'll want to know about it - and there are always issues, political or otherwise. – sleske Oct 26 '16 at 6:48
  • It is answers like this that make this site great. Thank you. – rath Oct 26 '16 at 15:02
  • I did try to contact the old programmer. He has moved on to a bigger, better project. Coincidentally, we were co-workers at another firm prior to this assignment, but we never met, we worked in different departments. He refused to talk to me about this project. I understand why. – Sensii Miller Oct 26 '16 at 18:15
7

Gather up any existing documentation and read it

Do a quick code review (like 1-2 days)

Don't say the program is trash and you have to start over even if you do. They don't want to hear that. There has to something you can salvage. These modules seem solid, these need a lot of work, and these need to start over.

Write up requirements and design if there is not one

If they bitch a lot about the last guy and don't really know what they want then be prepared to be the last guy they bitch about.

| improve this answer | | | | |
6

My take on this is slightly different, in that I would give more weight to determining the requirements than most of the other responders. There can be any number of reasons that a contractor quit suddenly, but all too often the reason that a "programmer had no idea what she/he was doing" is because the stakeholders had no idea what they wanted. It's very important to go over the requirements in detail, and ask any questions that you might have about them. If you get resistance to this, that's a big red flag, because you'll have no idea what you're doing, either, and you'll be a convenient scapegoat for everyone.

Back in the 90's, I was gotten rid of as scapegoat number two in a situation like this. Several months later, I was teaching a class in the same town, and a fellow from the company that had kicked me out was in it. As it turned out, they had just gotten rid of scapegoat number three, who had taken over from me (starting from scratch, I might add), put one of their own employees on the job, and made sure he had enough training to become scapegoat number four. In other words, the problem was with these contractors, dang the lot of them as useless, let's train up one of our own and get the job done right. The real problem was that there was a manager who would go to board meetings twice a week and come back with changed requirements for the software we were writing. To be fair, she wasn't an IT manager, but when I tried to push back and say that we needed to stop changing the requirements every board meeting, she would just shrug and say we have to do what the board wants. When I mentioned that it was pretty clear that they didn't know what they wanted, since they kept changing their minds, and offered to meet with them directly, I set myself firmly on the path to scapegoat number two. (Nowadays I would try a little harder to educate the manager about the consequences to deliverability of changing requirements before taking this approach.)

If your predecessor was obviously incompetent, you might mention something as soon as you can effectively demonstrate the truth of that assertion. If the code is riddled with architectural problems, that's a liability to the success of the project and management will need to know about it. But it will be your job to convince them, so again make sure that you can.

| improve this answer | | | | |
2

Having had a very complicated customer in the past, I would reenforce the predicament of talking with the previous developer. More often than not, the previous actor may have fired the client.

I was unfortunate enough to pick up a very bad customer, that mishandled the contractors, wasted their time, changed the requirements, and after having the work mostly done dispensed the contractor, and did not want maintenance...and let the solution rot as long as it could, and restarted the cycle anew from ground 0 with another contractor - and before trying a new contractor, they called you with another magnificent job...which you would refuse, of course.

Document all steps by writing/email, including requirements, negotiation, and paid values.

| improve this answer | | | | |
  • Some folks just have money to burn on maintaining their illusions. :) – BobRodes Jun 30 '16 at 18:19
  • @BobRodes - those clients can be OK for a while. It's the ones that have the illusion of having money to burn that cause grief! – Wesley Long Jun 30 '16 at 18:24
  • The tactic of this one in particular is paying you the minimum possible, and milking the work for as long as they can. – Rui F Ribeiro Jun 30 '16 at 18:25
  • 1
    @RuiFRibeiro Yeah, the old "he who has the gold makes the rules" illusion. – BobRodes Jun 30 '16 at 18:53
  • 1
    Bob, they have to show you the gold... in this case they seem to be more they wish they could afford to pay you... making it "if wishes were horses beggars would ride". – Móż Oct 26 '16 at 3:30
1

As a contractor it's in your best interests to start from scratch, so before I even look at the work done and contemplate taking a job I push that angle. And I'll make my first general quote based on that assumption. And in most cases it would be a prerequisite to me taking it on.

I'll only take over if there is no choice because deadlines are looming and I can see at least a partially working job has been done. But I've only really done this once and that was more of a service for an existing client, rather than a new job. What I will do is take the structure of a job and work off that if it has already been thoroughly hashed out. That actually saves a LOT of effort. But working and troubleshooting someone else's code can be too much of a headache particularly if it's not well commented.

Professionals do not quit suddenly partway during a project unless they are having serious issues either with the work or the client, and the sort of person who would do that is not beyond messing up the code on the way out (unless it was a health issue or sudden death).

So if you do take these sorts of jobs you'll have to check things over very thoroughly. And the first thing you should find out is if the original programmer is contactable, because if he/she is not, then that is a red flag. Most times I have been asked it's been very vague and the original chap was not contactable, and I've refused the jobs unless doing it from scratch.

| improve this answer | | | | |
  • "As a contractor it's in your best interests to start from scratch" and then leave half way ;) – tymtam Jun 29 '16 at 22:27
  • @Tymski nope, you don't build a good rep doing that, and contractors live off their reputations. – Kilisi Jun 30 '16 at 3:26
  • 2
    No, of course not. I wasn't serious. – tymtam Jun 30 '16 at 3:38
  • On the other hand, if you can say "they fired three contractors before me and one after me", that should be Ok :-) – gnasher729 Jun 30 '16 at 8:00
  • "As a contractor it's in your best interests to start from scratch" . I don't think this is true as a blanket statement. If taking over the previous work is practical, you should use it, both in the interest of the client, and so you can make a lower offer. Most developers prefer writing fresh code over understanding existing code, so there is a problematic bias involved. Of course, sometimes there really is nothing to salvage - but IMHO usually throwing away everything is not warranted. – sleske Oct 26 '16 at 7:59

You must log in to answer this question.

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