Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
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?

Posted 08-25-2008 5:15 AM by sergiopereira
Filed under: ,



Steve Evans wrote re: Transitioning - part I - getting out
on 08-25-2008 8:15 AM

Great points!  I'm in a similar situation as I'm looking to transition out of my current company (at a still yet to be determined date, but hopefully soon) and have run into many of the same issues.  My problem is that many of the projects are not related to code bases, but more on understanding the business.  That's been more difficult because of the fact I've been with the company for 3.5 years (well 5.5 if you include my time as a student (I work for a private college)).  That sort of knowledge transfer just isn't easy, especially in a fast paced environment where a policy has changed several times over my span with the college.

I agree on the point of not taking support issues near the end of your tenure.  I've been trying to do that, but it's been a difficult habit to break.  Especially when everyone in the company knows to contact me when it comes to IT/IS related tasks.

Dew Drop - August 25, 2008 | Alvin Ashcraft's Morning Dew wrote Dew Drop - August 25, 2008 | Alvin Ashcraft's Morning Dew
on 08-25-2008 9:23 AM

Pingback from  Dew Drop - August 25, 2008 | Alvin Ashcraft's Morning Dew

Sidar Ok wrote re: Transitioning - part I - getting out
on 08-26-2008 12:36 PM

Good stuff. What I'd add to the list is that, while handing over, if possible, record the hand over session so it can be watched over and over again by different people.

sergiopereira wrote re: Transitioning - part I - getting out
on 08-26-2008 1:20 PM


I thought of doing that but I was discouraged by the number of hours and the lack of (easy) indexing in the videos. Maybe I should try that for smaller projects in the future.

Mark Freedman wrote re: Transitioning - part I - getting out
on 09-10-2008 12:22 PM

I've also thought about doing some Camtasia videos for whenever transition time comes.  But I think I'm going to start creating of series of videos now, so there's no last minute rush.

If you find yourself bringing new people up to speed on your systems more than a couple of times, then you don't really need the excuse of a transition to create videos.  It's valuable, not only as part of orientation, but also for you to refer back to them again in case you forget some details.

I love the idea, and as I'm writing this, I'm getting motivated to do a few soon.

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)