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

  • That's a very very interesting question... – user2567 Oct 7 '10 at 7:53
  • 1
    Dang it. I know I have some good stories for this, but it is the type of thing I try not to think about. :) – George Marian Oct 7 '10 at 7:58
  • 1
    @Ran you get +1 scrum point for this question ;) – Eran Harel Oct 7 '10 at 8:10
  • This question is inherently negative and inviting destructive/critical answers. Could you perhaps elicit constructive answers of how these issues were overcome - technical solution, human solution, lateral thinking, etc? – JBRWilkinson Oct 7 '10 at 12:03
  • 1
    @JBRWilkinson What's wrong with sharing the pain and having fun while at it? It helps other human beings, perhaps it'll help programmers as well... – Ran Oct 7 '10 at 13:16

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.

  • no exactly the kind of funny answer I was expecting, but definitely a thoughtful one, so I'll mark as "accept" even though I'll be happy to see more stories fly in. – Ran Oct 17 '10 at 11:31

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


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.

  • 5
    Unit tests are pieces of code run automatically to catch coding errors. They are 'free' to run. Humans spending lots of time debugging cost $$$ per person per hour. If just one developer leaves, the debugging capability of the team is reduced but the unit tests would still be just as good. – JBRWilkinson Oct 7 '10 at 12:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.