Avoiding all of the analogies... I'm on the technical side, and there's non-trivial work involved in evaluating the quality of the work of other developers. Pa

Avoiding all of the analogies... I'm on the technical side, and there's non-trivial work involved in evaluating the quality of the work of other developers. Particularly for sniffing out security problems... you're fighting a many-headed beast, so unless you're quite technical yourself (and know how to exploit the whole OWASP list, for example), I can't imagine how you'd evaluate someone else's statement that "yes, this will be secure"; even if the lead developer can talk in depth about 10 common security holes, what if s/he simply isn't familiar with #11 and #12? Or lacks the creativity to notice how an architecture choice will severely hamper security in the future? There's non-trivial work involved in evaluating my own work, and every now & again when I step back to view my own approach to a technical problem I change course. So -- it's certainly possible to evaluate developers without being technical, but you're still forced to trust their diligence and skill quite a bit. "Talking the talk" of doing things right technically isn't very hard (just read a lot of dev blogs... you'll pick it up); actually doing them right with some consistency is a different beast entirely, and not everyone succeeds even with the best of intentions (...but this is much harder to evaluate).