The problem here is that everybody thinks that they're talented superstars, and they don't need to have to worry about rolling back a version, or testing, or any of those other dreaded bits of 'process'. Which is another way of saying, "putting some steps in place to cope when you inevitably screw up."

This piece sounds like it's written by some cowboy who wants to move fast, and be all agile and light. These people are also nominally nowhere to be found at 4am when their undocumented change brings down the production server farm, and then I have to get up and fix it... which is all kinds of fun.

The fundamental problem is that most shops are organized with 'IT', 'Operations', and 'Development' all being very separate camps.  There's no mutual respect, and plenty of blame, so massive piles of process get created as a means of defense for the Ops and IT guys, who get screamed at every time there's a problem that hits the customers.

There's a really good talk on why this is bad from the Velocity conference, here: http://velocityconference.blip.tv/file/2284377