It’s been my experience that just like in sports where you have a goal tender, every development team needs a gate keeper or goal tender for their VCS to ensure nothing gets in that they don’t want. The role of the gatekeeper in the team is not only to manage the promotion/demotion of DEV code to QA on through to PROD (production), but also to ensure the code meets syntax standards, and more importantly architectural standards or conventions.
Even if the standard way of doing things is less than optimal, consistency is king. If a slower evolutionary method of evolving the code is not possible, at least with consistent code, you can transform it en masse at the beginning of a release cycle and dedicate a lot of QA time to ensure you didn’t break anything. Developers who understand the “normal” way of doing things can maintain and write code comfortably, with confidence that it will work.
I have seen consultants brought in to author a new system and use it as an opportunity to play with new architecture and methodologies. While they usually deliver the results, the code most often cannot be effectively supported by on-site developers because it is so radically different from what they know. The same thing can happen on a team with developers at different skill levels, and different views on the latest design patterns and methodologies.
The important thing is that ‘there is no “I” in TEAM’. Everyone needs to be able to understand and support all the code. If an architectural pattern makes software harder to understand, then the benefits of using that pattern may be outweighed by the maintainability of the code by the team. The team needs to decide as a whole on coding standards and practices.
One example of this is the heavy use of interfaces. Interfaces are great for decoupling code, but at the same time it makes it harder to follow since the implementer of the interface is “disconnected”. Using the Delphi IDE to navigate through code, by Ctrl+clicking in order to understand it, doesn’t work as it does with classes. This isn’t a shortfall of the IDE. There is simply no way it can know what objects are used to implement that interface (especially if you use injection).
The quality and maintainability of your code is directly related to the strength of the gatekeeper and the cohesion of the team. Better teams build better code…