Telecommuting and procrastination

My col­leagues and I had re­cent­ly an in­ter­est­ing dis­cus­sion about let­ting de­vel­op­ers to work at home. They high­light­ed that one of the is­sues of telecom­mut­ing is that it makes it dif­fi­cult for the man­age­ment to en­sure the de­vel­op­ers are cur­rent­ly work­ing in­stead of pro­cras­ti­nat­ing. Un­for­tu­nate­ly, this point of view is very pop­u­lar in France, and also par­tic­u­lar­ly harm­ful. Let me now ex­plain its flaws.

False sense of se­cu­ri­ty

The be­lief that a man­ag­er, in­de­pen­dent­ly of her tech­ni­cal lev­el, can as­set the pro­duc­tiv­i­ty of a de­vel­op­er by tak­ing a few glimpses over a work­ing day on the mon­i­tor of a per­son is dumb. Peek­ing over the shoul­der of a col­league a few times a day gives noth­ing more than a very ap­prox­i­ma­tive im­pres­sion of the pre­cise ac­tiv­i­ty of a col­league at the very spe­cif­ic mo­ments, and ex­trap­o­lat­ing dai­ly ac­tiv­i­ty of some­one from that is a big mis­take. Imag­ine you are notic­ing that the per­son is read­ing TheDai­lyWTF. What does it mean? It might mean that the per­son is pro­cras­ti­nat­ing for the last three hours. It may also mean that the per­son is tired solv­ing a creepy bug no­ti­fied three hours ago, and needs to rest a bit. Or it may mean that the per­son is run­ning the lat­est suite of unit tests and will re­sume work in a few min­utes when she gets the test re­sults.

This ap­prox­i­ma­tive as­pect also leads to a lot of sub­jec­tiv­i­ty. When I have a bad day at work and es­pe­cial­ly need to work ex­tra hours, I ac­tu­al­ly have a very con­crete im­pres­sion that every­body around me are lazy, and I'm the only one do­ing my job in the com­pa­ny. I walk through the open space and the only thing I no­tice are peo­ple who read ar­ti­cles or play games—I don't even care that it's 1 p.m. and peo­ple are ex­pect­ed to do some­thing oth­er than work. How­ev­er, when I'm in a good mood, what do I no­tice? Right, the ded­i­ca­tion of this guy in the cor­ner who does a great job for the last three days, and the fact that those two de­vel­op­ers on my team are ac­tu­al­ly work­ing hard on the last bugs we have to solve be­fore to­mor­row's re­lease.

Re­ly­ing on our im­pres­sion of the pro­duc­tiv­i­ty of the peo­ple we work with is the sec­ond worst thing we can do, right af­ter mea­sur­ing the pro­duc­tiv­i­ty in terms of LOC or num­ber of com­mits per day or oth­er stu­pid and mean­ing­less met­ric.

Work­ing con­di­tions

What an­noys me even more is that the in­ten­tion of keep­ing an eye on de­vel­op­ers leads di­rect­ly to poor work­ing con­di­tions.

Usu­al­ly, this leads to open spaces or cu­bi­cles. Both are ex­cel­lent ways to kill de­vel­op­ers' pro­duc­tiv­i­ty. If in your com­pa­ny, de­vel­op­ers are forced to work in an open space or in cu­bi­cles, stop read­ing this blog: you have more im­por­tant stuff to do: fix­ing the open space is­sue by giv­ing your em­ploy­ees de­cent work­ing con­di­tions.

If you're one of the sane per­sons who don't force de­vel­op­ers to spend eight hours per day in a work­place which pre­vents any form of work, then you may be in a case where de­vel­op­ers still don't have sep­a­rate of­fices, but share of­fice space by groups of two to three per­sons. In this case, if you want to be able to mon­i­tor what your col­leagues are do­ing, you have two choic­es: put a cam­era in every room be­hind every de­vel­op­er, or po­si­tion the mon­i­tors of every de­vel­op­er so one could see them from the hall­way. In the first case, you should seek help from a psy­chol­o­gist. In the sec­ond case, you should read De­Mar­co's and Lis­ter's Peo­ple­ware which de­scribes, among oth­ers, why this is the wrong thing to do.

In all cas­es, de­cent work­ing con­di­tions and the abil­i­ty of spy­ing on your de­vel­op­ers are not com­pat­i­ble. If you think that spy­ing on your col­leagues will help re­leas­ing your pro­ject faster, you are do­ing it wrong.

Lin­ear­i­ty

One of the points of my col­leagues was that they don't con­sid­er it prob­lem­at­ic if the per­son is play­ing games at work if only the pro­ject is not late.

Let not dis­cuss the rogue ex­pres­sion “the pro­ject is late” for now, and fo­cus on the games part. Let's as­sume that, for some weird rea­son, the ex­pres­sion makes sense, like it seems to make sense to thou­sands of to­day's man­agers, and that, in­deed, the pro­ject can ac­tu­al­ly be late.

I can't see any­thing wrong in a de­vel­op­er play­ing games when the pro­ject is late.

Let me rephrase that. I find it per­fect­ly nor­mal for a de­vel­op­er to play games while know­ing that the pro­ject won't be shipped when ex­pect­ed.

We of­ten for­get that de­vel­op­ers are not work­ers. The na­ture of their job makes it non-lin­ear. A de­vel­op­er who spends eight hours work­ing doesn't do eight times more than some­one who works for one hour. He may do ten times more. Or five times more. Or twice less. As­sum­ing any cor­re­la­tion be­tween time ac­tu­al­ly spend work­ing is as dumb as as­sum­ing a cor­re­la­tion be­tween LOC pro­duced by a de­vel­op­er over a day and her dai­ly pro­duc­tiv­i­ty.

If a de­vel­op­er is not feel­ing like she's able to do any­thing use­ful to­day, I see no rea­sons to force her to write code. Usu­al­ly, this would only lead to low qual­i­ty code which lacks thought and to more prob­lems and to fur­ther de­lays. Sim­i­lar­ly, work­ing un­der time pres­sure doesn't nec­es­sar­i­ly make things faster: some­times, it only makes things slow­er. Push de­vel­op­ers to work un­der stress for six­teen hours be­cause you promised to your boss that the prod­uct will be re­leased to­mor­row, and you may be sure that the prod­uct won't be re­leased the next three weeks—that is the time it takes solv­ing the bugs in­tro­duced dur­ing those six­teen hours.

An­oth­er rea­son I find it nor­mal for de­vel­op­ers to play games when the pro­ject is late is that it's usu­al­ly not their fault if it's late in the first place. In most cas­es, it's the fault of the process. Some­times, it's the fault of the boss or the cus­tomer who doesn't lis­ten to rea­son and wants a six months pro­ject to be fin­ished in four months. Some­times, it's the fault of the man­ag­er who was un­able to clear­ly com­mu­ni­cate about the ac­tu­al re­lease date. In all cas­es, I don't see why de­vel­op­ers need to car­ry the bur­den of some­one else's mis­takes.

This leads us to talk about the re­la­tion be­tween the pro­ject be­ing late and the de­vel­op­ers play­ing games.

Wrong causal­i­ty

If you fo­cus on the fact that de­vel­op­ers are not work­ing on the pro­ject, you may be in­clined to con­sid­er a re­la­tion of causal­i­ty be­tween the way de­vel­op­ers spend their time and the fact that the pro­ject is late or that, more gen­er­al­ly, the work is not done.

As I al­ready said above, de­vel­op­ers are not work­ers. They ac­tu­al­ly en­joy what they do. They work be­cause they like it. They don't make a dis­tinc­tion be­tween a bur­den of soft­ware de­vel­op­ment on one hand, and a plea­sure of video games on the oth­er; in­stead, both are pleas­ant tasks, but not nec­es­sar­i­ly in­ter­change­able—just like read­ing a nov­el and walk­ing on a beach are not in­ter­change­able.

But it hap­pens that de­vel­op­ers are drown in pro­jects which are... not par­tic­u­lar­ly in­ter­est­ing. Some are just plain­ly bor­ing, oth­ers are not chal­leng­ing enough. There are plen­ty of rea­sons which make those pro­jects un­bear­able. The same ap­plies to com­pa­nies and pro­ject man­agers: some have an ef­fect very sim­i­lar to Rowl­ing's De­men­tors by suck­ing all the joy and mo­ti­va­tion from any de­vel­op­er.

They glo­ry in de­cay and de­spair, they drain peace, hope, and hap­pi­ness out of the air around them.

Source: Har­ry Pot­ter Wiki

In this case, in­deed, we find our­selves with peo­ple who start ac­tu­al­ly mak­ing a very clear dis­tinc­tion be­tween the la­bor and the plea­sure. I've seen nu­mer­ous pro­jects where, if I were a de­vel­op­er, I would rather find my­self play­ing games than writ­ing code.

So when we talk about the re­la­tion of causal­i­ty, let use it the oth­er way around. If too many de­vel­op­ers spend too much time pro­cras­ti­nat­ing, this is a very clear sign that it be­comes cru­cial to change some­thing in the pro­ject or in the com­pa­ny.

Wrong mes­sage

The last as­pect worth men­tion­ing is that forc­ing de­vel­op­ers to work on-site with no good rea­son for them gives them a wrong mes­sage. This is es­sen­tial­ly form over sub­stance prob­lem: ei­ther you ask to pro­duce a re­sult and you let skill­ful per­sons de­ter­mine them­selves how would they do it, or you mi­cro­man­age by mak­ing rules which make sense only to you. When you make it manda­to­ry for every­one to be in the of­fice just to make it pos­si­ble for you to keep an eye on peo­ple, you give them a wrong mes­sage that what is im­por­tant is not the re­sult, but how the re­sult is achieved.

In the worst case—and I wit­nessed such case for nine months in my pre­vi­ous em­ploy­er's com­pa­ny—the de­vel­op­ers will end up as­sum­ing that they are paid to be phys­i­cal­ly at the work­place, and not for ac­tu­al­ly re­leas­ing the prod­uct. Of course, you have to make a lot of ef­forts to be that bad at man­age­ment to reach such ter­ri­ble re­sults, but as my ex­pe­ri­ence shown, this is not an iso­lat­ed case. By fo­cus­ing ex­clu­sive­ly on the re­sults and let­ting de­vel­op­ers de­cide how to reach those re­sults, this com­pa­ny, as many oth­ers, could have avoid­ed many of the is­sues they cur­rent­ly have.