Process of handing over source code to a customer [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Software Engineering Stack Exchange.

Closed 5 years ago.

Improve this question

Should I just copy the project files to him? Should I sit and explain the code to him ? If so, up to which level of details? Or do I just tell him where everything is within the solution and not how the code works?

I would appreciate your input

Answer 1

You make a copy of the code.

You take that copy of the code to a different computer and verify that you can build the application on that computer from the code.

If that doesn't work, then you fix all the problems in the code until it works to build the application on your computer, and on the second computer.

You document all the steps that are needed to build the application, so that another person can build the application using those instructions only. When you document the steps, you assume that the reader can read the instructions, but not your mind.

You give the code and the instructions to a secretary at your company, or to your mother, and make sure that they can build the application following the instructions without asking you any questions.

Until that works, you improve the instructions.

At that point, you hand over the code and the instructions to the customer.

Answer 2

I would approach this the same as when handing over to any other maintainer:

• Include the source control files so that they have the entire history of the project.
• Make sure that the code builds from source with just one command. Nothing is more depressing then having to spend several hours/days before getting it to compile.
• If external resources are required (say a database) the code for setting them up should be part of the source control. (Think: Migrations and/or for example a Vagrant file for local testing.)

• Documentation:

  • A High Level overview of the project (the different layers, their intent and their dependencies)
  • Deployment configuration: How to deploy (again, ideally with one command), where to find the log files, which firewalls, reverse proxies, ... are passed, credentials for databases etc.
  • Anything that you think your client could benefit from... (ex: ubiquitous language, design/architectural decisions etc)
  • Most importantly, keep documentation as short as possible. If you hand over 50+ pages of documentation, chances are it will never be read. (it all depends on the size of the project of course but less is almost always better)

Going through the code with the client: I guess this is up to him. If the client will continue work on it right away, going through the code together is a very good idea. He will not remember everything you say and show but will have some general idea of your project layout.