Teammate departing before launch day is not a disaster.

The Bad News

A new product (let's call it "Messenger") is scheduled to be finished in 2 months but a core team member is telling me he is departing for another opportunity.

Instead of 2 months, I only got about 10 more days to work out the remaining with him. Scraping up the project is the last thing I want and I decided to compete with time.

Constraint becomes your friend

Time become my constraint. I go back to the drawing board and look at Messenger again. I focus on the following area and soon, I found myself having Messenger 2.0.

Garnish looks great but your product won't die from not having it
Cross out everything on the feature list - except those which will render the product non-functional if gone missing.

There's a scheduler engine in Messenger which works similar to crontab. The original design aims to make it generic throughout the entire product line and provide flexibility to define how frequent the scheduled tasks should run. Indeed, the scheduler engine is re-designed to only cater job that runs per day or per minute which are the two settings that Messenger needs.

Spoon and fork VS chopsticks
If your product is already focused in doing one thing, can it be done even simpler?

Messenger is a product to take care of message exchange. User can customize the way to communicate and one of the setting is where in the file system to pick up data for delivery. Instead of allowing the user to define, we eliminated this field and request them to put everything in a pre-defined location. The fewer settings we provide, the less validation effort is required and the less likely to have bugs.

Re-use it if you can
Look around, you might already have some components developed and well tested. But don't over doing this by patching it up as a "make-do".

There are some DB operation needed in Messenger. Instead of writing new DB classes, we reuse the existing DAO and modify to suit the specific needs. The transaction is well taken care of and we can even reuse the unit test cases.

Iterate and iterate fast

The last thing I see essential is working as closely with the developer as you can. This ensure your decision is well executed. And communicating directly helps to address things fast, but of course, keeping things on issue tracker is still necessary.

When my teammate finished anything, he will notify me through IM and I will check it out right away. I shall give him instant response so that he knows if any amendment is needed.

All goes well

Luckily, by the time when my teammate departs, Messenger 2.0 is done. It certainly is a challenge to both of us but having it accomplished is not as difficult as one would imagine. Try to turn the bad into your good.