Home Home

What if the team would just circumvent the “productivity measures”?

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
December 18, 2014

Working with teams and companies which experience problems, I can't notice a strong correlation between the way management treats employees and those employees treat projects they are working on. It always amazes me how many CEOs are expecting their staff to do a great job and to invest their time and effort in the company, while the same company can't even bother giving them decent working conditions or simply treating them... I don't know... like actual living beings?

While I've seen programmers trying to do their best in unfriendly or even harmful environments, I'm convinced that it is simply impossible to expect great developers to make a great software product while lacking any respect for their efforts. This is why one should think twice before taking a measure to solve a specific social problem.

This is actually one of the biggest difficulties in productivity management and quality management. You discovered that something is a problem, you are able to clearly explain what the problem is and you even found a possible solution. But then, how to know how this solution will affect the team? Would the team members accept to follow you? Would they rather reject your approach and try to circumvent the measures you're taken?

Basic example: you notice that the number of regressions is high, and surprisingly, the code coverage is not ideal, let's say 60%. In order to increase productivity by decreasing time spent solving regressions, you start to force the team to make more tests, targeting 85% in two months. However, team members disagree with your solution: they think that code coverage is irrelevant in their case and that they have enough tests. Result: instead of doing actual work, they are searching for the easiest parts to be covered by tests, that is CRUD operations. In two months, you have your 85% code coverage; meanwhile, regressions only increased and the morale of your team dropped dramatically.

The more you treat employees as staff instead of people through different measures, the more would be the incentive for them to go against your measures.

An excellent example of such terrible measure appeared in a recent answer on Stack Exchange. The poster of the question was complaining that his team won't commit frequently enough, making merges more painful than they should be. The answer suggested the following:

An organization I contracted for in the past wanted to solve this same problem, and came up with a fairly good social solution: developers do not have their own computers. The development TEAM has computers, but any individual can be asked and expected to work on any development computer on any given day. So, checking in is the only way to make sure you can continue working on what you were doing yesterday!

Management then went around and surreptitiously reverted changes on computers after hours so that anything not checked in was lost. These "simulated computer failures" only had to occur a few times before the devs got on board.

Of course, it's important to explain the "why" of rules as well as the "what". Unless the "why" is made clear, they could just store their source on USB drives or something.

How could anybody be possibly calling that a “fairly good social solution”? It is all but social, or good, or a solution. The only thing it creates is a poor morale and time lost, day after day, configuring the operating system, installing the applications, etc. What about personal files? Or the e-mail client? Or passwords stored in the browser? Or the preferred browser? Or the configuration of the IDE? Or code snippets?

I would love to be in this company on this project, just to see how long would it take to the management to see their own stupidity. There are a few things programmers can do in such context:

  1. Not committing the code in the evening and, when asked what they did during the day, telling that they were redoing yesterday's work. If management prefers that I waste one hour every day, great, I'll do it. Quickly, management will ask to commit unfinished code, which will lead to the second technique:

  2. Committing broken code every evening, and by broken, I mean code which obviously cannot be build because it is unfinished. Very probably, the company is not doing nightly builds or tests, but code which can't even compile is problematic even outside builds and tests, because it affects work of the whole team. If the team agrees to support you against the management, this can be a very effective way to fight against the management: leave the code unfinished when going on vacation and ask your team to pretend that they don't know how to solve your mess. They can easily spend the whole day doing nothing and blaming the part of the code which doesn't compile.

  3. Committing untested (and intentionally flawed) code is even better. If in the previous case, the team cannot pretend to not being able to solve the problem for several days, an intentionally hidden bug (your coworkers know about, but not your manager) is an excellent opportunity for a team to do nothing as long as they please during your entire holiday. In the absence of nightly builds and testing with enough coverage, management would hardly discover that the regression occurred in your last commit and won't necessarily ask your team to rollback to previous revisions and see if the bug still exists.

    When your vacation ends, “What bug? That one? That's easy, you just have to replace this by that! I didn't have time to do it the last time, and since you force me to commit every evening...” would be extremely effective.

  4. Counting time you spend configuring your PC every morning. “Our team spent $12 800 doing repetitive, useless work because of the latest management stupidity. Also, the project will be delayed for additional four weeks.” should be persuasive enough.

  5. Booting from an external hard disk. Changes on a PC were reverted? Funny, you haven't even noticed that, nor should you be concerned.

The last measure makes me think of what happened at my last workplace. Management cared a lot about making programmers' productivity as low as possible through many stupid measures. One of such measures was to force us to renew our domain passwords every month while setting a few rules about what a password should or should not contain. Changing the password was painful too—this is a privilege of working in a company which don't have a sysadmin who actually knows his stuff—and usually resulted in lot of wasted time dealing with funny messages such as Windows asking to renew an expired password, then refusing to renew it, because it is expired.

It appeared that not using my Active Directory account by switching to a local account was an excellent solution, which also came with nice side effects, such as instant logon (instead of having to wait very often for several minutes) and no spyware installed automatically by domain controller on my machine.