I've been credited with coining the term "do-ocracy." When I've had the opportunity to lead an open source project, I've preferred to "run" it as a do-ocracy, which in essence means I might give my opinion, but you're free to ignore it. In other words, actual developers should be empowered to make all the low-level decisions themselves.
When you think about it, the hacker group Anonymous is probably one of the world's most do-ocratic organizations. Regardless of where you stand on Anonymous' tactics, politics, or whatever, I think the group has something to teach developers and development organizations.
[ Robert X. Cringely offers another take on what we learned from Anonymous. | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
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.
Is it possible to apply do-ocracy outside of open source and hacktivism? Not to the same degree Anonymous does, but in moderate amounts, it could improve the overall quality of our software and our jobs.
Vision and culture rule Anonymous members pick targets and carry out actions based on the general vision and culture of the group. Whether in a do-ocracy or not, vision goes a long way.
Some years back I worked for a network equipment company. It was probably one of the worst jobs I've ever had, complete with rows of beige cubicles highlighted with sickly green trim. Not only was I told to write my Java classes mostly in caps, with few files and minimal whitespace, but each day we had hours of conference calls with a team in New Jersey. Our computers were vintage and our shell connection was slow. The "vision" was to try and catch up with whatever Cisco was doing.
Internally, the project was considered a success, but to me it was clearly a failure. I'd be shocked if the company kept a single customer from leaving, and I'm virtually positive it didn't land new ones. The website was horribly confusing and unattractive. It was intended to be a B2B site. The dilapidated culture of the company and its hollow objective coupled with a bizarre need for control yielded predictable outcomes.
Consider how Anonymous works. It started with a general vision of anarchistic attacks against centers of power. Over time, this has become specific to punishing "bad behavior" and grabbing attention. There is no five-year plan (that we know of). Something happens, folks come together -- in an IRC chat or other medium -- and collaborate on their work. Despite the lack of an overall plan, tactical successes occur.
On the other hand, lack of a plan causes Anonymous to be a slave to the news cycle. While I'm not saying its activities at the height of the Arab Spring didn't contribute, key strategic objectives were not accomplished -- for instance, the repeated calls by freedom fighters to bring down Gadhafi's satellite TV channel. This is where a plan would be helpful. I've seen a lot of organizations function with neither shared vision or a plan. I've yet to see a successful software project without both.
Control has its limits Many managers believe that if they aren't getting the results they want, they can just put pressure on the team. But as a developer who's transitioned to a management role, I can tell you that the more I push that button, the less effective it is.
Consider the misadventures of our hacker anti-heroes. Where Anonymous has had a central nerve, it has been attacked, which has led to arrests. The effects have trickled down and negatively affected the group.
We can also see this in server architecture. There are still clustering platforms managed through a central server -- the weak point in everything from Hadoop to WebSphere. Yet we're watching the evolution of these architectures away from central control. This results in less predictability in some circumstances, but makes them more robust in the long term.
That metaphor is transferrable to the management of software projects. Yes, setting expectations, establishing norms, and spurring motivation can have great positive effect and avert crises. I am not advocating for anarchy. But the loose affiliation model of Anonymous, an organization notorious for wreaking chaos, has more to teach than many of us would like to admit.
This article, "What developers can learn from Anonymous," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.
Read more about application development in InfoWorld's Application Development Channel.
This story, "What developers can learn from Anonymous" was originally published by InfoWorld.