How to avoid problems with taking over the code written by outsources?
Programmers, when asked about their biggest professional nightmare, often say it’s working on the code created by another team or an outsourced freelancer. It comes as no surprise. Without proper brief and prearrangements, at the end of the day the company may receive thousands of chaotically written lines, which are understandable only for its creators.
A multitude of projects, lack of time, short deadlines, staff shortages, pivots or sudden business development — those factors often lead to outsourcing a part of the company’s tasks. However, getting the code from an outside developer or a software house is just the beginning of the adventure. What should you do to step into their shoes smoothly? How to prepare guidelines to get exactly what you expect, and that is a transparent code?
Handing over your product to someone else is an important process: it’s sensitive to any turbulence and has a big impact on its future. That’s why it is crucial to plan this process right from the beginning. I’ve come across two different approaches to this task. Some assume that the code just has to work, regardless of its quality and architecture. However, this can lead to problems with scaling, which will occur sooner or later. To make things worse, omitting integrity tests (individual or end-to-end) is risky for the entire product and may slow down its development in the future.
First of all: cooperation
The second approach, definitely preferred by Indoorway, is constant supervision over the written code. It requires cooperation with Team Leaders of an external company. This kind of teamwork may partially slow down the process, but guarantees compliance with your quality policies. When you decide to get more engaged in the work on the requested code, you make decisions about its architecture and you see for yourself what potential flaws or shortcomings the final code may have.
What is the best way to initiate such cooperation? In the beginning, you should deliver your outsourcer quality guidelines, preferably even before your first meeting. It will give them a great, in-depth overview of the situation and enable better planning and valuation of their future work. Unfortunately, many companies forget about the importance of creating quality guidelines or they treat documentation standards either negligibly or routinely. Creating the guidelines in advance and collecting them in one file is so worth it! They’ll be useful for both: outsourcing tasks and conveying good practices to future employees.
It’s also important to involve developers working on the code in meetings and arrangements with the company’s outsourcer. Moreover, you should schedule entirely technical meetings or workshops with both teams of programmers. They would allow them to better understand the developed product, share ideas with each other and aptly find the right workflow. It’s also a good opportunity for everyone to meet people involved in your project, which makes further communication easier.
The terms are settled and welcome handshakes were given? Excellent! Now, it’s time for coding itself. To have everything under control, don’t forget about three key principles:
- If the outsourced code is an integral part of the previously developed product, it’s important to begin with preparing data flow models between the “external” code and the code that has been developed so far by your company.
- In case of network services, it’s good practice to prepare contracts as early as possible, for example, using Swagger.
- For backend products, determine the version of the interpreter and the environment in which they will work by default, whereas for frontend products specify the minimum requirements related to the versions of web browsers.
Customers always expect outsourcers to do their job as predictably as possible, so don’t hide the product while creating it. The assigned job goes much smoother when the company and its outsourcer go through the process of creating the product together. You need to ensure that both parties actively participate at every stage of work. For this purpose, the contractors should provide up-to-date test versions of the product. In case of internet applications, it can be a dedicated website, and in case of mobile apps — Fabric or TestFlight platforms.
The next step: passing the code back to you
When the contract comes to an end, it’s worth to spend some time to familiarize yourself and your team with the code written by an external company. According to Indoorway’s experience, it’s good to include and train as many people as possible to avoid creating so-called silos. When only one person has full knowledge of the project, it’s not difficult to find a crisis situation in the event of his absence or illness. Backup is always the key!
Your outsourcers should help you to dig deeper into the code and understand its complexity. Pay attention to whether the code is properly documented. Does it contain an accessible “user manual”? Good documentation allows you to quickly acquaint the team with the code, and it will also be a good starting point for future employees.
The product should be tested in the environment of the target infrastructure. Your outsourcer must know in what kind of software this product will be launched. And I mean both system and web programming. It’s also recommended to conduct performance tests of the code, which will allow to estimate the cost of usage better.
Code problems: a never-ending story
Fortunately, thanks to building good relationships with our outsourcers, Indoorway has always been able to ensure a smooth transfer of code to its products. However, before we developed a well-functioning scheme, we learned from our own mistakes made while working on other projects. For example, a resigning developer in one of my previous companies didn’t leave any tips for his successors — in this case, me — neither a scheme of a database, nor a text file explaining and guiding others into his code. Besides, the quality of his code was far from perfect. This is the most extreme case, but it taught me that you need to plan your work and set requirements for your outsourcer very carefully.
Now I know that the most important thing, from the perspective of the person who takes or inherits the code, is whether it has been described correctly: from predictable and clear method names to auxiliary comments. It is a good practice to use automatic code documentation. Every popular language has appropriate tools to do so and many libraries use this method of documentation.
How to recognize good outsourcers? If you want to be sure that they provide high-quality services, at the first contact, pay attention to whether they ask about the condition of the code and whether they plan to conduct its detailed audit. If so, you can confidently negotiate further.
This post originally appeared on justgeek.it (in Polish).
