[LRUG] Development methodologies (Was: Code samples: To do or not to do)

[Eleanor McHugh]

On 8 Apr 2009, at 12:33, Chris Parsons wrote:
> On 8 Apr 2009, at 11:55, Eleanor McHugh wrote:
>> Codifying Best Practice like that has to be a good thing, even if  
>> it does bother me that many people follow these methodologies  
>> without understanding both why they're effective and where their  
>> fracture points are.
>
>
> Reminded me of this article on InfoQ[1] by Dan North, which is a  
> must read if you're training or managing developers, or even just  
> trying to get better.
>
> Chris
>
> [1] http://www.infoq.com/articles/better-best-practices

Funnily enough I've used the Dreyfus model in designing skill systems  
for RPGs (yes, my geekdom apparently knows no bounds) where it's a  
great way of eliminating unnecessary and tedious dice rolling and/or  
paperwork :)

An interesting article though that chimes well with my own experiences.

Experts are rare enough that there is a definite need for best  
practices of a kind to help propagate knowledge - although as I've  
never followed any myself it would be hypocritical of me to suggest  
any in particular, or to berate those who share my passion for  
exploratory coding. Unfortunately best practices also act as a  
straight-jacket on creativity and their rigid adoption places a bar on  
how far practitioners can ultimately advance their skills which makes  
them dangerous: a change in environmental conditions can see the  
practices which once aided acting as a hindrance, as is the case with  
enterprise culture.

It's also the nature of closed communities that their rules become  
ever more detailed and prescriptive in an effort to achieve  
conformity, exacerbating this danger and decreasing the overall  
efficiency of practitioners at all levels.

It's also good to remember that knowledge is distinct from experience:  
knowing how to do something correctly under one set of circumstances  
may give some advantage when presented with different circumstances,  
but only the pain of failure really sharpens instinctual responses.  
And only repeated failure under a variety of circumstances will  
accurately calibrate those instincts.

On the other hand experts are very much nature forces of nature: they  
solve problems intuitively - often even when explicitly forbidden from  
working on them - and when phrasing arguments to defend their  
solutions use seemingly irrational language tinged with subtleties and  
allusions which make absolutely no sense to their less-skilled  
colleagues.

Put two experts in a room together and the problem is compounded -  
broad swathes of a topic will be cut across in a few words, to be  
followed by a three hour discussion of technicalities that no one else  
can even identify the importance of.

Frankly most teams are better off without an expert unless they:

a) specialise in innovative projects where an expert's instincts are  
the only sure guidance they'll get;
b) have too few resources to afford a decent sized team of competent  
developers;
c) want to convince third parties that they know their shit;
d) can gain in some other way from having a loose cannon in the  
building...

However as experts represent a very small proportion of any talent  
pool, it's not a hiring decision most of us will in practice have to  
worry about on a regular basis :)


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason