Mind you I was all for processes but my interest was only to improve code quality [as I was at the receiving end of super-nasty bugs in code I never wrote].
The new management process-ified things blindly left and right, imposed quality checks but the quality processes were followed only formally, i.e. not in their spirit.
There were only two good outcomes out of that:
1. checked in code did not break the build any more and
2. super-bugs were not usually found one day before GA [sometimes they were found and relegated on purpose to "point-one" releases].
Other than that all we got was stacks of red tape and endless useless forms to fill. The time-tracking system was a VisualBasic webapp that was just gross.
IEEE has a very interesting article on this and here is a relevant portion:
The process-imposter organization bases its practices on a slavish devotion to process for process’s sake. These organizations look at process-oriented organizations such as NASA’s Software Engineering Laboratory and IBM’s former Federal Systems Division. They observe that those organizations generate lots of documents and hold frequent meetings. They conclude that if they generate an equivalent number of documents and hold a comparable number of meetings they will be similarly successful. If they generate more documentation and hold more meetings, they will be even more successful! But they don’t understand that the documentation and the meetings are not responsible for the success; they are the side effects of a few specific effective processes. We call these organizations bureaucratic because they put the form of software processes above the substance. Their misuse of process is demotivating, which hurts productivity. And they’re not very enjoyable to work for.Mind you I felt like the last two sentences.
Also the fact that during all my time there I had to pick up after a few people that exhibited the cargo cult programming syndrome did not help either.
-ulianov
