4 ms·

Let process be implemented by those who practice it

31 points by curtis 16y ago

gcb 16y ago
Fighting chaos with well defined goals.
wccrawford 16y ago
There's a fine line here. Letting the chickens run the farm is not a good idea, but neither is letting the bank. In the company I work for, The CS Manager often dictates the workflow. If we let the CSRs do it, they'd pick the way that was easiest for them, but would ignore things that were less visible or useful to them. So their direct manager does the deciding. Whenever she outlines how changes to the system work, she always talks about how it'll improve their efficiency and how it'll improve the efficiency of the company as a whole. When work comes from the next rung up the corporate ladder, it's almost always about management's side of things instead. So you have to balance it all out, and have someone that can see all the angles. And let them decide on the process.
DanielBMarkham 16y ago
You can look at process as "a list of stuff we have to do" or you can look at it like "stuff we need to worry about" The first way, you are relieved of worrying -- you do the list, and the list thinks for you. The second way is much more difficult. The problem in big organizations is that different folks are worried about different things. That's why they keep making and giving out lists of stuff for people to do -- they don't want you screwing up. If you have a hundred teams and one of them takes down production for a day, I can guarantee you somebody is going to make a list of how-not-to-do-that-again, like it or not. We all know where this heads -- mindless trolls doing paperwork and following the list while nothing gets done. But it's important to realize how we get there too. There are no bad guys in this story. It's not just descriptive process that causes the problem, it's letting the "chickens run the farm" as one other commenter put it. There has to be some give and take. I wish you could throw out some kind of slogan and have an easy answer, but a lot of this is highly dependent on organizational culture, previous history, the people involved, etc. It depends. :)
- aaronblohowiak 16y ago
  risk aversion is a rational strategy when you have a lot to lose.
- draebek 16y ago
  >The problem in big organizations is that different folks are worried about different things. That's why they keep making and giving out lists of stuff for people to do -- they don't want you screwing up. If you have a hundred teams and one of them takes down production for a day, I can guarantee you somebody is going to make a list of how-not-to-do-that-again, like it or not. Why is it a problem to make procedures to avoid making the same mistake twice? In terms of "[taking] down production for a day" I'd prefer to make permanent changes to my systems so that I don't have to rely on procedure, but for those things that I can't or won't fix with more code or automation, making and following procedures to avoid e.g. unplanned service outages seems perfectly fine, even advisable? Of course this ignores the specifics of each individual situation, although I am having trouble imagining any product that I'd want me or my business to depend on that is also known to fail with any great frequency. (Even my home broadband Internet connection, for example, hasn't failed more than once or twice in the past year, and they have a veritable monopoly.)
da5e 16y ago
I think a way to avoid the negative calcification of descriptive process documents, would be to have those who use the document as a guide to append their own experiences using the document to that document for future implementers.
dotBen 16y ago
(OP link is worth a read btw despite how heavy it is presented, btw) This post articulates a bug-bear I've had throughout my career which is the pedantic "RTFM" culture in software - where no one wants to help anyone and instead gives them a pointer to a document (the 'Descriptive Process" as the author describes it). Proscriptive Process, actually sitting down with someone(s), not only is valuable for the reasons the author suggests (re-examining process, updating, refining, improving) but often new issues and idea and opportunities emerge from going over something together or in a small group. Sure, you can't do it all the time but there are loads of examples when it is valuable and should be considered part of the cost of development. I think it's sad when you enter a workplace where everyone just wants to tell you to RTFM all the time and no one has the time to sit down and go over anything. Ultimately, I don't believe its how good product/software is made.
curtis 16y ago
As a company scales, it becomes necessary to add or codify process. The key tradeoff under consideration is always whether the drag imposed by the process is worth the gains in efficiency or effectiveness. I kind of like "process drag" as terminology for the overhead associated with formalized processes. It sounds a little more pejorative than simply "process overhead". It might make a good addition to the lexicon, right next to "technical debt".

31 points by curtis 16y ago

gcb 16y ago

Fighting chaos with well defined goals.

There's a fine line here. Letting the chickens run the farm is not a good idea, but neither is letting the bank. In the company I work for, The CS Manager often dictates the workflow. If we let the CSRs do it, they'd pick the way that was easiest for them, but would ignore things that were less visible or useful to them. So their direct manager does the deciding. Whenever she outlines how changes to the system work, she always talks about how it'll improve their efficiency and how it'll improve the efficiency of the company as a whole. When work comes from the next rung up the corporate ladder, it's almost always about management's side of things instead. So you have to balance it all out, and have someone that can see all the angles. And let them decide on the process.

DanielBMarkham 16y ago

You can look at process as "a list of stuff we have to do" or you can look at it like "stuff we need to worry about" The first way, you are relieved of worrying -- you do the list, and the list thinks for you. The second way is much more difficult. The problem in big organizations is that different folks are worried about different things. That's why they keep making and giving out lists of stuff for people to do -- they don't want you screwing up. If you have a hundred teams and one of them takes down production for a day, I can guarantee you somebody is going to make a list of how-not-to-do-that-again, like it or not. We all know where this heads -- mindless trolls doing paperwork and following the list while nothing gets done. But it's important to realize how we get there too. There are no bad guys in this story. It's not just descriptive process that causes the problem, it's letting the "chickens run the farm" as one other commenter put it. There has to be some give and take. I wish you could throw out some kind of slogan and have an easy answer, but a lot of this is highly dependent on organizational culture, previous history, the people involved, etc. It depends. :)

aaronblohowiak 16y ago
risk aversion is a rational strategy when you have a lot to lose.
draebek 16y ago
>The problem in big organizations is that different folks are worried about different things. That's why they keep making and giving out lists of stuff for people to do -- they don't want you screwing up. If you have a hundred teams and one of them takes down production for a day, I can guarantee you somebody is going to make a list of how-not-to-do-that-again, like it or not. Why is it a problem to make procedures to avoid making the same mistake twice? In terms of "[taking] down production for a day" I'd prefer to make permanent changes to my systems so that I don't have to rely on procedure, but for those things that I can't or won't fix with more code or automation, making and following procedures to avoid e.g. unplanned service outages seems perfectly fine, even advisable? Of course this ignores the specifics of each individual situation, although I am having trouble imagining any product that I'd want me or my business to depend on that is also known to fail with any great frequency. (Even my home broadband Internet connection, for example, hasn't failed more than once or twice in the past year, and they have a veritable monopoly.)

da5e 16y ago

I think a way to avoid the negative calcification of descriptive process documents, would be to have those who use the document as a guide to append their own experiences using the document to that document for future implementers.

dotBen 16y ago

(OP link is worth a read btw despite how heavy it is presented, btw) This post articulates a bug-bear I've had throughout my career which is the pedantic "RTFM" culture in software - where no one wants to help anyone and instead gives them a pointer to a document (the 'Descriptive Process" as the author describes it). Proscriptive Process, actually sitting down with someone(s), not only is valuable for the reasons the author suggests (re-examining process, updating, refining, improving) but often new issues and idea and opportunities emerge from going over something together or in a small group. Sure, you can't do it all the time but there are loads of examples when it is valuable and should be considered part of the cost of development. I think it's sad when you enter a workplace where everyone just wants to tell you to RTFM all the time and no one has the time to sit down and go over anything. Ultimately, I don't believe its how good product/software is made.

curtis 16y ago

As a company scales, it becomes necessary to add or codify process. The key tradeoff under consideration is always whether the drag imposed by the process is worth the gains in efficiency or effectiveness. I kind of like "process drag" as terminology for the overhead associated with formalized processes. It sounds a little more pejorative than simply "process overhead". It might make a good addition to the lexicon, right next to "technical debt".