

The Process Myth - filament
http://www.randsinrepose.com/archives/2013/01/01/the_process_myth.html

======
btilly
One of the problems with process, the best intentioned process, is that you
always create perverse incentives.

For instance take the transfer process that was being extolled. The incentive
now is for managers to evaluate their best employees poorly, and mediocre ones
highly so they will keep their best and lose their worst. Many people who have
worked in large companies have seen this first hand.

Secondly there is a very real problem of fit between the person and the job.
If a person is not doing well, and the problem is fit, then the transfer
restrictions will leave no place for that person to go but out of the company.
As a concrete example I offer SRE at Google. They need an unusual mix of "able
to program, but sysadmin mentality". So Google tends to hire one skill set and
hope that they get the other. But when they don't they may get a perfectly
good software developer in a role where they won't do well. This is a loss for
everyone.

The result is that even well-intentioned and supposedly good processes result
in routine bad decisions. If this bothers you, then you probably do not want
to work in a large company.

~~~
SoftwareMaven
I think _always_ is overstating things a little, but you are right that you
have to be very aware of perverse incentives and, the more process you bring
in, the higher the likelihood that your process will interact in strange,
unexpected ways to create those perverse incentives.

~~~
btilly
If you think that always is overstating things a little, can you give me an
actual example of an actual process at an actual company that creates no
possibility of perverse incentives?

~~~
SoftwareMaven
"All commits should have a message and commit messages should be explanatory."

This is an actual process in my group at the company I work for.

Process doesn't _have_ to be heavy and invasive.

And what's the alternative? Zero process? Everybody has to "wing it" all the
time? I can't see any possibility for a perverse environment there!

~~~
btilly
Who defines what "explanatory" means? And what is the resolution if there is a
disagreement? I, personally, am happy with a commit message like, _Refactoring
needed before #12345 can happen._ I've said what I was doing, and why, and
presumably in your ticket system there is a ticket 12345 that has more
detailed explanation. Other programmers will disagree. "Explanatory" means
different things to different people, and complex arguments can erupt.
(Conversely if your commit essay lacks a concise first line to show up in
blame, is that explanatory? Should you always have a ticket #?)

Furthermore there is a type of person who enjoys asserting power through
language lawyering. That kind of person will see that policy as a golden
opportunity to acquire influence, even though the cost may be unnecessary
conflict to little point. If such a person manages to assert control of a
process element like that, you can easily get a type of teamicide that drives
away good developers who don't want to deal with the BS of figuring out
whether their essay was good enough to avoid an email lecture.

As for the alternative, I thought I was clear on that. Large groups cannot
work without process, small groups can mostly get by on common sense. The
imperfections of processes do not change their necessity in many cases. But if
you, personally, do not enjoy dealing with process, then you should find
opportunities to work in more congenial small groups.

------
SoftwareMaven
The biggest mistake I see in the process train is not "trying to fix
something" but, rather, not keeping track of "what don't we want to break".
Whenever I start thinking about process, I build two lists of requirements:
what do I want to fix and what do I want to not impact. Without both, it's
easy for process to grow like a gray goo[1], gobbling up all the useful
culture in the company and leaving a company devoid of life.

(I expand on this idea on my blog[2], if you are interested.)

1.<http://en.wikipedia.org/wiki/Gray_goo>

2\. [http://softwaremaven.innerbrane.com/2010/03/preventing-
proce...](http://softwaremaven.innerbrane.com/2010/03/preventing-process-goo-
or-how-to-keep.html?m=1)

------
rpwilcox
Process is a great tool - and if used properly -can keep teams more efficient
and maybe even propagate some culture or history.

And then Rands touches on something important: every time there's a new policy
addition in the office engineers groan. Why?

* Because a manager is going to try to "fix" something (and will probably make things worse). ("Yes, we know the bug tracker sucks, but (sarcasm) yes blame the _developers_ when the requirements change half eay through implementing the ticket")

* "If you listened to us in the first place... We wouldn't be overworked and making these mistakes you're compensating for"

* The "green lieutenant" problem. (see any war movie for this)

See enough of those and yeah you'll roll an eyewhensome manager bursts into
the door with a great idea... Especially when asking "why?" too mny times
certainly will get you branded as a trouble maker.

------
sopooneo
I find that many _policies_ (I'm not sure if they might overlap with
processes) are actually the hidden tales of past disaster.

~~~
mpyne
In the Navy (submarines) we would always say that "such-and-such procedure is
written in blood"... and often it was. Either blood or millions of dollars
worth of damage and time wasted.

------
michaelochurch
This is syphilitic nonsense. His defense of bad internal mobility policies
spoiled the whole thing. It seems like he's trying to defend moronic decisions
made in large companies as if there "must be" a decent underlying reason for
them. Sometimes, there's not. The Just World Hypothesis is a neat way to trick
yourself into believing some insane shit that has no basis in reality.

If you're not an execrable fascist, you realize that performance review
history part of the transfer packet is a Bad Fucking Idea. This Enron-style
"innovation" was intended to intimidate people into working harder. What it
actually did was give managers incentives to give inaccurately bad reviews:
keep the fuckers captive with negative ratings. Bonus points if people don't
know what their exact ratings are and therefore can think they're receiving
acceptable ratings (cf. Google's secret calibration scores).

I'm sorry, but the absolute _first_ thing you need to assess when it comes to
process is: _how will this shit be abused?_ If the system entrusts a single
individual (in the internal mobility case, an employee's manager) to be
ethically decent, with serious consequences to others if he's not, it will
probably fail.

The real purpose of these bad HR practices (transfer blocks, global stack-
ranking, political-success-I-mean-"performance" review history as part of the
transfer packet) is to create a false objectivity that leaves badly-treated
employees _falsely_ believing they have no legal or publicity recourse.

The vast majority of terminations don't go to court, but companies want to
avoid bad publicity as well. The real purpose of a severance is to leave the
employee feeling good about the company, despite the separation. The purpose
of a PIP is to make the employee feel _bad_ about himself. This is because
people are most likely to seek recourse when they perceive a sort of moral
superiority. HR's job is to frame events so that people don't have this sense
of righteous indignation. A severance brings the company up; "we can still be
friends". A PIP brings the employee down; "you have no recourse, because
you're shit and I'm champagne".

People who look at bad HR practices and ascertain noble or neutral intent are
missing the bulk of the picture. Most powerful people in most companies are
just bad human beings whom a less emasculated society would do something
about. It really is that simple.

------
Swannie
Very nice article. My primary question: when I need to document the process,
how do I best encode the culture and values into the document?

Should I aim to explain the values that we're upholding (code quality,
documentation quality, test quality, etc.), in every step?

~~~
vinodkd
My takeaway from the article was exactly that: if you document anything,
document the WHY, not the HOW. That way, when the HOW changes with time, the
WHY will guide its new form.

Agreed on the quality of the article. As always, Rands manages to put the
right perspective on the topic. I'm forwarding to quite a few process-averse
folks I work with.

