Shadow Mode: The Dark Side of Outsourcing That Nobody Tells You About

Note: Although there are many articles about the pros and cons of outsourcing, I found nothing useful to inform the product owners about fraud prevention. It's about time to fix this. Imagine the situation: you find a suitable developer, work with them for a few weeks, then you end up seeing their code quality become poor. What is that? Lack of motivation? Dark times personally which reflect in their work? The stars aligned wrong? Or is it shadow mode?

Prologue, or The Problem of Cons and Pros

Before contracting out development to a remote team, you’ve probably read about hiring offshore developers’ pros and cons. I guess you know that the advantages of outsourcing are cost-cutting, staff flexibility, focusing on the core activity, and high productivity of the team. The disadvantages: lack of control, language barriers, intellectual property concerns, and loss of jobs in your country. Based on the articles available, the same content can make outsourcing more tempting than not. 

As a person who has worked in the outsourcing field for three years, I wonder why no one told me about such benefits as capital inflows, distribution of work difficult to manage, and risk-sharing between the parties.  Nor did anyone mention such shortcomings as scaling up management efforts, competing interests of client and vendor, instability risks related to either of the contracting parties, and the threat of opportunism by the vendor. As a marketer, however, I know that there are many more copywriters who rewrite text, than content writers who research first, then create original articles. 

I mean to say that the stories copywriters tell you can be misleading and don’t necessarily reflect the abilities of the copywriters. There are several reasons for this. First, there are not a lot of vendors who hire copywriters and write content because their competitors do the same. Second, no vendor tells you about the way of cheating they use. (How, then, will they deceive you?) 

Shadow What?

Let’s turn back to the situation when the code quality of a developer has become worse. I’m not ruling out the options of dark times, or wrongly aligned stars if it only lasts a week or less. Unless code quality turns around, I almost certainly know that your vendor might be using shadow mode against you.

Shadow mode is the opportunistic practice used by some IT services vendors. The idea is that the agency provides you with the required professionals to interview (e.g., C++ Senior Engineer/Tech Lead), so you hire them without hesitation. After a while, the agency owner sets up a less experienced developer (e.g., Middle C++ Engineer) without your awareness. The result is that you pay the same money for lower code quality. The vendor also gains by assigning their top-employees to other projects. 

During the development process it looks in this way:

The sample of code written by a senior engineer:

app.update(
  '/api/v1/task',
  [authMiddleware({ role: ROLES.user }), validateBodyMiddleware(taskUpdateSchema)],
  async (req, res) => {
    const { taskID, description } = req.body;
    try {
      res.json(await taskService.updateDescription(req.user.id, taskID, description));
    } catch (e) {
      res.status(500).json({ error: getErrorMessage(e.code, req.user.locale) });
    }
  }
);

The same code sample written by the low-quality engineer under the shadow mode, who knows nothing about design patterns, architectural thinking, and best practices with specific technology:

app.post('/update-task', (req, res) => {
  const session = req.cookies['session'];
  const user = getUserBySession(session);
  if (user.role < 2) return res.status(403).json({ error: 'You are not allowed here' });
  if ('taskID' in req.body && 'description' in req.body) {
    const db = getDbConnection();
    db.query(
      'UPDATE "Tasks" SET description = \'' +
        req.body.description +
        '\' WHERE "taskID" = ' +
        req.body.taskID +
        ' AND "userID" = ' +
        user.id
    )
      .then((res) => {
        db.query('SELECT * FROM "Tasks" where taskID = ' + req.body.taskID)
          .then((task) => {
            res.json(task);
          })
          .catch((err) => {
            res.status(500).json({ error: 'Something happened...' });
          });
      })
      .catch((err) => {
        res.status(500).json({ error: err.message });
      });
  } else {
    res.status(400).json({ error: 'Bad query' });
  }
});

I Googled Nothing about Shadow Mode

Every time I told my colleagues about shadow mode, they asked me what it is. As soon as I described the state of shadow mode, I saw their “aha” moment. Almost everyone is aware of it but doesn’t know the name of this practice. This suggests that the developers and managers providing offshore IT services observed, heard, or may have been involved in this process.

Indeed, there is very limited information on this issue for project owners. And I can only imagine how much more the vendors gain by assigning top-employees to other projects.

Do screen trackers or other tools help?

I'm afraid that if the vendor wants to cheat you, they’ll figure out a way to do it.

The screen trackers help you track how many hours the developer works, or how much time they spend browsing through Stackoverflow, but it doesn’t protect your project from fraudulent practices such as shadow mode. For example, imagine you start using the screen tracking tool on the laptop of the Senior developer you’ve hired. The agency owner might pass this laptop on to the shadow developer, and all you will see are the same desktop, dev accounts, IDE, and tools. Even the video calls are useless because both developers are likely working from the same office, so it’s not a problem to switch seats while the client calls you. Thus, the client gets a false sense of security, rather than a protection against fraud.

How to keep your product away from such deceit without any tools

To avoid giving you vague advice, I’ll try to write an algorithm that helps you know what to look for at all development stages.

Before hiring the engineer:

• Check the vendor’s reliability. Trusted development agencies have some commonalities: legal entity, case studies, and reviews on popular directories. The legal entity allows you to feel protected, knowing the law is on your side if something goes wrong. The best option is when the vendor has the entity in your country to simplify all legal and payment processes. Case studies show how the engineers from the agency have developed products in industries similar to yours. Additionally, if you have some free time, you can check the reviews on authority sites such as Clutch, GoodFirms, Extract, etc. The reviews do not always reflect the agency’s authentic assessment but give you some information to be aware of.
• Examine the contract fully. Remember that the contract protects the rights of both the client and the vendor (the clients could also trick the agency, by the way). It’s best to read through the general terms of the contract, add other conditions if needed, and finally sign the agreements. If you have doubts or concerns, seek the guidance of legal experts.

While working with the engineer: 

• Manage the development process in-house. This helps you to monitor the progress and see all organizational changes yourself. If you have no time to manage the team yourself, you can hire either a CTO or a PM. This assures that the in-house manager, who doesn’t work for the vendor, won’t serve the interests of the development agency. 
• Communicate with developers directly. When you chat, hold daily stand-ups, or use other ways to talk to the dev team, you get to know how the developers behave. Thus, you're likely to find if the developer was off doing other things. Again, you can delegate this responsibility to your proxy person. 
• Trace code patterns. Every developer has a unique code of authorship attribution. The company I work for has built a tool that tracks the code authorship by 20 different criteria, among which are: average number of symbols in comments, the most frequently used variable naming, code structure, code coupling, and so on. It’s possible to track such patterns manually, but it takes some time. 

Note: The last advice works for those who are good at programming. If you're a non-technical person, it will be challenging for you to evaluate the quality of code.

You can also consider asking previous clients for feedback, using PM tools like Asana, Jira, Trello (this is helpful for every type of coordination with the team), and seeking assistance from IT consultancies.

Why does this even matter?

The products fail not only because of a lack of motivation or insufficient investment but also because low-skilled workers play a prominent role. The entry-level developers don’t fully realize the scope of project structure, so even small code changes without such understanding can get the product into undefined behavior. This can lead to long app/page loading, security vulnerabilities, performance issues, and incorrect app workflow. Such incompetence affects the general application architecture, so all further app development and maintenance take much more effort and cost. 

I hope this information helps you pay more attention to the vendors that provide you remote software engineers and to detect those who want to deceive you. Cheers.