* Peter Rabbitson <rabbit+d...@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/> _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk