Do you know how to receive source codes from your developer the right way? We have learned from experience that many companies make mistakes at this point, which will prevent them from developing the system in the future. How can you safeguard yourself against such mistakes?

In the article you will learn:

• the mistakes companies make when receiving source codes
• the consequences of having wrong source codes
• the problems our clients have encountered
• how to take over codes and documentation in a proper manner.

Most common mistakes

The client often fails to engage programmers who could check the condition of data delivered. The most important issue for the client is the system function test; as for the codes, the client only makes sure he/she has received them. He/she does not verify the codes and just assumes they are compatible with the system launched by the developer. Further, he/she receives the codes once the main part of the project has been completed and does not supplement them after subsequent modifications.

As long as the client keeps cooperating with the system developer on a regular basis, things work like a dream. A problem crops up when somebody else takes over the program support. Did I say „problem”? A whole lot of problems crop up and they do so at the worst possible time!

Usual consequences of inadequate reception of codes:

• the system cannot be compiled due to missing documents or codes,
• once the compilation is complete, it turns out there are no codes for specific modules,
• you cannot install the system „from scratch” due to missing components,
• when started on a test server, the system works differently from the one supplied by the developer.

In such a case, clients contact the program developer, which usually solves the issue. It happens though that the developer has not stored the codes or documentation because their collaboration ended long ago. Those responsible for the project may not even work at the company any more. Regardless of the causes, either the system developer helps or the system owner is in trouble.

In practice – sample problems of our clients

Example 1 – lots of wasted time

For our client, we were taking over the support for a system supplied by another developer. The system was composed of a dozen or so large modules. As a whole, it was quite an elaborate program. We received the documentation with the source code package and theoretically things should work out. At first, we verified codes and encountered an obstacle. The program could not be started on a test server.

Intense communication with the client and the developer took us a month and as a result, we received the right codes. „We’ve made it this time”, we thought. Unfortunately we soon found out that we still did not have the codes for all the components. The lacking codes prevented us from developing the system although it functioned. It took us several weeks more to obtain the missing codes. We wasted a lot of time to start and get full access to the program. We could have devoted the time to proper work on operation and development.

Example 2 – a little problem, huge consequences

Several years ago, our present client ordered a document scan processing system from a company. The system operation was stable and smooth over the years. Then the law changed, which required slight modifications to the system. Regrettably, the system developer was no longer interested in cooperation; perhaps the documentation or the people who had created the project were no longer available. Looking for another developer, the client came to us.

Upon initial talks, we determined as follows:

• the client had source codes for the first system version only,
• the system used an internal OCR library the client had no development licence for,
• to make changes, we would have to purchase an analogous licence and the purchase cost would account for a significant percentage of the project value.

No happy ending here. Although the system required small-scale modernisation, the above-mentioned problems made it infeasible. In effect, the client had no option but to order a new system.

So, what is the right way to receive codes?

The proper code reception procedure is not complex, but you need to follow it closely. Apply it when receiving the main part of the system and for every program modification.

When you receive the system:

• check to see the source codes are complete and include any and all modules and fixes,
• read the system installation manual and ensure it is complete,
• install the whole system „from scratch” on a new server, using the codes you have received,
• perform function tests on the system when started from source codes.

In a minimum safety variant, the above-mentioned procedure should be carried out by the developer in the presence of the ordering party. It is a convenient option, especially for companies which have no IT facilities of their own. But it does not guarantee, with 100% certainty, that everything will work as it should in the future.

In an optimum scenario, the developer provides the client with the code and document package. The client engages his/her own team or a third company to conduct the entire procedure on his/her own, without the developer’s participation. Thus the client may check thoroughly the codes for completeness and the system for proper functioning. Any deficiencies or faults are fixed and future software modifications will not pose problems to other programmer teams. The cost of such a solution is just a small percentage of the order value but it minimises future losses efficiently.

Be meticulous

IT systems developed to order are unique software whose operation requires complete documentation and up-to-date source codes. All the more reason to analyse the codes you receive in depth and stick to the recommended procedure as described in this article. With the procedure, your company will always avoid any system development problems.