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.
Thanks for the comment. no, I'm actually not even talking about the process of building software, (as I stated in the post), and am anything but a "cowboy". I'm talking about all the dozens of other processes that add zero value to the product, that are put in place with the best of intentions, and add all kinds of cost....things like spending 30 minutes a day tracking time for every meeting attended against an activity/project, multiple processes taking weeks for acquiring a server, weeks spent in generating documents that are not even looked at by others, etc... hopefully that makes sense.
Common focus is one thing; changes should be driven by a concrete external goal that is shared by all parties. You don't push code because it's Thursday, you push code because it's got new feature X that matters to client Y.
A culture of humility is also important; Ops/IT people build walls of process when developers chew them out for mistakes, which only gets worse when a chunk of those mistakes (but not all) end up falling on the developers. At most shops, when there's a problem, this is the general flow of things:
1. The software got updated on the site, and now customers can't access anything, but everything looks to be running.
2. Sales/Management/CS scream to fix the problem.
3. Ops blames Dev, and Dev blames Ops.
4. After the problem is fixed, Ops adds new process to make sure this problem doesn't happen again.
When, in my perfect world (and at both places I work, for the most part), it goes like this:
1. The software got updated on the site, and now customers can't access anything, but everything looks to be running.
2. Sales/Management/CS scream to fix the problem.
3. Dev and Ops both say, "We might have screwed up, let's dig deeper...", find the problem and fix it.
4. Whoever found and fixed the problem gets a beer.
This can't work unless you've got a company culture of "fix the problem, reward the fixer", rather than the prevailing culture of, "nail the responsible party to a tree."
Finally, getting out of the ivory towers is also really important. Dev people need to realize that their mistakes cause serious grief for the Ops guys, and the Ops people need to realize that making life harder for the developers through over-regulation (not having local admin, etc) causes equal pain. Mutual respect, which comes from working together, is important.
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