in reply to Re^3: Some reflections on the Brainbench Perl Test
in thread Some reflections on the Brainbench Perl Test

Re-read those questions and adjust them (to remove the "agility paradigm" bias), for (your perception of) a well-run, tight-knit, mature development shop using any particular development methodology (set of established and proven working practices), and, if you can get them too waste their time answering those questions, they'll likely score highly.

The primary goal of any development procedure: is having one.

The (slightly) secondary goal: is using it.

The tertiary (but still of Xtreme importance): is that methodology does not consume an overly substantial part of your budget, at the expense of your primary goal.

When the process outwieghts the product, you are measuring the wrong statistics.

There is no substitute for competent (not gifted or clever) programmers, who work hard, to achieve the primary goal.

Experts in secondary goals seek only to emphasis their expertise, and maximise their value, even to the deteriment of that primary goal: achieving a working solution to the primary problem description.

When the process become more important than than the goal--all is lost.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^4: Some reflections on the Brainbench Perl Test

Replies are listed 'Best First'.
Re^5: Some reflections on the Brainbench Perl Test
by Your Mother (Archbishop) on Dec 15, 2008 at 02:13 UTC

    I used to write art reviews and I often made exactly the same point; one very unpopular in the art world: process is nonsense. Only the product, the art, matters. To some degree this becomes a context argument again. :)

    Software development is completely different. It's not one person creating a finished work. Keeping a software base together is itself process. I would never have quit my last job if even 1/3 of the practices in that assessment were in place (they weren't all process either). It was primarily the homegrown, ad hoc, à la carte, manager's choice process drove me out.

    Before you think I'm disagreeing with your major point I'll mention that I refused to be sent for Six Sigma Black Belt training a few of jobs back because, in the main, I agree with you; and strongly enough to cripple my own career. That was one of two choices that probably cost me a directorship or major program manager job at one of the Net's biggest animals.

    So I don't disagree with you. I think there's a huge difference between bureaucracy -- which is what I feel you are really critiquing -- and best practices -- which I found most of the assessment to encourage.