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?