2014-04-05 - (un)cooperative

there are tools that can help management make decisions. problems start when this tools change status from informative to repression-source. quite common case is test coverage – once you have it in your project (which is good) usually you can expect that management will setup certain rules like “you cannot release unless you have XX% coverage” (with XX being often artificially high), which becomes very bad. from that point tests quality may start dropping, just to satisfy supervisors, yet still add-up to code base size. this is exactly counter-productive.

bug-reporting tools are another example. it's good to keep an eye on what's up. the problem starts when numbers become the-driver. recently i had few-days long @-flame, because i reported few minor bugs, that ends in SEGV of one application. cutting out bullshit-bingo, the point was team responsible for the application in question did not wanted to accept these, as the official bug report is visible to management and breaks their statistics. the-solution, being forced quite strongly, was to do these bug-fixes outside of the bug-fix procedure, by some local improvements or other change requests! taking into consideration these types of activities are low-prio and usually there is no time to do such, one can interpret it as infamous “holly never”. and so we end up with few unfixed bugs, that even if will be eventually fixed, you won't be able to track this fact. more over – you have a bug-reporting too, you should not use. if that's still not enough, you have dozen of ppl arguing for days – literally fighting, instead of cooperating. the funny fact is that, since these problems were quite simple to reproduce, most likely 1 or 2 “ifs” would do for a proper error checking and all fuss would be over. most likely all of the discussion attenders spent more time arguing than it would take to fix it. unfortunately, from their point of view, it is much better to reject any error, than to acknowledge the problem (statistics).

think of it like the programmers-vs-testers problem, when programmers run into problems for having XX bug reports, while testers are being punished for not finding YY bugs a month. will there be any cooperation in there? now think how could it look like if both teams would be rewarded, instead of being punished. better of – given a common target, say customer satisfaction. now programmers try to write as bug less code, as possible, are happy when testers find any (even remotely) possible issue, since this means one less possible error report from client (which cannot be simply rejected!) and finally, testers want to test in detail, since if they would miss something, it will come back from the client sooner or later any way. note there is no tension between testers and programmers – they share the same goal.

using tools to repress instead of reinforce lead to organizing number of teams, with contradicting targets, that fight instead of cooperate. we have nice, local optimization, at the expense of globally optimal solution. plus everyone is nervous (have you found a bug? nice – get ready for a week of harsh @s to get it fixed…).

it is interesting to notice this very similar to how nazi's party worked. it was not uncommon for higher level officials to assign the same tasks to different branches of government, set their targets so that they would interfere and to make sure no one in that mess has enough time or power to change their agenda. classical local-optimization, that took a significant part in a fall of 3rd reich. luftwafe did not takled to kriegsmarine, nor heer. nowadays armies look different – cooperation between different branches is stressed: sharing intelligence, joint operations… looks like the wheel is being reinvented in IT once again. we have some field for improvement.