Right after I mildly complained about the lack of thoughtful orientation on a new job, I was pleasantly surpirsed with this lovely schedule for my first week at the new place.
Just wanted to share that with you. There's hope for our world.
Nothing like a long 3-day weekend to help forgetting about the old problems from your previous job. This should help making room for the upcoming avalanche of new information and ramping up on the new gig.
I'm also taking this short interval to revisit my previous experiences of changing jobs and what waited for me on my first few days. I think that in all the other transitions only once there was an orientation process in place to assist the new guy learning the ropes. The common approach has always been to give a brief half-day or less introduction to the system, show how to get the source code, show the database diagram, meet your team leader, webmaster, DBA and manager, then go fix some bugs or build a prototype of a new feature.
I can't say that style of orientation (or shall we call it hazing?) can't work. It may work for some types of developers and worked for me, but it's risky and painful. It's also fuel for misunderstandings and propagation of myths. I won't lie and say that I could completely understand the entire system just by reading the source code and outdated documentation, it often happened that I had to grab any chance I had with more senior team members to ask questions that other developers in the same situation as myself could not answer.
I wanted to write this before I even look at the source code that waits for me because I don't want my new team mates thinking I'm talking about their master-piece. Again, I'm referring to my previous job/client changes.
One thing that invariably happens with me when I start reading unfamiliar source code is that shock of dealing with different coding styles, different coding standards, different 3rd party libraries, and sometimes different programming languages (or versions).
A lot of the discomfort is caused by superficial issues like naming conventions that temporarily obscure the understanding of the important characteristics of the system. We shouldn't be distracted by these conventions or code formatting style. What we are really trying to understand and get up to speed with is how the product was designed and which are the important components and identifiable patterns we need to adopt. It's okay to start off writing code with disagreeing naming styles, these things are easy to fix. Misusing or not using the design principles applied in the rest of the code is way more costly to fix, demanding more careful refactoring.
Once we start to see through that noise, we will finally be able to understand the why's and how's of the system. With that understanding comes an increasing sense of admiration for the code. I'm not saying that you will agree 100% with what you see, but at least you can feel more confident that you know what you're stepping on.
With that confidence in place we can start to identify places in system where cracks can start to show or more appropriate solutions for some of the issues. In general, we start to be able to contribute more than just code, but also design options.
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.
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.
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.
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?
The second half of the meeting was an open discussion that revolved around practices of Agile teams. There's also an entertaining rant by I'm-still-Brad in the middle.
This video was captured at the Chicago ALT.NET August 13th meeting. This first video is the Cruise presentation.