The Tyranny of Process Worship Within IT
ciopedia.com
The Tyranny of Process Worship Within IT
1–10 of 22 posts
Re: The Tyranny of Process Worship Within IT
#2I think we need to create an approval process for processes so that we can slow down the creation of processes.
Re: The Tyranny of Process Worship Within IT
#3I think we need to create an approval process for processes so that we can slow down the creation of processes.
[deleted]
Re: The Tyranny of Process Worship Within IT
#4The 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
Re: The Tyranny of Process Worship Within IT
#5The 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…
[deleted]
Re: The Tyranny of Process Worship Within IT
#6The 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…
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.
Re: The Tyranny of Process Worship Within IT
#7I think a distinction needs to be made between actual process and codified process. The former always exists, and the only question is whether it is working or not. The latter is endemic to large organizations with disaffected and mediocre management and employees, which is what Netflix is actively fighting against.
However the tone of this piece and the original Netflix manifesto does not acknowledge this distinction. I think this shows a bias that is driven by product-oriented software engineers and creatives. "If the product is great then who cares how we got there?" Well that's certainly a valid viewpoint, however it shortchanges great management. Great management is not done by simply hiring the best people and turning them loose on a project. That works in a startup where everyone knows each other and so any two people can notify each other of relevant issues. It doesn't work in larger organizations where individuals have a much narrower slice of responsibility and thus lower visibility on the whole actual process going on.
I've worked with some people who take a process-oriented approach and were very talented at getting the best work out of their employees. For these people it's no more about rigid codified processes than it is about a relentless focus on product. Instead, the goal is to understand at a high level what all the various stakeholders are doing, where their individual bottlenecks are, and determining a process that maximizes everyone's productivity. People like this are incredibly valuable, because let's face it, management is much harder than programming to do well because you are not a domain expert in anything, instead you have to figure out how to help all the different domain experts operate efficiently.
I realize none of this is news to the folks at Netflix, but I think the way the manifesto is written de-emphasizes these facts to the point that the inexperienced or low-level programmer may miss the forest for the trees, which incidentally is exactly what the problem with bad actual process is.
Re: The Tyranny of Process Worship Within IT
#8I voted this up immediately after reading the title.
Re: The Tyranny of Process Worship Within IT
#9The 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…
[deleted]
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.
Re: The Tyranny of Process Worship Within IT
#10"We should focus on what people get done, not how many hours or days are worked. Just as we don’t have a 9-5 day policy, we don’t need a vacation policy."
While I admire the sentiment, it's rather anti-family.