When arriving at a source code review for the first time for a case, it is important to appropriately prepare for that first visit, then immediately gather appropriate information during that first visit.

Indeed, day-one analysis does not usually require all of the preparations and information gathering listed below, but in my experience, later in cases I have been asked for information that I have gathered on day-one, and often asked when I am not at the review site!

Tasks before arriving at review site

• Well in advance, supply a list of required and preferred software tools and acquire the licenses required to use those tools.
• Determine the address of code review site
• Determine the name of the firm and the name and telephone number of the person to ask for when arriving.
• Determine any special instructions or credentials required to pass-through lobby security.
• Protective Order’s requirements:
  • Determine the earliest allowed start time for a review
  • Determine the latest allowed end time for a review
  • Determine if a note-taking computer will be provided
  • Determine the confidentiality labeling required for work product that references source code (e.g., HIGHLY CONFIDENTIAL – SOURCE CODE).
  • Determine which, if any, electronics are disallowed in the review room.

• Bring a hardcopy of this list and a hardcopy of instructions for common Linux shell and Windows PowerShell commands (e.g., how to create a manifest, how to create a count of file extensions), as well as instructions for any other tools, as needed.
• If not allowed electronics in the review room, arrive with hardcopies of any patents, claim charts, infringement contentions, infringement/non-infringement theories, architectural diagrams, attorney’s instructions, and any other documentation that might be needed in the review room. This is particularly important if the private break-out room is far away or on a different floor from the review room. A small portable thermal printer can be used to print something on-the-fly in the private break-out room to take into the review room.
• Request an external monitor, keyboard, and/or mouse to accommodate any ADA needs.

Tasks upon arriving on day-one

• Determine the name and phone number of the proctor.
• Determine how to get production and review computer issues resolved.
• Determine the location of a private break-out room.
• Determine if the proctor requires the review room to be unoccupied when they take restroom or lunch breaks. If so, determine the exact times for their breaks.
• Determine if have access to the firm’s lunch room for water, tea, coffee, snacks, etc.? If going out to lunch, ask the receptionist/proctor for a lunch suggestion.
• Determine the location (and possible key or code) for the restroom.

Tasks upon entering review room on day-one

• Determine special instructions, credentials, or keys which are required to enter the review room.
• Document serial number of the review computer.
• Document user name and password for the review computer.
• Document location of the production on the review computer.
• Document list of installed software tools.
• Activate whatever licenses are necessary to use the installed software tools.
• If a note-taking computer is provided, determine how to take notes on it and retrieve those notes from it.

Most of the following tasks also apply to source code not restricted to a remote review

• Create a manifest of the produced files.
• Search for, and recursively unarchive, any files that might have been produced only in an archive file (e.g., .zip).
• If any unarchiving is necessary, create an additional manifest indicated as such.
• Document top-level folder tree structure (occupying only 1-2 pages)
• Document size of production in units of folders, files, and bytes (using Windows folder properties menu item).
• Document count of important file extensions produced (especially source code programming languages used).
• Document number of lines in important file types (if possible with installed software tools).
• Document list of produced source code repositories (e.g., .git folders).
• Document list of produced products and product versions (if possible).
• Document dates of produced products and product versions (if possible).
• Document list of produced technical documentation (e.g., architecture diagrams).
• Document list of source code files that were generated from files that were not produced (if possible).
• Verify ability to create PDFs of source code.
• Based on the contents of the production, document list of any additional software tools and/or plugins/extensions to be installed.

Appropriately preparing for that first source code review visit, then immediately gathering appropriate information during that first visit will allow sooner focus on the analysis tasks at hand.