Help me inherit code, not objects

June 27, 2007 11:42 AM

I'm about to receive a large chunk of code for a nearly code complete web app from several consultants and have been tasked with assuming the knowledge transfer. What questions do I ask?

I work for a large financial institution and they outsourced the development of a web application to a consulting firm (it handles reconciliation of data from scanned checks and movement of the scanned images).

I have been tasked to start the knowledge transfer and handle integration issues in our existing environment. They are supposedly almost code complete although no testing beyond unit testing has been done and no integration has been started. Obviously there will be a lot to cover, and I have the impression that they are further off from being done than they lead on, but what I'd really like to come up with is a list of topics and questions to ask. Here are a list of points I've come up with already, I'd like to have more or hear of your own experiences and what to watch out for.

What I've already come up with:

-documentation (specs, architecture, standards, javadoc, support, configuration)

-Source control (trunk, branches, tags)

-General Requirements (JVM version, servlet container version)

-IDE Project file

-Build Script

-list of configuration files

-bug tracking

-Points of contact

-Unit testing

-libraries

-Dependencies

-File system requirements (size, mappings, etc)

-Database requirements

-Other interfaces (ejb, mqseries)

-General security

-User Security

-long term support?

-licenses

What other topics should I cover, what other questions should I ask, what else should I be aware of?

posted by furtive to computers & internet (4 comments total)

Since integration isn't done, you should care about the implicit (and explicit) design assumptions and assumptions about the development, build, and deployment environment. It looks like you've got yourself a Java project, and my experience with Java developers has shown time and time again that regardless of their experience level they may not be consciously aware of the differences between their development environment and a production-ready deployment environment.

In order to successfully land this external code into your production environment you're going to need to figure out what the developers were ignorant of, handwaved away, or otherwise glossed over during implementation. It doesn't fit conveniently into your bullet point checklist of things to ask for -- it's not a one-step question/answer process -- but I advise you to think about how you'll address it.

Almost as important as what knowledge gets transferred is knowing what ignorance got transferred, too. This is doubly so when you're in the hot seat for integration.
posted by majick at 11:54 AM on June 27, 2007

I would definitely ask some questions about scalability regardless of whether or not you're planning on throwing a lot of traffic at it immediately, it's nice to know that they accounted for it in the future.
posted by bertrandom at 2:39 PM on June 27, 2007

The huge ones (by some standards...) you should look at are their unit tests & their documentation. If they have good coverage from their unit tests, and everything is well-documented, your job will be significantly easier, and you'll get a better idea of how everything fits together. If they've written bad or incomplete unit tests ("oh, hey... we were supposed to do testing too"), they might as well not have written them.

You should try to get a feel for how fault tolerant it is, too. There are a lot of systems that just barely hang together when they really should be pretty sound. Knowing the weak points would help you plan for where some recoding needs to be done (i.e., have they checked EVERY place input from outside the program is received, including from other nodes, if its distributed? What happens when the system runs out of memory and allocation fails? What happens when the system gets seriously overloaded (i.e., do they have timing bugs)?

Design rationale is something that should be with the documentation if you're using javadoc, but if there were overarching design decisions that are strange it'd be good to have reasons for those. Along with that, ask about the major problems they had and the solutions they found.

I can't think of other things off the top of my head.
posted by devilsbrigade at 3:47 PM on June 27, 2007

Consider asking, in a casual manner, what parts don't work (or words to that effect). Done at the right moment, you might catch them off-guard and get an honest response. Since nothing of consequence is bug free, they should have a handle on outstanding issues.
posted by trinity8-director at 5:36 PM on June 27, 2007