Home Home

Telecommuting and procrastination

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
December 23, 2015

My colleagues and I had recently an interesting discussion about letting developers to work at home. They highlighted that one of the issues of telecommuting is that it makes it difficult for the management to ensure the developers are currently working instead of procrastinating. Unfortunately, this point of view is very popular in France, and also particularly harmful. Let me now explain its flaws.

False sense of security

The belief that a manager, independently of her technical level, can asset the productivity of a developer by taking a few glimpses over a working day on the monitor of a person is dumb. Peeking over the shoulder of a colleague a few times a day gives nothing more than a very approximative impression of the precise activity of a colleague at the very specific moments, and extrapolating daily activity of someone from that is a big mistake. Imagine you are noticing that the person is reading TheDailyWTF. What does it mean? It might mean that the person is procrastinating for the last three hours. It may also mean that the person is tired solving a creepy bug notified three hours ago, and needs to rest a bit. Or it may mean that the person is running the latest suite of unit tests and will resume work in a few minutes when she gets the test results.

This approximative aspect also leads to a lot of subjectivity. When I have a bad day at work and especially need to work extra hours, I actually have a very concrete impression that everybody around me are lazy, and I'm the only one doing my job in the company. I walk through the open space and the only thing I notice are people who read articles or play games—I don't even care that it's 1 p.m. and people are expected to do something other than work. However, when I'm in a good mood, what do I notice? Right, the dedication of this guy in the corner who does a great job for the last three days, and the fact that those two developers on my team are actually working hard on the last bugs we have to solve before tomorrow's release.

Relying on our impression of the productivity of the people we work with is the second worst thing we can do, right after measuring the productivity in terms of LOC or number of commits per day or other stupid and meaningless metric.

Working conditions

What annoys me even more is that the intention of keeping an eye on developers leads directly to poor working conditions.

Usually, this leads to open spaces or cubicles. Both are excellent ways to kill developers' productivity. If in your company, developers are forced to work in an open space or in cubicles, stop reading this blog: you have more important stuff to do: fixing the open space issue by giving your employees decent working conditions.

If you're one of the sane persons who don't force developers to spend eight hours per day in a workplace which prevents any form of work, then you may be in a case where developers still don't have separate offices, but share office space by groups of two to three persons. In this case, if you want to be able to monitor what your colleagues are doing, you have two choices: put a camera in every room behind every developer, or position the monitors of every developer so one could see them from the hallway. In the first case, you should seek help from a psychologist. In the second case, you should read DeMarco's and Lister's Peopleware which describes, among others, why this is the wrong thing to do.

In all cases, decent working conditions and the ability of spying on your developers are not compatible. If you think that spying on your colleagues will help releasing your project faster, you are doing it wrong.


One of the points of my colleagues was that they don't consider it problematic if the person is playing games at work if only the project is not late.

Let not discuss the rogue expression “the project is late” for now, and focus on the games part. Let's assume that, for some weird reason, the expression makes sense, like it seems to make sense to thousands of today's managers, and that, indeed, the project can actually be late.

I can't see anything wrong in a developer playing games when the project is late.

Let me rephrase that. I find it perfectly normal for a developer to play games while knowing that the project won't be shipped when expected.

We often forget that developers are not workers. The nature of their job makes it non-linear. A developer who spends eight hours working doesn't do eight times more than someone who works for one hour. He may do ten times more. Or five times more. Or twice less. Assuming any correlation between time actually spend working is as dumb as assuming a correlation between LOC produced by a developer over a day and her daily productivity.

If a developer is not feeling like she's able to do anything useful today, I see no reasons to force her to write code. Usually, this would only lead to low quality code which lacks thought and to more problems and to further delays. Similarly, working under time pressure doesn't necessarily make things faster: sometimes, it only makes things slower. Push developers to work under stress for sixteen hours because you promised to your boss that the product will be released tomorrow, and you may be sure that the product won't be released the next three weeks—that is the time it takes solving the bugs introduced during those sixteen hours.

Another reason I find it normal for developers to play games when the project is late is that it's usually not their fault if it's late in the first place. In most cases, it's the fault of the process. Sometimes, it's the fault of the boss or the customer who doesn't listen to reason and wants a six months project to be finished in four months. Sometimes, it's the fault of the manager who was unable to clearly communicate about the actual release date. In all cases, I don't see why developers need to carry the burden of someone else's mistakes.

This leads us to talk about the relation between the project being late and the developers playing games.

Wrong causality

If you focus on the fact that developers are not working on the project, you may be inclined to consider a relation of causality between the way developers spend their time and the fact that the project is late or that, more generally, the work is not done.

As I already said above, developers are not workers. They actually enjoy what they do. They work because they like it. They don't make a distinction between a burden of software development on one hand, and a pleasure of video games on the other; instead, both are pleasant tasks, but not necessarily interchangeable—just like reading a novel and walking on a beach are not interchangeable.

But it happens that developers are drown in projects which are... not particularly interesting. Some are just plainly boring, others are not challenging enough. There are plenty of reasons which make those projects unbearable. The same applies to companies and project managers: some have an effect very similar to Rowling's Dementors by sucking all the joy and motivation from any developer.

They glory in decay and despair, they drain peace, hope, and happiness out of the air around them.

Source: Harry Potter Wiki

In this case, indeed, we find ourselves with people who start actually making a very clear distinction between the labor and the pleasure. I've seen numerous projects where, if I were a developer, I would rather find myself playing games than writing code.

So when we talk about the relation of causality, let use it the other way around. If too many developers spend too much time procrastinating, this is a very clear sign that it becomes crucial to change something in the project or in the company.

Wrong message

The last aspect worth mentioning is that forcing developers to work on-site with no good reason for them gives them a wrong message. This is essentially form over substance problem: either you ask to produce a result and you let skillful persons determine themselves how would they do it, or you micromanage by making rules which make sense only to you. When you make it mandatory for everyone to be in the office just to make it possible for you to keep an eye on people, you give them a wrong message that what is important is not the result, but how the result is achieved.

In the worst case—and I witnessed such case for nine months in my previous employer's company—the developers will end up assuming that they are paid to be physically at the workplace, and not for actually releasing the product. Of course, you have to make a lot of efforts to be that bad at management to reach such terrible results, but as my experience shown, this is not an isolated case. By focusing exclusively on the results and letting developers decide how to reach those results, this company, as many others, could have avoided many of the issues they currently have.