How Do Committees Invent? (1968) | Hacker News Reader

How Do Committees Invent? (1968)

melconway.com

42 pointsmike_ivanov9 comments

As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization. This is an inappropriate motive in the management of a system design activity. Once the organization exists, of course, it will be used. Probably the greatest single common factor behind many poorly designed systems now in existence has been the availability of a design organization in need of work.

This is a great point, and it's not widely understood. Organizations always try to grow, and once they've grown, they will continue to do work, regardless of whether that's what anyone actually wants or needs them to do.

For example, say a popular website has gone a long time without much design work, and people are complaining that the site is hard to use. In response, the people in charge of the website form a design team, which succeeds in redesigning the site. But now that there's a design team, they will continue to do design work, and the site will likely be redesigned periodically. This will happen regardless of whether anyone actually using the site wants a new design.

From my experience, Facebook described to a T. I have a hunch you were thinking of the same site. Any other examples? I'm struggling to find any other examples that are as compelling

I think is this also what happened at Microsoft to cause them to put out a new programming framework every 18 months. They got some huge architecture team together to design .net, but then never disbanded them.

A new programming framework every 18 months? Is that an exaggeration? Teams are fairly dynamic; e.g. many of the .NET people went over to do Typescript. Then there is something like WPF that hasn't moved much recently (for better or worse).

Also, users really like the fact that there will be a new version of C# with more features (async, pattern matching, etc...) with some continuity.

To put it differently, committees don't invent. People invent. Committees coordinate (or gather, edit, filter, etc.).

So if three people invent three things, and they form a committee to put the parts together, then they typically end up with a thing having three parts.

This way of looking at it makes it all seem much less mysterious and profound, IMHO.

That's a much better way of thinking about it.

The real problems I've seen emerge when there is a clear mismatch between the organisational structure and the obvious (to everyone) solution to the problem involves altering that structure, even slightly. At that point everything becomes impossible.

This is the most practical and important paper I have read this year, and I'm doing a masters in Information Systems.

Maybe this is the true reason why Google lets engineers rule ?

Restricting them in hard ways essentially implies that the software produced would just reflect the final bureaucracy?

There's no way around the rule though, if the communication is ad-hoc it might be better than being dictated by clueless bosses, but everyone is still operating with imperfect information, just at a different level. Witness the chaos of their login systems before the sound of the Google+ battle horn.

Reply on news.ycombinator.com