Monday, March 10, 2008
When Governance and Best Practices become antipatterns (Part Two)...
Continuing yesterday's posting...
If developers aren't spending sufficient time writing software, then it can also be said that governance committees are actually a bigger antipattern. Billion of dollars wasted in unsuccessful projects based on crappy standards, very good and sound technologies put on the sidelines because they don't fit within the committee's narrow view of the world.
To govern is to talk about behavior models and not processes nor approvals. The funny thing is that governance committees need to understand that while their charter is to help improve quality, reality says that they may be making high quality valuable secure working software even harder to obtain.
A committee may produce crap, but knowledgeable people will know to avoid it. The problem is when other "authorities" (architects, authors, etc.) insist that you use the flawed specifications produced by the committees, for no reason other than "It's a standard.".
Awhile back, I was talking with a developer that worked for a company in the neighborhood about the standards imposed on him. He was talented and understand that there were better, faster and cheaper ways to realize the goal of the business, but he was handcuffed by governance.
If you have ever interacted with folks who create standards for your enterprise, can you honestly tell me you understand them all? Many standards are used and understood only by their authors. The authors take whatever quirky ad-hoc "solutions" they have created and push them through committees to be standards. The authors don't see the problems (or just deny them), and the committees don't have sufficient time/expertise to review the proposals thoroughly. Many committees are under a lot of pressure to approve something as quickly as possible so as to not appear as an impediment yet at some level that is what they are best at...
| | View blog reactionsIf developers aren't spending sufficient time writing software, then it can also be said that governance committees are actually a bigger antipattern. Billion of dollars wasted in unsuccessful projects based on crappy standards, very good and sound technologies put on the sidelines because they don't fit within the committee's narrow view of the world.
To govern is to talk about behavior models and not processes nor approvals. The funny thing is that governance committees need to understand that while their charter is to help improve quality, reality says that they may be making high quality valuable secure working software even harder to obtain.
A committee may produce crap, but knowledgeable people will know to avoid it. The problem is when other "authorities" (architects, authors, etc.) insist that you use the flawed specifications produced by the committees, for no reason other than "It's a standard.".
Awhile back, I was talking with a developer that worked for a company in the neighborhood about the standards imposed on him. He was talented and understand that there were better, faster and cheaper ways to realize the goal of the business, but he was handcuffed by governance.
If you have ever interacted with folks who create standards for your enterprise, can you honestly tell me you understand them all? Many standards are used and understood only by their authors. The authors take whatever quirky ad-hoc "solutions" they have created and push them through committees to be standards. The authors don't see the problems (or just deny them), and the committees don't have sufficient time/expertise to review the proposals thoroughly. Many committees are under a lot of pressure to approve something as quickly as possible so as to not appear as an impediment yet at some level that is what they are best at...
