[/caption]I've been working on a project for the last 5 months, but finished active development about a month ago. I finished in the best possible way, the product shipped, the customer likes it, and there hasn't been much to do besides the minor bug or feature here and there. It's a good place to be in, since I'm a consultant it's also not economically viable. If I'm just sitting here writing blog posts and drinking smooth delicious Diet Dr. Pepper all day, I'm not making money for my company, so they went and found me another project to work on, which I talked about here.
I'm looking forward to starting my new project, but as Semisonic taught us, "every new beginning comes from some other beginning's end." (Have to try to pull this post out of the tailspin caused by quoting Semisonic lyrics now). The problem is that when you start a new project, the glitz and glamor of a new project you haven't learned to hate yet can blind you from the responsibilities of being the guy leaving.
Leaving a project comes bundled up with a bunch of responsibilities. The cliched, "what if you got hit by a bus tomorrow?" question that managers love to ask (because they are too afraid to say, "what if you quit" or "what if I fire you" but oddly enough have no qualms with theoretically knocking you off) actually has some value. The "bus" of leaving this project is barreling down at me, and I have to make sure I dump enough of my brain out that people can still maintain the code I wrote.
If you read my rant / guide to project documentation, here's a chance for me to prove myself. Throughout the project I've dutifully created and more or less kept documentation up-to-date about everything from server credentials to step-by-step deployment procedures. I cannot recommend this approach enough, after reading through some of my wiki pages on these topics it is clear that trying to compile this information after the fact would be difficult if not impossible. So since, ostensibly, everything is done already, what am I left to do?
- Read through documentation - Projects move fast, things that made sense a month into a project probably won't make sense 5 months into a project, be sure everything is up to date. Read the documentation with the mindset that you are trying to start working on a project, is it clear, could you set up a development environment, fix a bug, and push out your changes in a day? If not, figure out why not, and fix it.
- Bug your coworkers - Someone will be around to work on the project, start bugging them to read the documentation, have them go through a dry run of some complex task you normally do, and let them mock your ability to document things properly. It is much easier to have a minute or two of verbal in-person explanation then trying to remember how things work and having a 20 email long thread of questions and answer a few weeks into your new project.
- Clean house - Those tasks you were putting off doing, get those done, and for fsm's sake, do it right! There is nothing worse than being knee-deep in a new project to have a past project rear its ugly head, forcing you to dredge up long forgotten knowledge to fix some minor issue.
- Cut ties - Clients and other developers get used to coming to you with issues, if you are moving on to a new project, let them know about it. Inform them that you will no longer be the contact for the garthok narfler and that they can talk to developer x about it from now on. For an extra touch of class let them know that it was nice working with them.
The way you leave a project is almost as important as the work you did on the project. Rest assured no matter how good a job you think you did, a few weeks after you leave, other developers will be cursing your name. Your job as you leave is to make sure that those angry expletives are few and far between and that you can rub it in their face when they complain about this problem or that obstacle with the fact that you left them very clear documentation on how to handle such a situation.
No comments:
Post a Comment