Slashdot Mirror
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."
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.
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.
Virtually serving coffee
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
This is standard common sense, and the negative effects of over/micro-managing and red tape are recognized (and felt) not just in software but in all endeavours (even within families.) We know what to do about that in all forms of organizations and projects.
That people and project still fall far from the well-known solutions, that has more to do with human behavior, team dynamics and the economics of the incentives/rewards, disinsentives/penalties, (whether tangible or psychological, subjective or objective) than anything else.
Anonymous, with its faceless nature (that precludes the realities of disinsentives and penalties), and incoherent goals, has nothing to teach us or anyone engaged in a real-life project or mission subject to incentives and disinsentives, and the realities of identifiable human relations.
The article might be good to drive traffic (ZOMG, Anonymous in teh titl3!), I'll give the author that </journalistic-attention-whoring>
Exactly, in most corporate environments you have to go through so many bosses (most of which shouldn't be making technical decisions) before you can ever get anything done.
Citations please. True that those organizations exist, but in my experience, they are the exception rather than the rule. Obviously, saying that most companies are like that makes good stuff for posting in teh slashdotties water coolers, but c'mon.
I remember a /. comment from a week or two back that mentioned a colleague/peer who was told he had to submit reports on the number of new lines of code produced every week. Through editing and refining the software, he ended up with a net loss of 20,000 lines of code (and submitted -20,000 in his report). Ultimately, he ended up submitting weekly reports that didn't really "mean" anything-- but was never questioned because his work was good and profitable.
Just this week my supervisor was gone on vacation. Our department ran more smoothly than it has for months because my peers and I took care of all our necessary duties and paperwork without having to deal with the stress of a boss fretting about reports getting submitted and said boss being fired for insufficient job performance.
However, while the principle holds true, I think there are guidelines required for it to be the most practical principle by which to run a company/department. For example, employees need to have firm directional guidance for their work-- just no heavy-handed iron-fistedness.
The only lesson here is that creating chaos doesn't require any kind of organizational structure (which is almost tautological). Producing something orderly is a whole different question, and unless you happen to have an infinite number of monkeys at your disposal, the chance of that happening in a finite period of time is pretty damn improbable.
http://alternatives.rzero.com/
And it has enjoyed a great deal of success - in part due to the lack of central control.
But Anonymous hasn't really done anything that requires the true contributive efforts of more than a few people at a time. LOIC doesn't count, because "here, run this" isn't in the same ballpark as actually contributing code to a project. The person/people who wrote LOIC still exercised control over the actual software and made decisions about what features went in and what didn't.
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
This is standard common sense, and the negative effects of over/micro-managing and red tape are recognized (and felt) not just in software but in all endeavours (even within families.) We know what to do about that in all forms of organizations and projects.
That people and project still fall far from the well-known solutions, that has more to do with human behavior, team dynamics and the economics of the incentives/rewards, disinsentives/penalties, (whether tangible or psychological, subjective or objective) than anything else.
Anonymous, with its faceless nature (that precludes the realities of disinsentives and penalties), and incoherent goals, has nothing to teach us or anyone engaged in a real-life project or mission subject to incentives and disinsentives, and the realities of identifiable human relations.
The article might be good to drive traffic (ZOMG, Anonymous in teh titl3!), I'll give the author that </journalistic-attention-whoring>
Micro-management shouldn't be the object. The object should be to develop a system to distribute best practices.
First, best practices care about a lot of things beyond management. Secondly, best practices cannot be defined without first having something to compare (favorably) across an spectrum of things, and not just one spectrum, but a multiplicity of them (coding, process, management, etc.) In the management spectrum, micro-management sits on the polar opposite of management-related best practices. Ergo, one cannot describe or study best practices without first identifying and understanding the pathological case one has to avoid (at best) or directly deal with (at worst): in this case, micro-managing.
This could apply to Anonymous or to software development where more experienced workers can share their best practices with less experienced workers.
But herein lies the problem: anonymous and software development are not comparable, not unless you want to stretch the definition of problem statement. But that's just Reductio ad Absurdum just to fit an argument.
The other is to focus on the process of making critical decisions. The problem of decision making can only be solved by developing a methodology of decision making along with some basic rules to follow when making certain types of decisions.
Which problem of decision making are we referring to here?
If this is Anonymous then it's what is a legitimate vs illegitimate op. Emphasis should be on the process of decision making so that there is a standard process or guideline for choosing an op.
How does this draw lessons for software development, and to general projects and missions with identifiable players? Is it a legitimate argument that requires Anonymous as an example (which is what the article says, remember the topic)?
If it's software development then developers need to know when to use certain designs and when not to use them or when certain tools work best and not others.
But that's a myopic view of software development because software development does not work in a vacuum. There is an organizational context at play that will guide (or force) a developer's hand into what choices to make. One cannot talk about the former without considering the later.
Comment removed based on user account deletion