[oselhn]

I worked on real program developed this way. It was Android/iOS tablet application with large part done in C++. C++ part was somehow generated from Java prototype and development was than outsourced to India. Those guys probably never seen C++ before, so they assumed program is correct and they used same style to extend the application. US managers were just filling reports with green/yellow/red markers preparing for release and having no clue about real state of the app. I worked for another contractor which was also working on this project (there were about 50 people working on small tablet app). I tried to fix those issues but it was really too much work and some guys just continued to broke the program as they really believed they are doing good job. So I decided to find another job and never work for huge US corporation again.

[phaedrus]

I have at times worked with people who, when the TFS task said, "implement this feature", interpreted it to mean "write code vaguely resembling this feature and mark the task complete" but not "test the code works" or even "run the code at least once". It was, apparently, someone else's (whose?) responsibility that the program as a whole actually work. I tried explicitly writing "and write the test and make sure it passes" in the task, and others on the team successfully argued that that is two tasks (we were rated on task completion). But when I made that a separate task, often a different person would end up assigned the task of fixing the result of the other. Anyone who cranked through a lot of the former was rewarded by management for getting so much work done, those who undertook the latter were seen as wasting time perfecting something that was already (supposedly) "done".