Transitioning - part I - getting out

Consulting engagements are supposed to end, even after 4.5 years. So, yes, my current assignment with the client is scheduled to end this week (is this job change season?). I didn't honestly expect it to last that long when I started but I guess the balance is positive.

With the end of the assignment my current priority becomes making sure I leave applications that can be maintained by the in-house staff. I can see at least 3 aspects that can impact the success or not of the transition — but only of them can be dealt with at this point. Read on.

1 - Design with maintainability in mind

That's where a truly successful transition starts. Of course there are situations where maintainability is not at the top of the list (think short-lived applications,) but we wouldn't even be talking about transition in those cases.

For all the other situations, which has been most of them for me, maintenance has to be factored in during the pre-coding stages of the project. That's when your senior developers will use their experience to identify potential support trouble in the solution design, before they come to life.

On that front I believe we did a good job within our limitations. I believe the applications were conceived with careful consideration to maintenance and, whichever parts of them created maintenance overhead, happened because of honest ignorance — not sloppiness. So check that off.

2 - Involve the maintenance staff during development

Without becoming annoyingly obvious here, it's always beneficial to have more than one developer knowledgeable about any one part of the application. Be it through code reviews, pair programming, or some other mechanism.

That's especially true for consulting engagements. Raise the red flag whenever you see a situation where only consultants/contractors are working on a project that is expected to be maintained by the client's staff.

Unfortunately the prominent structure of a project team at this client only included a single developer — sometimes an employee, other times a consultant. That was not something that I was ever in a position to change. I raised that flag but... oh, well. Whatever.

3 - Knowledge transfer of the parts you own

If the first two items were taken care well, the knowledge transfer can be just a formality. The less effectively we take care of #1 and #2, though, the greater the pressure on #3 will be.

When transitioning parts of the application that you're the only one that is familiar with, then there are several things to consider: existing documentation, the background of the people taking on the application support, the fancier parts of the code, the embarrassing parts of the code, and the design principles behind it all (if any.)

I think documentation is important but it only goes so far. There are many things that will require sitting in front of the screen, opening the code and/or database, and explaining how things flow.

It's also important to know the style of each developer. If you are dealing with a data-first type of programmer, then you have to make sure enough time is given to discuss the database design. Conversely, if the developer is an objects-first subscriber, the business objects in your code will deserve some more attention. The type of developer you are will also affect this discussion.

I try not to be excruciatingly detailed in the transition to avoid burning out the other developers before they even start touching the code. I try to leave some things that seem clear enough to be discovered by them as they go.

Lastly, if possible, stop taking on support tasks for the application being transferred and have the new crew take care of them while you're available to help. This will also help guiding the knowledge transfer meetings.

In my case I knew I was in trouble for being the only developer on the project(s) so the transition meetings became inevitably numerous and lengthy. In a way I was lucky that I knew I'd be leaving the client more than a month in advance so I could prepare better for this. Being with that client for such a long time also helped knowing the other developers well enough to make a list of items I really wanted to ensure got the necessary talk time.

I don't think it is possible to leave the client thinking 100% of the possible issues are understood, but we are doing a responsible job of covering our bases. At minimum I know the code is in good hands.

Good advice is always welcome. Do you have experiences to share? Anything I could take care of in the next five days?