What Developers Can Learn From Anonymous

snydeq writes "Regardless of where you stand on Anonymous' tactics, politics, or whatever, I think the group has something to teach developers and development organizations,' writes Andrew Oliver. 'As leader of an open source project, I can revoke committer access for anyone who misbehaves, but membership in Anonymous is a free-for-all. Sure, doing something in Anonymous' name that even a minority of "members" dislike would probably be a tactical mistake, but Anonymous has no trademark protection under the law; the organization simply has an overall vision and flavor. Its members carry out acts based on that mission. And it has enjoyed a great deal of success — in part due to the lack of central control. Compare this to the level of control in many corporate development organizations. Some of that control is necessary, but often it's taken to gratuitous lengths. If you hire great developers, set general goals for the various parts of the project, and collect metrics, you probably don't need to exercise a lot of control to meet your requirements."

Comments

What the group has to teach

[Anonymous Coward]

What the group has to teach is simple: If all you want is to disturb the normal process, and highlight certain aspects, then you don't need much organization.

Wake me up when anonymous actually produced something non-trivial.

Depends on your requirements

[melonman]

I was reading "The mythical man-month" only this weekend, which starts with the observation that "everyone knows" that two kids in a garage can do more than a corporate development team, and then points out that, if this was actually true without caveats, corporations would hire two kids in a garage every time. There's a difference between producing a standalone program and developing/maintaining a product system.

Re:Depends on your requirements

[Missing.Matter]

What you've just said is something many entrepreneurs find out too late: that ideas are dime a dozen, and execution is what really differentiates successes from failures. Strong organizations differ significantly from "two kids in a garage," in that they have people who are experienced in execution and all it entails including: capital management, marketing, legal, supply chain, distribution, manufacturing, personnel, security, infrastructure etc. These things all need to coordinate with R&D and work on specific timelines to sync with departments, and this is all happening in parallel. Two guys in a garage operate serially, so management isn't really needed.

I know most people here are developers, so most of us see the world in developer-colored glasses, so saying things like "Just hire good developers and let them loose and they'll churn out good work and you'll be a success." is just plain wrong. They'll do what good developers do: develop. And that might be enough to make a good product (or in some cases a good prototype or preproduction product), but it's not enough to make a successful product. This is also why the "two guys in a garage" stories are few and far between; their efforts were met with a good deal of luck and happenstance which drove their success. Right place, right time sort of stuff. Everyone else with the next big idea in their garage met with failure because they lacked execution.