How does office bureaucracy affect code quality [closed]

Question

I'm interested in stories where office bureaucracy has had direct effect on the final code quality result.

For example, a friend just told me that at his previous work place the version control system was so bulky that programmers were not allowed to create new "modules" (root directories in the source tree) without asking permissions from the VCS gods. The result was that programmers were unwilling to go through the extra bureaucratic step and instead of properly componentizing their services they ended up piling unrelated functionality on top of existing modules even when functionality was just remotely related to the current definition of the module or the module's name was way in the past. (not to mention renaming a module...)

I'm interested in similar stories of office, operational or any other bureaucracy that eventually, perhaps unintentionally affected software quality

Answer 1

I'm interested in stories where office bureaucracy has had direct effect on the final code quality result.

I don't think bureaucracy has so much effect on code quality as personal dynamics and office politics do. Bureaucracy has to do with process. When an existing process is done improperly (or exploited negatively... see further below), it has the potential to negatively affect the ability to delivery or react to sudden changes. A lack of process, however, will have a certain and significant impact on code quality. Or to be more precise, a process that does not govern code quality (also interpreted as a lack of code quality process) affect code quality.

That is, it is not bureaucracy itself but specific, QA-related holes in bureaucracy that affect code quality when exploited (either accidentally or nefariously.)

Personal dynamics and office politics, however, are much more of a culprit in bad code, however. Personal dynamics involves lack of professional ethics first and foremost. I don't really buy the argument that people write bad code because they don't know better or have not been properly trained. I've seen people w/o CS-related degrees writing decent code. It is a state of mind and a personal matter of being organized and meticulous.

Office politics play an even more terrible role. Bosses that push the don't think, just code mantra (though there are times when we must just code and ship and clean the bodies later); developers who insist on delivering what they think is the perfect code even though getting something out of the door now is of the essence; code reviewers that are a**holes; cubicle wars and such. These things exacerbate problematic personal dynamics. The combination of both seep through any crack in the process (the bureaucracy) or lack thereof, causing a breakdown in code quality assurance.

Hole in bureaucracy could be solved if there is a culture of post-morten reviews and continuous improvement. However, negative personal dynamics and destructive office politics prevent such corrections on the process to occur, thus perpetuating existing problems (including those related to code quality.)

Bureaucracy by itself is rarely ever the culprit in bad code quality. I would actually say that code quality and bureaucracy are both negatively affected by negative personal dynamics and office politics.

Answer 2

I stopped working on some particular modules in the Project because the code reviewer was a Smart A$$

Answer 3

On a recent project, quality people had many requirement regarding formal unit tests (traceability, coding rules, formal reviews, ...). The coders no longer write unit tests, they only debug their code. This is the same task just renamed, leads to the same technical results, but without the administrative hassle.