Sad, It sounds like most custom IT business solutions. This brings to light something I have been pondering for a while now. Basically, there are two types cu

Sad, It sounds like most custom IT business solutions. This brings to light something I have been pondering for a while now. Basically, there are two types cultures related to development teams. Culture A, treats the software as their business and respect it as much as they do their customers, employees and partners. In an "A" department developers are empowered to take ownership over the code. This means that they feel obliged to refactor code and improve comments, documentation, and tests as a part of of whatever change they are delivering. It is understood that bugs can come from this but that the overall benefit of not ending up with an unmaintainable system is worth the cost of an accidental bug from time-to-time. Culture B, treats the software as a necessary evil or at best a commodity. Developers are instructed to perform the least amount of changes to meet the changing business requirements. These department are almost always in crises mode as the inflexibility of there bubblegum patchwork has put them into a reactionary relationship with the team who is driving the requirements. In "B" departments you often see high turnover by the best engineers since they feel something is wrong with the departmental management strategy. The high turnover in turn leads to less knowledge about the most complex components in the system and even more reluctance from the management and engineers to risk refactoring something that no one completely understands. I've noticed the "B" shops are always looking for a new silver bullet, the new servers to be able to run the integration tests in under 48 hours since the code is not unit testable or changing frameworks every two years in hopes it will lead to a more flexible system. Unfortunately, in my experience, the "B" companies tend to pay the highest salaries.