"Capturing requirements is pretty useful and having a repeatable, reproducible way of doing this is also useful. Need to take over some other person's 3 year old steaming pile of spaghetti? Requirements are a good start. Need to replace a home-grown system with a market solution? Requirements are pretty useful in negotiating a contract with the vendor (unless you don't mind the vendor nailing your balls to their invoice because you couldn't actually tell them what you needed their software to do)."

Yes, IF your contractor is COMPETENT ENOUGH to give reasonable requirements. In reality this rarely happens. And while you can point a finger at them, that their requirements were stupid, they will think you just deceived them. They will pay you, but they will not come back.

I agree with you except:

This is FALSE. In fact, "institutional causes" are ALWAYS lack of communication, lack of REAL teamwork, lot of ass-cover, responsibility avoidance, bureaucracy and fear. This is exactly CAUSED by such processes.

AAAAAH! Now I remember! Now I remember all the pain! These memories were suppressed, and buried deep down in my mind... This explains all the nightmares. Oh God. I need a therapist.

If I understand correctly, you can run your own Diaspora server, is it right?

Well, then there must be a protocol to communicate between Diaspora servers. If that protocol is sound, then I will just write my OWN server with all the security features I need.

Do we know anything about the security of the protocol? I am more interested in that not in the security of the webapp.

Erdos Pal
http://en.wikipedia.org/wiki/Erdos_Pal (I cannot reproduce Hungarian umlaut in slashdot)

Although an amphetamine taking mathematician is maybe not the best hero for an 8 year old :)

Yeah, and this mechanism hinders deep research. The problem is that the most interesting research subjects are also the riskiest ones. You cannot publish papers on failures, therefore you are highly pressed to go for the low hanging fruit. This means that journals will be full of the (n+1)th refinement of a well known algorithm/technology/formula/theorem.

We need more scientific risk-taking.

It is great to see that we can produce scientific puzzles in the 21th century that are based on simple mechanics (no quantum theory, no higher math), and confuses the hell out of a lot of knowledgeable people! Really intriguing!

I wanted to write v_2 (lowerthannorequalto) v_1, but slashdot swallowed the relation sign.

It is interesting how people always come to conservation of energy, but they talk about speed at the end. They basically say "hey, if wind blows at v_1 relative to the ground and your cart goes at v_2 only gathering energy from wind, then v_2 = v_1 must hold (at least in the infinite), because otherwise we would have a perpetum mobile". Now the only problem is that speed is NOT energy, so relation of speed between an energy source and a worker depending on the source does not matter by itself alone.

If you interpret the manifesto in the original context in its own age, you will understand that documentation means there not "developer documentation" or "user documentation" but the various "project documentation" artifacts that were the holy grail of that age.

The same is true for processes. It is not about the small scale ones (source control, review processes, whatever), but the overengineered project processes prevalent in that era.

If you read the original manifesto, it is very carefully worded. It does not say "abandon processes", it says that the priority should be on the developers as creative individuals, instead of mechanized drones.

Also, it is not against "processes" (with small "p"). A build system is itself a process, a source control software also enforces a process. The manifesto is against Process with a capital P. It is hard to explain, but easy to give an example what I mean about this:

http://www.ogcio.gov.hk/eng/prodev/es3.htm

The above link is about the SSADM Process. Read it and you will immediately understand what I mean.

Also, lot of people misunderstand "Working code over documentation" and think that documentation is not important. In fact, it should be read primarily as "project documentation", the things that most old fashioned processes mandate. Again, look how many and what kind of docs SSADM needs.