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

Work­ing with teams and com­pa­nies which ex­pe­ri­ence prob­lems, I can't no­tice a strong cor­re­la­tion be­tween the way man­age­ment treats em­ploy­ees and those em­ploy­ees treat pro­jects they are work­ing on. It al­ways amazes me how many CEOs are ex­pect­ing their staff to do a great job and to in­vest their time and ef­fort in the com­pa­ny, while the same com­pa­ny can't even both­er giv­ing them de­cent work­ing con­di­tions or sim­ply treat­ing them... I don't know... like ac­tu­al liv­ing be­ings?

While I've seen pro­gram­mers try­ing to do their best in un­friend­ly or even harm­ful en­vi­ron­ments, I'm con­vinced that it is sim­ply im­pos­si­ble to ex­pect great de­vel­op­ers to make a great soft­ware prod­uct while lack­ing any re­spect for their ef­forts. This is why one should think twice be­fore tak­ing a mea­sure to solve a spe­cif­ic so­cial prob­lem.

This is ac­tu­al­ly one of the biggest dif­fi­cul­ties in pro­duc­tiv­i­ty man­age­ment and qual­i­ty man­age­ment. You dis­cov­ered that some­thing is a prob­lem, you are able to clear­ly ex­plain what the prob­lem is and you even found a pos­si­ble so­lu­tion. But then, how to know how this so­lu­tion will af­fect the team? Would the team mem­bers ac­cept to fol­low you? Would they rather re­ject your ap­proach and try to cir­cum­vent the mea­sures you're tak­en?

Ba­sic ex­am­ple: you no­tice that the num­ber of re­gres­sions is high, and sur­pris­ing­ly, the code cov­er­age is not ide­al, let's say 60%. In or­der to in­crease pro­duc­tiv­i­ty by de­creas­ing time spent solv­ing re­gres­sions, you start to force the team to make more tests, tar­get­ing 85% in two months. How­ev­er, team mem­bers dis­agree with your so­lu­tion: they think that code cov­er­age is ir­rel­e­vant in their case and that they have enough tests. Re­sult: in­stead of do­ing ac­tu­al work, they are search­ing for the eas­i­est parts to be cov­ered by tests, that is CRUD op­er­a­tions. In two months, you have your 85% code cov­er­age; mean­while, re­gres­sions only in­creased and the morale of your team dropped dra­mat­i­cal­ly.

The more you treat em­ploy­ees as staff in­stead of peo­ple through dif­fer­ent mea­sures, the more would be the in­cen­tive for them to go against your mea­sures.

An ex­cel­lent ex­am­ple of such ter­ri­ble mea­sure ap­peared in a re­cent an­swer on Stack Ex­change. The poster of the ques­tion was com­plain­ing that his team won't com­mit fre­quent­ly enough, mak­ing merges more painful than they should be. The an­swer sug­gest­ed the fol­low­ing:

An or­ga­ni­za­tion I con­tract­ed for in the past want­ed to solve this same prob­lem, and came up with a fair­ly good so­cial so­lu­tion: de­vel­op­ers do not have their own com­put­ers. The de­vel­op­ment TEAM has com­put­ers, but any in­di­vid­ual can be asked and ex­pect­ed to work on any de­vel­op­ment com­put­er on any giv­en day. So, check­ing in is the only way to make sure you can con­tin­ue work­ing on what you were do­ing yes­ter­day!

Man­age­ment then went around and sur­rep­ti­tious­ly re­vert­ed changes on com­put­ers af­ter hours so that any­thing not checked in was lost. These "sim­u­lat­ed com­put­er fail­ures" only had to oc­cur a few times be­fore the devs got on board.

Of course, it's im­por­tant to ex­plain the "why" of rules as well as the "what". Un­less the "why" is made clear, they could just store their source on USB dri­ves or some­thing.

How could any­body be pos­si­bly call­ing that a “fair­ly good so­cial so­lu­tion”? It is all but so­cial, or good, or a so­lu­tion. The only thing it cre­ates is a poor morale and time lost, day af­ter day, con­fig­ur­ing the op­er­at­ing sys­tem, in­stalling the ap­pli­ca­tions, etc. What about per­son­al files? Or the e-mail client? Or pass­words stored in the brows­er? Or the pre­ferred brows­er? Or the con­fig­u­ra­tion of the IDE? Or code snip­pets?

I would love to be in this com­pa­ny on this pro­ject, just to see how long would it take to the man­age­ment to see their own stu­pid­i­ty. There are a few things pro­gram­mers can do in such con­text:

1. Not com­mit­ting the code in the evening and, when asked what they did dur­ing the day, telling that they were re­do­ing yes­ter­day's work. If man­age­ment prefers that I waste one hour every day, great, I'll do it. Quick­ly, man­age­ment will ask to com­mit un­fin­ished code, which will lead to the sec­ond tech­nique:

2. Com­mit­ting bro­ken code every evening, and by bro­ken, I mean code which ob­vi­ous­ly can­not be build be­cause it is un­fin­ished. Very prob­a­bly, the com­pa­ny is not do­ing night­ly builds or tests, but code which can't even com­pile is prob­lem­at­ic even out­side builds and tests, be­cause it af­fects work of the whole team. If the team agrees to sup­port you against the man­age­ment, this can be a very ef­fec­tive way to fight against the man­age­ment: leave the code un­fin­ished when go­ing on va­ca­tion and ask your team to pre­tend that they don't know how to solve your mess. They can eas­i­ly spend the whole day do­ing noth­ing and blam­ing the part of the code which doesn't com­pile.

3. Com­mit­ting untest­ed (and in­ten­tion­al­ly flawed) code is even bet­ter. If in the pre­vi­ous case, the team can­not pre­tend to not be­ing able to solve the prob­lem for sev­er­al days, an in­ten­tion­al­ly hid­den bug (your cowork­ers know about, but not your man­ag­er) is an ex­cel­lent op­por­tu­ni­ty for a team to do noth­ing as long as they please dur­ing your en­tire hol­i­day. In the ab­sence of night­ly builds and test­ing with enough cov­er­age, man­age­ment would hard­ly dis­cov­er that the re­gres­sion oc­curred in your last com­mit and won't nec­es­sar­i­ly ask your team to roll­back to pre­vi­ous re­vi­sions and see if the bug still ex­ists.

   When your va­ca­tion ends, “What bug? That one? That's easy, you just have to re­place this by that! I didn't have time to do it the last time, and since you force me to com­mit every evening...” would be ex­treme­ly ef­fec­tive.

4. Count­ing time you spend con­fig­ur­ing your PC every morn­ing. “Our team spent $12 800 do­ing repet­i­tive, use­less work be­cause of the lat­est man­age­ment stu­pid­i­ty. Also, the pro­ject will be de­layed for ad­di­tion­al four weeks.” should be per­sua­sive enough.

5. Boot­ing from an ex­ter­nal hard disk. Changes on a PC were re­vert­ed? Fun­ny, you haven't even no­ticed that, nor should you be con­cerned.

The last mea­sure makes me think of what hap­pened at my last work­place. Man­age­ment cared a lot about mak­ing pro­gram­mers' pro­duc­tiv­i­ty as low as pos­si­ble through many stu­pid mea­sures. One of such mea­sures was to force us to re­new our do­main pass­words every month while set­ting a few rules about what a pass­word should or should not con­tain. Chang­ing the pass­word was painful too—this is a priv­i­lege of work­ing in a com­pa­ny which don't have a sysad­min who ac­tu­al­ly knows his stuff—and usu­al­ly re­sult­ed in lot of wast­ed time deal­ing with fun­ny mes­sages such as Win­dows ask­ing to re­new an ex­pired pass­word, then re­fus­ing to re­new it, be­cause it is ex­pired.

It ap­peared that not us­ing my Ac­tive Di­rec­to­ry ac­count by switch­ing to a lo­cal ac­count was an ex­cel­lent so­lu­tion, which also came with nice side ef­fects, such as in­stant lo­gon (in­stead of hav­ing to wait very of­ten for sev­er­al min­utes) and no spy­ware in­stalled au­to­mat­i­cal­ly by do­main con­troller on my ma­chine.