"Firefighter" consulting, getting a project released

Question

I am about to start working for a new customer who asked for a "firefighter" to help his only developer finish a product due at the end of the month.

While I am confident I will do fine from a technical point of view, I could use some advice regarding the best way to "educate" this developer without sounding too pedantic.

Have you ever been hired for such a task? What are the do and don't?

Answer 1

Don't educate, you're there to finish the project, dot end of line. When the month is over, take your next project.

Answer 2

Start Slow. Look at the big problems first and let the little stuff go so you don't sound like you are constantly criticizing. Over time you can start to work on more subtle changes to the code for optimization, etc.

Answer 3

The best way to educate someone without sounding pedantic is to ask a lot of questions. Figure out what they know first, then figure out where you need to go from there.

Answer 4

First and foremost, practice self-defense. Make sure that your client knows beforehand that jumping in at the last minute is indeed a risk to the project, and that you won't lose reputation if things go off poorly.

Depending on the developer, you'll be met with either efflusive thanks or indignant resentment. If you get the latter, then your most important task is getting buy-in from him. Convince him you're on his side.

Next, take a look at the architecture. If it's a piece of crap -- onworkable -- then communicate that to the client as soon as possible. Try hard not to lay the blame at the feet of the developer (hell, it could be me!), but again, you have to defend yourself.

If it's something you can work with, then do some code triage -- fix the big, easy stuff first, then on to the next piece and so on.

In any event, good luck -- you'll need it!

Answer 5

Never talk about the bad code to your client in front of the other developer. Never let the developer know that you've complained about his code. And never bad-mouth the developer to your client. If you're careful, the client will understand what you mean without you looking like a jerk.

Also, instead of saying, "You should do it some other way...", say "A while back I did it this way, and it didn't work out very well for these reasons, so after I made that mistake, I learned that this other way works really well..." Also be sure to point out the things he did well, especially if you're just about to suggest some ways to improve it.

Really, it requires humility to be a good, likable teacher.

Answer 6

I suggest a pragmatic approach:

1. Determine what must be done still
2. Determine skills & experience differences between you and developer
3. Agree with him that you divide the duties accordingly in appropriate measures
4. Agree with him a feedback to each other schedule
5. Do normal quality things such as testing each others work
6. Give adequate attention to soft issues such as friendliness, co-operation etc.
7. Ensure that regular progress is given to management by both of you.

etc. etc.

Answer 7

The first question to ask yourself is "Can the project be realistically completed by the end of the month?".

Then, I would sit down with the developer and list the tasks that needs to be completed before the end of the project just like I would in a Scrum planning meeting.

Then, I would request an estimate for every one of the tasks.

The two first steps may take a few hours but it is nice to know if you are leading towards a wall or not.

It is possible this estimate will give a completion date after the end of the month. In that case, you will need to start cutting features.