Committees Dont Code

This is the worst and the most evil of a series of AntiPatterns such as ArchitectsDontCode and AuthorsDontCode.

But if the impact of architects and the book authors is significant, the impact of a committee can be disastrous. If you don't know what I'm talking, it's about standard committees. 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, and many many more goodies.

What is worse, if we can work around ArchitectsDontCode and AuthorsDontCode, working around a committee who doesn't code is almost an impossibility.

The committee isn't really the problem. 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.".

Well, the committee is, on the contrary the heart of the problem, because they own the supreme influennce in the industry. Trying to work around the work of the committee is an uphill battle, almost guaranteed to be lost. Because the chief architects, project managers, VPs of development and the likes are not going to argue with you on the merits of a committee's fine crafted PDF, they will be sensitive only to the millions of dollars invested in the marketing of the standard. But having pages like this on wiki, might help, just a little bit.

Over the years, projects are likely to fail and bad standards are likely to disappear because the lack of tangible results will lead the same architects, managers, VPs to the next FadOfTheDay?. But that is not a good enough consolation.

Still, it's the "authorities who don't code" who make the decisions to form the committees, and to accept the results. Committees only have the power that is ceded to them by others. ArchitectsSitOnCommittees?, and ArchitectsChooseStandards?, and so we can still put the blame on them. --KrisJohnson

Example of committee work that made my life a lot harder than it needs to be : EnterpriseJavaBeans, SQL, UML. For all of which I have good reasons to believe that their authors didn't directly suffer the consequences of their own work, that is having to used their standard in their day to day professional activity. --CostinCozianu

I think 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. The authors of the specifications can then write books to explain to the confused masses how to do something useful with the flawed standards. -- KrisJohnson

In all fairness, I have to mention some fine pieces of work produced by committees over : ADA '83 and ADA '95, CORBA , which are arguably among the good things that happened in the industry.

C and C++ standards are good enough examples, but the committees decided only the shape of the standard, not necessarily the substance.

Actually CORBA is a perfect example of CommitteesDontCode. The first CORBA standard specified things that were completely useless and impossible to implement in any sane manner. For example, the C++ language mapping for the Any type could only be used to hold values of structs that were available to the program at compile time. The whole point of the Any type is to pass any value to a method, including those that are not available at compile time. The specification made it impossible to send Any values to objects that use types that are not compiled into the client program. Worse, it was impossible for servers to decode structs received from clients if the definition of those structs were not compiled into the server , which opened up a source of communication errors that could not be worked around.

Many (not all) committees are staffed with members whose primary purpose is to ensure that their employers' technology (good or bad) gets standardized on. Even if the employer is not in a position to collect royalties; a company will reap lots of benefits from having its technology standardized.

And many committee decisions are based essentially on business negotiations.

Unfortunately, committees of any importance have to deal with the business community if they are going to be at all relevant...

That said, producing a technical standard of any size that is useful is a tremendously difficult job, whether for a committee or for a small integrated team of developers (or a solo developer, for that matter).

ModelDrivenArchitecture is a perfect example of CommitteesDontCode (and they never want to code ever again).

CategoryAntiPattern