12

We've had our old iOS developer drop out and we're looking for a new developer or a team to pick up where he has left off.

I'm aware there can be issues with developers inheriting code etc.

What are some questions that I can ask my old developer to better help the new developer understand what stage the code is at, what needs working on etc etc. Just general type questions? So that when I meet with potential new developers I can hand them a 'fact sheet' of where the code is at form the old developer.

gnat
  • 21,442
  • 29
  • 112
  • 288
Scott Townsend
  • 121
  • 3

7 Answers7

21

A few things to ask/document (may or may not be what you're looking for):

  • What 3rd party libraries/tools/etc are used?
  • How do you build it? Anything special required for a build?
  • What are the valid targets for the build (OS, version, etc)? (from World Engineer's comment)
  • Where is the source located? How is change managed (releases, branches, etc)?
  • High-level overview of the application architecture
  • Any gotcha areas (hard to understand areas, etc)
  • Anything out of the ordinary, where it may not be immediately obvious why something is implemented the way it is
  • Are all defects documented somewhere? Do they have any documentation on hints to correct? Which defects would be good to fix to start getting acquainted with the code?
  • Are all feature requests documented somewhere? Is there any design documentation for the enhancements?
  • Are there any technical specifications?
  • Any required reading to help get up to speed (3rd party documentation, etc)
  • Any areas of the application that need to be reviewed or updated (fix technical debt)?
  • Are all conventions and standards used documented and well known?

I'm sure you'll get more, but I hope you find some of these helpful.

Michael Dean
  • 854
  • 5
  • 8
  • 1
    Make sure in particular to cover the target iOS version. I can't even begin to count the numbers of times this blew up in my face last semester. –  Jul 12 '11 at 05:49
  • @World Engineer - excellent point; I added it to the list. – Michael Dean Jul 12 '11 at 14:38
  • Be sure to ask for the developer's own documentation and source code - hopefully in a repository with a helpful change log. – rlb.usa Jul 12 '11 at 19:06
  • 1
    @MichaelDean - You forgot to list "how do you build it?" which is likely one of the most important questions to ask. Having instructions that the next guy can follow will help. – Ramhound Feb 10 '12 at 15:53
  • @Ramhound I added it to the second bullet, which was not as explicit as "how do you build it". – Michael Dean Feb 12 '12 at 20:26
6

While Michael Dean has already given a pretty comprehensive answer, I will add one further piece of advice, as I assume your old developer isn't going to be around to do a hand over when the new developer starts:

  • Sit down with the existing developer and work through compiling the code from scratch, documenting the procedure yourself.

You don't need to understand the code to do this, you just need to step through setting up the development environment, checking out the source code, compiling it and running the test suite.

Don't let the developer sit at the computer - do every step yourself and document every detail, especially the but you probably shouldn't need to do that again steps.

This can all be a mechanical dummy's guide (i.e. download X, install it, then install Y & Z before checking out the code using the V option on the W menu etc.), but it could save your new developer weeks of messing around, trying to work out how the old developers build environment was set up.

If sitting down with your developer isn't possible, Kim Burgess's suggestion of getting the developer to take a screencast of the build process is an excellent one.

Ideally, you should give your developer a machine that has never been used for development, install your screencasting software and get them to go through all of the steps to build the full software.

In fact, even if you do sit down with your developer, it might be worth running some screencasting software in the background, while he is showing you. that way you will have a permanent record of what you did and what happened.

Community
  • 1
Mark Booth
  • 14,214
  • 3
  • 40
  • 79
  • 2
    +1: As a consultant, I have inherited probably a dozen projects where the earlier developers had left, nobody but them had built it... and the code drops the owners had didn't build - missing source files, funky undocumented build steps, etc. I make it a point of professional pride to always provide a build step checklist consisting of just this sort of mechanical dummy's guide, and follow it myself when doing a build. I also encourage my clients do the build themselves once in a while - they almost never take that advice, but at least I try. – Bob Murphy Jul 12 '11 at 16:48
  • 1
    Rather than manually documenting every detail do a screencast of this session. It will ensure that there are not any issues with semantics in the way you document. – Kim Burgess Feb 12 '12 at 22:56
  • @Mark screencast, not screenshot. This includes a video of the process, voice, key indicators etc. It captures all elements of the interaction with the build machine as well as a providing a narration of the process. Only drawback is it takes linear time for the new dev to view this the first time, however you will be sure not to miss anything and they can create their own documentation from it if need be. – Kim Burgess Feb 13 '12 at 23:35
  • @KimBurgess - Sorry Kim, I misread your comment. That's a great idea, I'll edit that suggestion into my answer. – Mark Booth Feb 14 '12 at 10:32
5

When I was in the same situation, I would have most benefitted from being told what parts of the application to really focus on as the keystone to learning the app. A lot of reading someone else's code is going to be involved regardless, but might as well be given a "table of contents" for that reading.

JD at Elon
  • 51
  • 1
2

"If you were taking this over, what would you want to know about it?"
"Which is the most important?"

The first will make him think of the undocumented, complex parts of the application.
The second will make him think of the details for all of the important parts.

StuperUser
  • 6,133
  • 1
  • 28
  • 56
1

It’s harder to read code than to write it...So it is a good thing that you are trying to help the new developer(s) as much as you can.

First off, I find the two best things to do are:

-Ask your old developer to write out and diagram interactions between classes or methods. This will help the new programmer get a good idea about the main architecture of the program and speed up the learning process. These types of diagrams are often more helpful than pages of written documentation which are often skimmed through by the new developer and not very helpful.

-Ask your old developer about how the source files are organized. Sometimes you can not tell by the name of the file or the name of the containing directory about what you might find inside.

The above two tips will save a lot of time and provides the new developer a good foundation to go and explore the more detailed intricacies...

rrazd
  • 1,398
  • 2
  • 12
  • 23
0

If you do data refreshes from prod on a regular schedule by restoring backups and one might happen between when he leaves and the new person is up to speed on where things are, it might be a good idea to make sure that the changes to the databases on dev that might get overwritten because they haven't moved to prod yet are in source control and in a script that can easily be run to put the dev database back to it's changed state. Same with Qa which may be in a separate set of changes.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
-1

You should to make your old developer comment his code. No one question here will doesn't work. imho.

stukselbax
  • 101
  • 2
  • The code is commented to some degree. Just wondering if there are any burning questions a new dev would have with inherited code before they delved into the code itself, just to get a better idea. –  Jul 12 '11 at 04:41