RE: [ba-ohs-talk] Excellent methodology book
[mailto:firstname.lastname@example.org]On Behalf Of Eric Armstrong
Sent: Tuesday, January 01, 2002 2:15 PM
Subject: Re: [ba-ohs-talk] Excellent methodology book (01)
"Garold (Gary) L. Johnson" wrote: (02)
> These ideas have some disturbing implications for the current model of
> how software is developed and for the creation of collaboration tools
> in general. He makes the issues of tacit knowledge even more important
> in that he sees tacit knowledge as not only impossible to avoid but as
> a major tool in the effective collaboration required to develop
Excellent review, Garold. (03)
Can you outline what you see as the "disturbing implications" for the
Actually, I'm not even sure what the "current model" is, these days --
model has been discredited for quite a while now, as far as I can tell.
incremental development seems to be the replacement, but I'm not sure
it has taken hold. (04)
The major "disturbing implication" is disturbing to the status quo, not to
me, and that is the observation that the success of a software development
project correlates with the quality and nature of the people interactions
than it does to any form of process, tools, or development methodology.
Nearly all of the thrust of all of the "heavyweight" methodologies are part
of an attempt to produce great software using only average people, with the
goal of making developers "plug replaceable". It turns out (no surprise to
developers) that in order to develop software, sooner or later, somebody has
to think. Another shocker - some people are better at some skills than
others. It is not politically correct to say so, but there are actually some
people who can develop software better than others as well.
Cockburn also points out that the idea that computer people are anti social
and non-communicative is untrue - it is just that we are interested in
talking abut developing software and any other sort of conversation strikes
us as uninteresting.
I got into computing because there is a lot less opinion about results - if
my program does what I said it would, there is precious little room for
anyone to argue that it is "wrong" somehow. Imaging my chagrin as I find out
more and more all the time that developing software is at least as much an
issue of people as it is of software, tools, technology, or methodology.
Grumble, hummmmph! (05)
Garold (Gary) L. Johnson (06)