[Dbix-class] 5/5 Why "a stability tzar" is a ridiculous proposition

[Aristotle Pagaltzis]

* Peter Rabbitson <rabbit+dbic at rabbit.us> [2016-10-11 17:28]:
> Additionally stability on its own isn't tangible, nor does it yield
> a final product. It is simply a mindset. When this mindset is not
> represented in the group as a whole, it makes no difference whatsoever
> whether a small part of said group is advocating it or not.

This might be easier to explain by analogy to a hypothetical notion of
a “security czar” in a project where all the active contributors treat
security as a check list item somewhere in the medium-priority section
of their personal list. I assume it to be fairly obvious to all by now
why appointing such a security czar will lead to no real improvements
in the security of that project.

And to reiterate the analogy in another area where this principle might
be somewhat widely recognized nowadays, in order to show that neither
stability nor security are special snowflakes: the same is true of
product design in teams that treat design as something you sprinkle on
after most of the work is done. Having a design czar won’t yield much
improvement in design for the end user. (Free software has demonstrated
this regrettably clearly and consistently…)

A sidecar can’t steer the vehicle.

The position of a czar is reactive and disempowered. They can only fire-
fight individual issues as the project hurtles forward headlong.

If you want real security or actual good design, it must be part of the
culture: it must pervade every choice, every judgement call. Otherwise
you get zilch, or maybe a veneer. Just the same is true of stability, or
any other similar value.

(And in fact, any time a whatever-czar is appointed I would worry that
the presence of such a role will tempt the rest of the team to slack off
in their own consideration of the faux-delegated concern. If the role of
that person is a mentor rather than a czar – then that is an arrangement
which might work. But it requires willingness of every other team member
to actually be mentored and carry that concern personally, as opposed to
e.g. considering the project to be trying too hard to be secure or well-
designed, relative to everyone else in the same ecosystem.)

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>