Old programmer disappeared. About to hire another programmer. How do I approach this? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

After spending over one year working on a social network project for me using WordPress and BuddyPress, my programmer has disappeared, even though he got paid every single week, for the whole period. Yes, he's not dead as I used an email tracker to confirm and see he opens my emails, but he doesn't respond. It seems he got another job. I wonder why he just couldn't say so. And I even paid him an advance salary for work he hasn't done.

The problem is that I never asked for full documentation for most of the functions he coded in. And there were MANY functions for this 1+ year period, and some of them have bugs that he still didn't fix. Now it seems all confusing.

What's the first thing I should do now? How do I proceed?

I guess the first thing to do will be to get another programmer, but I want to start on the right foot by having all the current code documented so that any programmer can work on all the functions without issues.

Is that the first thing I should do? If yes, how do I go about it?

What's the standard type of documentation required for something like this? Can I get a programmer that will just do the documentation for all the codes and fix the bugs or is documentation not really important?

Also, do you think getting another "individual" programmer is better or get a company that has programmers working for them, so that if the programmer assigned to my project disappears, another can replace him, without my involvement? I feel this is the approach I should have taken in the beginning.

Answer 1

Based on that interaction we had in the comments, I'll go with the assumption that you didn't drive your only developer away because of personal things. However, basing on that conversation, I'll make another guess that this setback is still mostly your responsibility as a hiring manager. As you mentioned you don't have AT ALL any experience with developers, but then how do you make a decision on how to hire one?

It sounds like you did your best, but you hired somebody who simply couldn't handle the scale of this project, he built shaky foundation which crumbled under him and then he simply left. Unfortunately, the difference between developers and entrepreneurs is that the former get paid hourly/salary but they can choose to come and go as they please. He got paid for the hours he worked and he left when he chose not to get paid anymore. Nothing you can do about that.

So what now? It seems like you started going down the path of replacing people with process. If only you had enough documentation, people could leave and others could pick up where they left off. IMO that doesn't work and if it does work, it'll still be way more expensive than having a reliable team of permanent employee(s). Management at various companies over the last 30 years have tried to replace people with enough documentation (including my last job) and they failed every time. That's why I decided to switch jobs and now they are stuck with their outdated and never accurate documents, while I'm having the time of my life in a new startup.

What I would do if I were you would be to try to find the right person with enough skills and experience to pick up this project and carry it to completion. This not only includes coding skills, but also design, architecture as well as basic project management. Do not try to define how he does his work, or how many documents he needs to produce. Just focus on finding the right person and be prepared to pay accordingly. When you do find him, make sure your role is to support him and remove obstacles from his way, not monitor/micromanage. I'm not implying that you did that before, but I do know a lot of managers tend to do that and that's just counter productive.

Talk to other entrepreneurs, possibly those with more software engineering background. Read these forums and come up with a set of questions to ask your prospective hire. Present the problem and ask what the approach would be. If he is the right guy (and assuming he didn't see this page), he should be able to suggest a lot of the things that other people already suggested in terms of what should be done in your company as you start recovering. Ask him to define a plan from the time he is hired to when your v1.0 will ship. How will he get you there. Ask for help interviewing such a person.

Just few of my own thoughts: Bug tracking is a must (Jira costs $10 for a team of up to 10 people). Source control is a must (git is free. perforce costs peanuts for a team of up to 5 or so people). Your code is your documentation. Not your written word documents. He should review the code and keep what is salvageable; throw out the rest and focus on writing maintainable and readable code. Save documentation for few high-level, few-page design docs. He must know the technology you are working on. Don't hire someone with just good intentions; you can't afford to have them learn on your time. Ask them what other projects they've done (unfortunately you or someone you find might have to keep up with technical aspect of things). You are looking for someone with enough experience but at the same time not too much that that spark of excitement has already burned out. Find someone who is hungry to make an impact. The methodology he proposes or follows should allow you to see work on regular (one or two weeks periods) basis and to provide instant feedback. Don't hire ANYONE who says, it'll be ready in exactly 7.4 months, I'll let you know when it's done.

Good luck

Answer 2

This is a strange situation, and I'm quite sure you're not telling the whole story. I worked with many people, some of who left for various reasons (me being their colleague), but don't try to tell us that everything was super good and one day just no contact.

But that's not problem. At least not anymore; you should learn from your mistake and try not to repeat it in the future. And yes, I'm strongly suggesting that 50% is your fault of him/her leaving.

Now about solving the current problem:

1. Try to contact your programmer. He reads your email - offer him money for documentation/fixing the most crucial bugs. No one else will be able to fix those faster than him. Doesn't it work? Try to find where he works, contact that company and tell your story. A good company will not hire a person who could do the same for them. At least they'll tell him to finish the documentation for you.

   NOTE: you don't want that person back, you just need finished documentation

2. Be prepared that your one year worth of work is going to be void. He might have fled when you asked for results and he knew he couldn't deliver. It's possible that the code is full of hacks, dirty implementation and overall poor quality. Even if he comes back - he probably won't have the skills or even time to do it right.

3. Look for another person. He needs to know the same technologies (programming language, frameworks, etc.). If the code quality is good - he could continue, if not, he'll be able to refactor it. Yes, refactoring takes time with no new feature implementation, but it makes code maintainable and that's what you need. Plus, a person who can refactor bad code is a really good programmer, hold on to him/her.

   NOTE: it's silly to pay money up front. The whole idea of salary is to pay for job done. Not for a promise made :)

4. Make lists. It's in your best interests to have a plan. A technical specification that once read will allow the new programmer to understand the job and milestones. Have at least three important documents:

   • Overall description of the project - a document that will allow even a non-programmer to know what is the project about.

   • Timeline - what part and when do you expect to be ready? What is already done?

   • Technical specification - this is a long one. It is THE document that a programmer wants to read. Separate it into logical parts and describe in as much detail as you can the features and workflow of that specific part.

Working with companies isn't really that good; your chances won't get better. And you'll overpay 10 times if you hire only one programmer. If you have a small team, let's say 3-5 people, just hire a programmer willing to be a team lead. He'll do a much better job managing the team.

Answer 3

Documenting code afterwards by another programmer? It is merely my own experience and opinion to tell you should not take that path.

Without more detailed knowledge of the quality of that code base, my opinion is that your best approach is to hire a new programmer to fix the bugs, maintain and possibly make modifications you require.

That opinion has the key point of possible modifications (changing or adding), as they need a requirement to be fulfilled. This means that some sort of requirement specification must be written. This is a document.

Which leads to a point of maintaining the whole project. You did not tell in your question if current programs requirements or even rough functional documentation exists, but that is where you should focus now.

In case you don't have any documentation at all, at this point, then it is more up to you to fill that void. You can not hire a programmer to reverse-engineer your application and miraculously mold documentation out of that. You must "explain" what you want the program do (even if it means to reexplain what has already been programmed in.)

When you have that document written (be it in form of requirement- or functional specification), you will get way better results from hiring a new programmer as you can hand over the documentation and start working from there.

There are also lots of programs that produce documents out of source code, which is good way to produce a skeleton of explaining the actual source code (this is in area of technical specification) which you only can work in context of explaining the technical aspects of the functionality specified in functional specification, which specifies the functionality of requirements specified in requirements specification.

So yes, my opinion is to hire a programmer to fix the bugs. After he has fixed the bugs which you agreed should be fixed, you could discuss the documenting aspect as another contract. With luck you hired a programmer who has some experience and can contribute to what steps you should take next from there.

Answer 4

Here's how I'd approach the problem :

• You have the domain knowledge. You know which features are available on the website now, which ones you'd like to add in the future, and can probably list a few bugs that were reported by users, too.

• There's this pile of code sitting there, left to itself in a corner. It might be buggy, but it still delivers value since the site has active users. A complete rewrite would thus be a mistake IMO.

The bridge between your domain expertise and the code was broken when the programmer left. You need to rebuild it so that the code base can be synchronized with your requirements again and that future updates can be developed.

The thing is, that bridge can't be entirely made of documentation. Software is a human matter as much as it is technical. If you don't explain the new programmer what you expect in great detail, he or she'll have a hard time deducing that from the code alone - all the more so if the previous programmer wrote cryptic, poorly documented, poorly tested code. And if you don't work in close wollaboration with the new programmer to find an automated, continuous way to verify the code matches your requirements, in other words to make the bridge more robust, the problem is doomed to repeat itself.

• Regularly sit down (even virtually) with the new programmer for domain knowledge processing sessions. During each of these sessions, write together the specifications for a small part of your product. It can be a single web page, it can be a feature. Making them executable specifications (a la Behavior-Driven Development) will increase your level of confidence that the bridge works, because you can run them continuously and be warned when there's something wrong. It will also make the developer's life easier.

  After a session, the developer is able to return to his work and write lower-level tests which validate that the current code complies with the spec. If it doesn't comply, then the programmer has everything he needs to fix it. It's also important to remain available for any questions he could have.

• Try to maintain a tight, continuous collaboration between you and the programmers on your project, and make sure this is also true between them. This is necessary if you want the functional and technical culture around your project to live on, avoiding issues like the one you're having now. This of course requires not only 2+ developers working on your project, but also that they share with one another the knowledge about everything they write. Thus one can act as a failover when another gets missing. Techniques such as pair programming and code reviews are good ways to achieve that.

Answer 5

Just adding to what everyone has said,

If you can't get the old programmer to document his/her code even at a price, then don't expect someone else to be able to document it any better. So here are some options on what you can do for now to make the new programmer productive on day one.

1. Get a bug database, and start entering all the bugs you found into it. This is the programmer's priority to-do list. Document it well and put in as much detail as possible (source file/root cause, what it does, and what it should do). There are lots of free bug tracking software, like Bugzilla, Redmine and JIRA. Feel free to use whichever you like.
2. Create a specification sheet for your project. This will give the new programmer some direction after the bugs have been cleared. You can check out Joel's guide on writing specifications.
3. Create a schedule or a time line for your project. They should have deadlines and milestones in which they get paid for work they rendered rather than paying them in advance.

Now that that's out of the way, you can start looking for a programmer. And like Creative Magic said, outsourcing the job to companies can lead to disaster or blow up the price to infinity and beyond.

This time around, start planning properly for the bus factor when hiring programmers. People come and go and there is nothing you can do about it, so prepare for the worst this time by getting two programmers, or as Uooo said, get one programmer and one tester.

Now, once the programmers are in the shop with you, you can start asking them to document their code going forward rather than asking them to document old code, really, forget that.

Other things to consider when getting a new programmer, make sure they know source control and automated testing. Also, try to get as many checks on the Joel Test as much as possible with their help, you can only do so much of this on your own.

Answer 6

So, your only programmer was hit by a bus, and you need replacement now.

You could try to sue your former programmer, based on yout contract, or find out what's wrong with him. Assuming that he won't come back, this won't help you.

• You want to get your product done, so search for a programmer who has experience in maintaining and developing existing systems. I would not focus on telling your programmer what to do in what order. Make sure you hire someone professional, who writes documentation and unit tests whenever necessary.
• From your side, you can make sure that the new programmer has everything needed for his work: Requirement specifications, a powerful working machine, and so on. You want a professional programmer, so provide him a professional working environment.

Also, think about hiring a second developer for making this kind of difficult situations easier in the future. A tester would be useful for quality assurance as well.