Re: [ba-ohs-talk] Excellent methodology book
Ah. Excellent observations. (01)
Yes. Our society has been plagued for some time now with the
"organization as machine, people as cogs" model for the workplace.
We've been growing out of it, but it's hard. And software development
is one area where it simply will not work. (02)
You're right. Somewhere along the line, someone has to *think*. And
that's just darn hard to do, with so many threads clamoring for your
attention, and the necessity to choose the right set of threads and
juxtapose them in the right way to make things happen. (03)
I think graphical design systems that allow for collapsing and reorganizing
object-responsibilities can be GREAT as a solution-enabler that helps
you visualize different designs and see relationships that might otherwise
have escaped you. (04)
"Garold (Gary) L. Johnson" wrote: (05)
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com]On Behalf Of Eric Armstrong
> Sent: Tuesday, January 01, 2002 2:15 PM
> To: firstname.lastname@example.org
> Subject: Re: [ba-ohs-talk] Excellent methodology book
> "Garold (Gary) L. Johnson" wrote:
> > ....
> > 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
> > software.
> Excellent review, Garold.
> Can you outline what you see as the "disturbing implications" for the
> current model?
> Actually, I'm not even sure what the "current model" is, these days --
> the waterfall
> 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
> how well
> it has taken hold.
> 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!
> Garold (Gary) L. Johnson (06)