Cobol - Mapping (CoBOL) Methodologies to Problem Domains

Author

Mapping (CoBOL) Methodologies to Problem Domains

klshafer@att.net

2008-01-22, 9:57 pm

All -

Haven't been here for a while due to personal demands, but now that
I'm back, I wanted to put out an informal Call for Participation along
the following lines. In another forum I participate in we discuss
methodological approaches more than languages (eg. CMM vs. Agile).
Here is the essence of a post I put out there, and I'm putting it in
CLC to solicit the CoBOL angle, to wit, what methodologies are you
using in your CoBOL efforts: structured analysis / structured design,
object-oriented, custom, code-and-fix :-), whatever. CoBOL to
"language-du-jour" converts' opinions also welcome (that's at least
*you*, Mr. Pete Dashwood :-) ).

I guess it's OK to do some follow up here within this thread in CLC,
but seeing as how this is just a little bit off the usual beaten track
of CLC, I don't want it to get "out of hand" (as if anything here ever
does!)

Anyway, here is a "copy and past" of what I posted elsewhere!

All -

Anonymous's last post got me thinking, and I reviewed my c:\ drive for
some articles I had culled regarding this problem, which is namely,

"What methodologies/methods should we apply to what domains of
problems?"

I have three seminal works by Robert Glass that are directly relevant
here (you will need ACM and/or IEEE membership to get these, but I can
help you):

"Contemporary Application Domain Taxonomies"
http://portal.acm.org/citation.cfm?id=625489

"Some Heresy Regarding Software Engineering"
http://ieeexplore.ieee.org/xpl/free...&isnumber=29063

"Matching Methodology to Problem Domain"
http://portal.acm.org/citation.cfm?id=986228

In these works Glass makes it abundantly clear how **little** work has
been done in this area, by either industry or academia, and so this
might be an opportunity for some (relatively) groundbreaking work.

Those interested in exploring this aspect independently of <CLC and
other Forums>, please post here in this thread, or contact me offline
at my e-mail address. The goal for this exploration should be
initially modest (I have a fair amount of personal business to attend
to in the short term, which limits my time), but could be on the order
of accumulating enough "stuff" (viewpoints, rough "artifacts") to
present a "Roundtable", "Birds of a Feather", "Panel", or simply
"Gathering" at something like GLSEC (Great Lakes Software Excellence
Conference), but certainly not so much as to qualify as a "seminar" or
"workshop", let alone a "conference" :-).

I think for the time being this effort would be organized as a simple
cc: list for some occasional group e-mailings, and not yet anything
more structured.

But I'd like to get started on it by accumlating a list of interested
parties?

Any takers?

Ken

Pete Dashwood

2008-01-23, 3:55 am

<klshafer@att.net> wrote in message
news:519b9104-a107-4f9d-b341-781c2185da40@d4g2000prg.googlegroups.com...
> All -
>
> Haven't been here for a while due to personal demands, but now that
> I'm back, I wanted to put out an informal Call for Participation along
> the following lines. In another forum I participate in we discuss
> methodological approaches more than languages (eg. CMM vs. Agile).
> Here is the essence of a post I put out there, and I'm putting it in
> CLC to solicit the CoBOL angle, to wit, what methodologies are you
> using in your CoBOL efforts: structured analysis / structured design,
> object-oriented, custom, code-and-fix :-), whatever. CoBOL to
> "language-du-jour" converts' opinions also welcome (that's at least
> *you*, Mr. Pete Dashwood :-) ).

I believe that any attempt at problem solution that is driven from a
Language perspective will not be optimum, so looking for approaches taken
with COBOL (as opposed to anything else) for me, is a non-starter.

I apply the same problem solution approaches no matter WHAT language is in
use.

>
> I guess it's OK to do some follow up here within this thread in CLC,
> but seeing as how this is just a little bit off the usual beaten track
> of CLC, I don't want it to get "out of hand" (as if anything here ever
> does!)
>
> Anyway, here is a "copy and past" of what I posted elsewhere!
>
> All -
>
> Anonymous's last post got me thinking, and I reviewed my c:\ drive for
> some articles I had culled regarding this problem, which is namely,
>
> "What methodologies/methods should we apply to what domains of
> problems?"

Pre-supposes that there ARE different domains of problem; in commercial
computer programming this is arguable: "Get a solution implemented that
costs as little as possible, takes as little time as possible, meets the
Business requirements, and is comfortable for users to use." If you can
manage to also minimise future maintenance and make the new system integrate
nicely with current and foreseeable technical environments, that's a
bonus...:-)

>
> I have three seminal works by Robert Glass that are directly relevant
> here (you will need ACM and/or IEEE membership to get these, but I can
> help you):
>
> "Contemporary Application Domain Taxonomies"
> http://portal.acm.org/citation.cfm?id=625489
>
> "Some Heresy Regarding Software Engineering"
> http://ieeexplore.ieee.org/xpl/free...&isnumber=29063
>
> "Matching Methodology to Problem Domain"
> http://portal.acm.org/citation.cfm?id=986228
>
> In these works Glass makes it abundantly clear how **little** work has
> been done in this area, by either industry or academia, and so this
> might be an opportunity for some (relatively) groundbreaking work.

Glass should speak for himself.

Personally, I've been researching, analysing, postulating, experimenting,
and considering this for the last 43 years. I have arrived at some
interesting conclusions which will be published in a forthcoming book that
will be completed later this year.

I can tell you this for nothing:

1. No single one of the current methodologies works to complete satisfaction
(with the POSSIBLE exception of DSDM...) when applied by itself, alone.
2. There is a marked lack of imagination on the part of both Business
Management and Technical Management when addressing this problem.
3. The main reason for software engineering failures is very bright
technical people being poorly led by managers who secretly despise them, and
have little or no understanding of what they do/need. (Point being: It isn't
necessarily about Methodology...)
4. It IS possible to formulate a General Solution to commercial software
engineering, that will solve more than 80% of the problems projects
encounter. (However, doing so requires vision, imagination, and acceptance
of change which most organisations are not capable of, or simply don't
have.) This "general solution" is possible because, at least in the domain
of commercial software solution engineering, there are the same (or very
similar) "general problems" that manifest thermselves on every project,
despite the fact that EVERY Management team believes THEY are unique and
THEIR business is completely different from everyone else's. I think this
myopia occurs because they are not capable of the pattern recognition that
their tech staff do instinctively.

I am postulating a completely different approach, but I don't want to spoil
it by pre-announcing it here. I WILL say that it includes the best points of
several currently successful methodologies, along with some quite innovative
ideas, based on my own experience and what I've found to work. I can also
say that it is as far divorced from Waterfall as it is possible to get :-)

Amazingly, I have a track record of 20 years in PM without a failure (1
project was not completed due to international corporate politics, over
which I had no control), yet I have NEVER implemented (completely) the
standard approach required on any particular site. Had I done so, the
project would have failed.:-)

I believe the factors required for successful implementation are not easily
identifiable or quantifiable and I address this in the book. Certainly some
of them cannot be taught, but must be learned by observation and experience.
It IS possible to raise awareness of them and suggest some approaches...

>
> Those interested in exploring this aspect independently of <CLC and
> other Forums>, please post here in this thread, or contact me offline
> at my e-mail address. The goal for this exploration should be
> initially modest (I have a fair amount of personal business to attend
> to in the short term, which limits my time), but could be on the order
> of accumulating enough "stuff" (viewpoints, rough "artifacts") to
> present a "Roundtable", "Birds of a Feather", "Panel", or simply
> "Gathering" at something like GLSEC (Great Lakes Software Excellence
> Conference), but certainly not so much as to qualify as a "seminar" or
> "workshop", let alone a "conference" :-).
>
> I think for the time being this effort would be organized as a simple
> cc: list for some occasional group e-mailings, and not yet anything
> more structured.
>
> But I'd like to get started on it by accumlating a list of interested
> parties?
>
> Any takers?

Not at this stage, Ken. I believe it will be too dry and Academic to
interest me, and I can't/won't contribute to a pissing contest about
methodologies, none of which I believe to be perfect... :-)

Nevertheless, I wish you luck with it :-)

Pete.
--
"I used to write COBOL...now I can do anything."

2008-01-23, 7:55 am

In article <519b9104-a107-4f9d-b341-781c2185da40@d4g2000prg.googlegroups.com>,
klshafer@att.net <klshafer@att.net> wrote:
>All -
>
>Haven't been here for a while due to personal demands, but now that
>I'm back, I wanted to put out an informal Call for Participation along
>the following lines. In another forum I participate in we discuss
>methodological approaches more than languages (eg. CMM vs. Agile).
>Here is the essence of a post I put out there, and I'm putting it in
>CLC to solicit the CoBOL angle, to wit, what methodologies are you
>using in your CoBOL efforts: structured analysis / structured design,
>object-oriented, custom, code-and-fix :-), whatever.

I use, of course, whatever style fits into the code that already exists at
the client's site... if a programmer expects something to occur in a
certain place or way then I want to make sure I do my best not to add
confusion. For example, if a program usually starts with something like:

Procedure Division using LinkParms.

Evaluate PassThrough
When 1
Perform First-Calls
Perform Edit-Data
When 2
Perform Edit-data
When Other
Perform LinkParms-Corrupt
End-Evaluate

Perform Cleanup

Goback.

.... then it is rather unlikely for me to write

PROCEDURE DIVISION USING LINKPARMS.

PERFORM 0000-HOUSEKEEPING THRU 0000-EX.

PERFORM 5000-MAINLINE THRU 5000-EX.

PERFORM 9000-EOJ THRU 9000-EX.

GOBACK.

0000-HOUSEKEEPING.

MOVE LS-PASS-FLD TO WK-PASS-FLD.
IF NOT FIRST-TIME-IN
GO TO 0000-EX.

.... et and cetera. If something just Isn't Working (certain things keep
going wrong in certain ways) then I'll make my suggestions as to how I
believe difficulties might be alleviated... but as long as what I do
doesn't violate my own standards of Professional Ethics then, ultimately,
I'll do what the person who signs my timesheets tells me to do; something
about paying pipers and calling tunes.

DD

2008-01-23, 7:55 am

In article <5vns9hF1ns38fU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>This "general solution" is possible because, at least in the domain
>of commercial software solution engineering, there are the same (or very
>similar) "general problems" that manifest thermselves on every project,
>despite the fact that EVERY Management team believes THEY are unique and
>THEIR business is completely different from everyone else's. I think this
>myopia occurs because they are not capable of the pattern recognition that
>their tech staff do instinctively.

Mr Dashwood, I'm not sure about pattern recognition and such... but I've
read in a few texts that it is a very ancient and human phenomenom to
consider one's Place and one's People to be special and superior to
everything else; the (that-which-caused-creation) made the Human Beings
and their Land of which We are part, etc.

Given that as an almost species-level behavior the diffident sniff and
'NIH' (Not Invented Here) dismissal aimed at a new idea or process
seems... downright Human, it does.

DD

klshafer@att.net

2008-01-23, 6:56 pm

On Jan 22, 10:57=A0pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
>
> Not at this stage, Ken. I believe it will be too dry and Academic to
> interest me, and I can't/won't contribute to a pissing contest about
> methodologies, none of which I believe to be perfect... :-)
>
> Nevertheless, I wish you luck with it :-)
>
> Pete.

Uhh, can you get me a pre-publication copy of your book? :-)

Ken

klshafer@att.net

2008-01-23, 6:56 pm

On Jan 23, 5:36=A0am, docdw...@panix.com () wrote:
> In article <519b9104-a107-4f9d-b341-781c2185d...@d4g2000prg.googlegroups.c=
om>,
>
> I use, of course, whatever style fits into the code that already exists at=

> the client's site... if a programmer expects something to occur in a
> certain place or way then I want to make sure I do my best not to add
> confusion. =A0For example, if a program usually starts with something like=
:
>
> Procedure Division using LinkParms.
>
> =A0 =A0 Evaluate PassThrough
> =A0 =A0 When 1
> =A0 =A0 =A0 =A0 Perform First-Calls
> =A0 =A0 =A0 =A0 Perform Edit-Data
> =A0 =A0 When 2
> =A0 =A0 =A0 =A0 Perform Edit-data
> =A0 =A0 When Other
> =A0 =A0 =A0 =A0 Perform LinkParms-Corrupt
> =A0 =A0 End-Evaluate
>
> =A0 =A0 Perform Cleanup
>
> =A0 =A0 Goback.
>
> ... then it is rather unlikely for me to write
>
> PROCEDURE DIVISION USING LINKPARMS.
>
> =A0 =A0 PERFORM 0000-HOUSEKEEPING =A0THRU =A00000-EX.
>
> =A0 =A0 PERFORM 5000-MAINLINE =A0 =A0 =A0THRU =A05000-EX.
>
> =A0 =A0 PERFORM 9000-EOJ =A0 =A0 =A0 =A0 =A0 THRU =A09000-EX.
>
> =A0 =A0 GOBACK.
>
> 0000-HOUSEKEEPING.
>
> =A0 =A0 MOVE LS-PASS-FLD =A0TO =A0WK-PASS-FLD.
> =A0 =A0 IF NOT FIRST-TIME-IN
> =A0 =A0 =A0 =A0 GO TO 0000-EX.
>

Hmmm... Doc, this actually is *very helpful*. I just need a moniker to
'tach to it. How about, "minimal impact" approach as the
"methodology", with the "problem domain" being "maintenance". Maybe
this is really a "meta-methodology", since it might subsume "if system
flowcharts exist, update the system flowcharts as needed, in the same
format as before." Given all the hub-bub of "transformational"
approaches and the like, "minimal impact" might actually be a valid
way of thinking about it.

Can you think of a better, ah, more *marketable* tagline than "minimal
impact" though? Something with a homonym of a Hollywood celebrity's
name, or the like?

> ... et and cetera. =A0If something just Isn't Working (certain things keep=

> going wrong in certain ways) then I'll make my suggestions as to how I
> believe difficulties might be alleviated... but as long as what I do
> doesn't violate my own standards of Professional Ethics then, ultimately,
> I'll do what the person who signs my timesheets tells me to do; something
> about paying pipers and calling tunes.
>

I seem to recall that when the ol' body wears out a little too much,
and there is little that the old' Doc can do, we usually shift away
from health Remediation to Pain Management. So what do we call these
for Software systems?

Ken

2008-01-23, 6:56 pm

In article <a875426b-021a-440c-adf1-a1df307299cd@e23g2000prf.googlegroups.com>,
klshafer@att.net <klshafer@att.net> wrote:
>On Jan 23, 5:36_am, docdw...@panix.com () wrote:

[snip]
[color=darkred]
>Hmmm... Doc, this actually is *very helpful*.

From *me*? That's utterly impossible, just ask around the newsgroup.

>I just need a moniker to
>'tach to it. How about, "minimal impact" approach as the
>"methodology", with the "problem domain" being "maintenance". Maybe
>this is really a "meta-methodology", since it might subsume "if system
>flowcharts exist, update the system flowcharts as needed, in the same
>format as before." Given all the hub-bub of "transformational"
>approaches and the like, "minimal impact" might actually be a valid
>way of thinking about it.

That is one of the difficulties, Mr Shafer... the reconciling of 'we want
something new' with 'we're comfortable with what we do'. If 'what we do'
actually *works* then I've found the primary cause of 'we want something
new' is a new Corner-Office Idiot who wants folks to say 'Jones is really
shaking things up there.'

(never mind the fact that more work is getting done, or less, or the
employees are more satisfied, or less... it's just 'Jones is really
shaking things up there')

>
>Can you think of a better, ah, more *marketable* tagline than "minimal
>impact" though? Something with a homonym of a Hollywood celebrity's
>name, or the like?

If I could do that I'd be writing advertising-copy... 'It's this, it's
that, it's the other thing! It's all three, in one... yes, it's new
Three-in-One!'

And so... I stick to COBOL.

>
>I seem to recall that when the ol' body wears out a little too much,
>and there is little that the old' Doc can do, we usually shift away
>from health Remediation to Pain Management. So what do we call these
>for Software systems?

It could be the shift from 'curative coding to, perhaps, 'palliative
programming'.

DD

Howard Brazee

2008-01-23, 6:56 pm

On Wed, 23 Jan 2008 18:26:51 +0000 (UTC), docdwarf@panix.com () wrote:

>It could be the shift from 'curative coding to, perhaps, 'palliative
>programming'.

Sometimes that's sufficient.

SkippyPB

2008-01-23, 6:56 pm

On Wed, 23 Jan 2008 10:36:29 +0000 (UTC), docdwarf@panix.com () wrote:

>In article <519b9104-a107-4f9d-b341-781c2185da40@d4g2000prg.googlegroups.com>,
>klshafer@att.net <klshafer@att.net> wrote:
>
>I use, of course, whatever style fits into the code that already exists at
>the client's site... if a programmer expects something to occur in a
>certain place or way then I want to make sure I do my best not to add
>confusion. For example, if a program usually starts with something like:
>
>Procedure Division using LinkParms.
>
> Evaluate PassThrough
> When 1
> Perform First-Calls
> Perform Edit-Data
> When 2
> Perform Edit-data
> When Other
> Perform LinkParms-Corrupt
> End-Evaluate
>
> Perform Cleanup
>
> Goback.
>
>... then it is rather unlikely for me to write
>
>PROCEDURE DIVISION USING LINKPARMS.
>
> PERFORM 0000-HOUSEKEEPING THRU 0000-EX.
>
> PERFORM 5000-MAINLINE THRU 5000-EX.
>
> PERFORM 9000-EOJ THRU 9000-EX.
>
> GOBACK.
>
>0000-HOUSEKEEPING.
>
> MOVE LS-PASS-FLD TO WK-PASS-FLD.
> IF NOT FIRST-TIME-IN
> GO TO 0000-EX.
>
>... et and cetera. If something just Isn't Working (certain things keep
>going wrong in certain ways) then I'll make my suggestions as to how I
>believe difficulties might be alleviated... but as long as what I do
>doesn't violate my own standards of Professional Ethics then, ultimately,
>I'll do what the person who signs my timesheets tells me to do; something
>about paying pipers and calling tunes.
>
>DD

In terms of methodologies to solve a problem, I'm so old school I
still flow chart at times when the logic path isn't clear or the
problem too complex. Then, depending on what language is available to
me at the client site, I write the code to fit the flow. Structured
analysis / structured design, object-oriented, custom, code-and-fix
are useless unless you know the path you need to take to solve the
problem. They, in and of themselves, will solve nothing and therefore
I don't feel are worth much discussion.

Regards,

////
(o o)
-oOO--(_)--OOo-

"Well, that kind of puts a damper on another Yankees win."
--Announcer Phil Rizzuto, after a news bulletin reporting
the death of Pope Paul VI, 1978
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Remove nospam to email me.

Steve

tlmfru

2008-01-23, 6:56 pm

Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5vns9hF1ns38fU1@mid.individual.net...
> I believe that any attempt at problem solution that is driven from a
> Language perspective will not be optimum, so looking for approaches taken
> with COBOL (as opposed to anything else) for me, is a non-starter.
>
> I apply the same problem solution approaches no matter WHAT language is in
> use.
>
>

If by this you mean that selecting the language first is a non-starter -
then you're absolutely right. But if you mean that the language to be used
is of no consequence, then I venture to disagree. Obvious examples: report
writers (including the much maligned RPG); FORTRAN in its place; or
assemblers for interacting directly with the hardware - shouldn't be a
priori ruled out.

It'll be interesting to see your book. Something written by an experienced
practitioner as opposed to a theorist (who quite often has an axe to grind)
should be a treat.

PL

Charles Hottel

2008-01-23, 6:56 pm

Charles Hottel

2008-01-23, 6:56 pm

<klshafer@att.net> wrote in message
news:5fc209c8-8bc2-483f-9e81-d8818fe51ab1@c23g2000hsa.googlegroups.com...
On Jan 22, 10:57 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
>
> Not at this stage, Ken. I believe it will be too dry and Academic to
> interest me, and I can't/won't contribute to a pissing contest about
> methodologies, none of which I believe to be perfect... :-)
>
> Nevertheless, I wish you luck with it :-)
>
> Pete.

Uhh, can you get me a pre-publication copy of your book? :-)

Ken

See: www.amazon.com/HowToBedWomenAll OverTheWorld

Robert

2008-01-23, 9:56 pm

On Wed, 23 Jan 2008 16:57:36 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
wrote:

><klshafer@att.net> wrote in message
>news:519b9104-a107-4f9d-b341-781c2185da40@d4g2000prg.googlegroups.com...
>
>I believe that any attempt at problem solution that is driven from a
>Language perspective will not be optimum, so looking for approaches taken
>with COBOL (as opposed to anything else) for me, is a non-starter.
>
>I apply the same problem solution approaches no matter WHAT language is in
>use.

The dozen methodologies I've used were agnostic to language. It didn't matter whether they
were heavyweight, such as CMM, or lightweight, such as Agile and XP. They treat the
programming act as a black box. They control the inputs -- requirements, planning and
design -- and the outputs -- testing, implementation, training. The black box they do not
care about, called 'build', includes detailed design, coding, peer review, programming
standards, change control and unit testing. One gets the impression methodology designers
regard developers (g

s) as inherently uncontrollable. I knew one who said "it's like
trying to herd cats."

At one big company there was a checklist of the steps to get a change made, start to
finish. There were 150 steps on the liist, of which ONE was the programming act. It said
simply "Make the program change." There was SECOND checklist breaking that step out into
25 activities. That second list was maintained by technical management; it was not part of
the corporate methodology. It is what passes for methodology in shops that don't really
have a formal methodology, shops run by programmer types.

Both lists aimed to avoid mistakes, increase productivity and make users happy. The
difference was the methodology developed by programmers (second list) revolved around
source code, whereas the first list regarded source code as almost irrelevant. The formal
methodology (first list) was used on projects that involved no software at all.

>1. No single one of the current methodologies works to complete satisfaction
>(with the POSSIBLE exception of DSDM...) when applied by itself, alone.
>2. There is a marked lack of imagination on the part of both Business
>Management and Technical Management when addressing this problem.
>3. The main reason for software engineering failures is very bright
>technical people being poorly led by managers who secretly despise them, and
>have little or no understanding of what they do/need. (Point being: It isn't
>necessarily about Methodology...)

"You must know there are two ways of contesting, the one by the law, the other by force;
the first method is proper to men, the second to beasts; but because the first is
frequently not sufficient, it is necessary to have recourse to the second. Therefore it is
necessary for a prince to understand how to avail himself of the beast and the man - just
one is not enough."

>4. It IS possible to formulate a General Solution to commercial software
>engineering, that will solve more than 80% of the problems projects
>encounter. (However, doing so requires vision, imagination, and acceptance
>of change which most organisations are not capable of, or simply don't
>have.) This "general solution" is possible because, at least in the domain
>of commercial software solution engineering, there are the same (or very
>similar) "general problems" that manifest thermselves on every project,
>despite the fact that EVERY Management team believes THEY are unique and
>THEIR business is completely different from everyone else's.

This made me smile. A running joke between computer company technical consultants is the
introductory statement from Mr. Big, "This company is unique." We knew it wasn't; it was
like all the others. It was difficult to suppress laughter until we were out of his
office.

> I think this
>myopia occurs because they are not capable of the pattern recognition that
>their tech staff do instinctively.

I think it's ego. 'Only a genius like me can understand the complex problems we face.'

>I am postulating a completely different approach, but I don't want to spoil
>it by pre-announcing it here. I WILL say that it includes the best points of
>several currently successful methodologies, along with some quite innovative
>ideas, based on my own experience and what I've found to work. I can also
>say that it is as far divorced from Waterfall as it is possible to get :-)

So are ALL Agile methods .. they say. Close inspection reveals the only difference is
shorter iterations. They seduce programmers into thinking they can be cowboys again, while
management thinks it's getting more output for less money.

Machiavelli wrote the seminal work on software management. He said a prince who does not
raise the contempt of the nobles and keeps the people satisfied should have no fear of
conspirators.

"If a prince seizes a state, all the required injuries should be inflicted at one stroke.
This way it is not necessary to every day be a little evil. Injuries should be inflicted
once, swiftly - so that it may be forgotten. A prince should however deliver frequent,
small benefits to his people so that its positive effects last longer."

>Amazingly, I have a track record of 20 years in PM without a failure (1
>project was not completed due to international corporate politics, over
>which I had no control), yet I have NEVER implemented (completely) the
>standard approach required on any particular site. Had I done so, the
>project would have failed.:-)

I don't understand this talk about cost overruns and missed deadlines. I've never worked
on a project that wasn't delivered on time .. using existing methodologies.

>I believe the factors required for successful implementation are not easily
>identifiable or quantifiable and I address this in the book. Certainly some
>of them cannot be taught, but must be learned by observation and experience.
>It IS possible to raise awareness of them and suggest some approaches...

"In order to imitate war victories of other illustrious men and avoid defeats, a prince
should study war histories to learn the causes of war victories and defeats."

Charles Hottel

2008-01-23, 9:56 pm

"Robert" <no@e.mail> wrote in message
news:3khfp39ibgkkhus4ut98c2q6a20he77idq@
4ax.com...
> On Wed, 23 Jan 2008 16:57:36 +1300, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz>
> wrote:
>
>
> The dozen methodologies I've used were agnostic to language. It didn't
> matter whether they
> were heavyweight, such as CMM, or lightweight, such as Agile and XP. They
> treat the
> programming act as a black box. They control the inputs -- requirements,
> planning and
> design -- and the outputs -- testing, implementation, training. The black
> box they do not
> care about, called 'build', includes detailed design, coding, peer
> review, programming
> standards, change control and unit testing. One gets the impression
> methodology designers
> regard developers (g

s) as inherently uncontrollable. I knew one who
> said "it's like
> trying to herd cats."
>
> At one big company there was a checklist of the steps to get a change
> made, start to
> finish. There were 150 steps on the liist, of which ONE was the
> programming act. It said
> simply "Make the program change." There was SECOND checklist breaking that
> step out into
> 25 activities. That second list was maintained by technical management; it
> was not part of
> the corporate methodology. It is what passes for methodology in shops that
> don't really
> have a formal methodology, shops run by programmer types.
>
> Both lists aimed to avoid mistakes, increase productivity and make users
> happy. The
> difference was the methodology developed by programmers (second list)
> revolved around
> source code, whereas the first list regarded source code as almost
> irrelevant. The formal
> methodology (first list) was used on projects that involved no software at
> all.
>
>
> "You must know there are two ways of contesting, the one by the law, the
> other by force;
> the first method is proper to men, the second to beasts; but because the
> first is
> frequently not sufficient, it is necessary to have recourse to the second.
> Therefore it is
> necessary for a prince to understand how to avail himself of the beast and
> the man - just
> one is not enough."
>
>
> This made me smile. A running joke between computer company technical
> consultants is the
> introductory statement from Mr. Big, "This company is unique." We knew it
> wasn't; it was
> like all the others. It was difficult to suppress laughter until we were
> out of his
> office.
>
>
> I think it's ego. 'Only a genius like me can understand the complex
> problems we face.'
>
>
> So are ALL Agile methods .. they say. Close inspection reveals the only
> difference is
> shorter iterations. They seduce programmers into thinking they can be
> cowboys again, while
> management thinks it's getting more output for less money.
>
> Machiavelli wrote the seminal work on software management. He said a
> prince who does not
> raise the contempt of the nobles and keeps the people satisfied should
> have no fear of
> conspirators.
>
> "If a prince seizes a state, all the required injuries should be inflicted
> at one stroke.
> This way it is not necessary to every day be a little evil. Injuries
> should be inflicted
> once, swiftly - so that it may be forgotten. A prince should however
> deliver frequent,
> small benefits to his people so that its positive effects last longer."
>
>
> I don't understand this talk about cost overruns and missed deadlines.
> I've never worked
> on a project that wasn't delivered on time .. using existing
> methodologies.
>
>
> "In order to imitate war victories of other illustrious men and avoid
> defeats, a prince
> should study war histories to learn the causes of war victories and
> defeats."
>
>

In my early days as a progrmmer a frequent project was: make a listing of
this tray of cards for the user

The first step was to prepare a pert chart. I usually listed the cards
first, gave them to the user and drew the chart later.

Robert

2008-01-23, 9:56 pm

On Wed, 23 Jan 2008 17:39:23 -0600, "tlmfru" <lacey@mts.net> wrote:

>
>Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
>news:5vns9hF1ns38fU1@mid.individual.net...
>
>If by this you mean that selecting the language first is a non-starter -
>then you're absolutely right. But if you mean that the language to be used
>is of no consequence, then I venture to disagree. Obvious examples: report
>writers (including the much maligned RPG); FORTRAN in its place; or
>assemblers for interacting directly with the hardware - shouldn't be a
>priori ruled out.

Hey, crank up the Wayback Machine. How about IBM 650 SOAP (not to be

with Simple
Object Access Protocol, this SOAP is about optimized drum storage)?

klshafer@att.net

2008-01-23, 9:56 pm

On Jan 23, 8:20=A0pm, Robert <n...@e.mail> wrote:
> On Wed, 23 Jan 2008 16:57:36 +1300, "Pete Dashwood" <dashw...@removethis.e=
nternet.co.nz>
> wrote:
>
> I don't understand this talk about cost overruns and missed deadlines. I'v=
e never worked
> on a project that wasn't delivered on time .. using existing methodologies=
..

I am not being deliberately *ch

klshafer@att.net

2008-01-23, 9:56 pm

>
> It could be the shift from 'curative coding to, perhaps, 'palliative
> programming'.
>
> DD

Palliative programming? That actually is very, VERY good! So apt! So
descriptive! I'm so glad I prompted you! I will have to tell the
*World* that it was a Doc who coined the term!

Ken

Robert

2008-01-23, 9:56 pm

On Wed, 23 Jan 2008 19:32:33 -0500, "Charles Hottel" <chottel@earthlink.net> wrote:

>This response may be more low level than you are looking for. I am not
>heavily into project management although I have been exposed to CMM. I was
>not impressed with how it was implemented where I work. People often
>generated a lot of the required documentaion after the fact so it was not
>true CMM.

That's the RIGHT way. First write the program, then the detailed design. They always
agree! There's no rework and you can use interns or offshore contractors rather than
wasting programmer time. I'm not joking, that's how it's done in F-100 companies.

>For manitenance I have used structure charts to show what
>CALLs/PERFORMs/XCTLs/LINKs what. For some twisted logic flowcharts can
>help

What's a flowchart? I think I saw one in the '70s.

Robert

2008-01-23, 9:56 pm

On Wed, 23 Jan 2008 18:34:15 -0800 (PST), "klshafer@att.net" <klshafer@att.net> wrote:

>On Jan 23, 8:20_pm, Robert <n...@e.mail> wrote:
>
>I am not being deliberately *ch

y* here, but could you cite me some
>of those "existing" methodologies and the general application domain
>(insurance, process control, government, etc.) that the project was
>on? This is the real *empirical* heart-of-the-matter I am trying to
>touch. And to point out the-not-obvious-to-others-lie-of "the
>traditional methods never work." Or maybe the existing ones you are
>referring to are Agile-OO?

All were CMM-3 or similar, none OO. The one I'm on now is CMM trying to be lightweight
with two month iterations; most were six month. All were very large companies or
government agencies.

Retail, Y2K fix on 100 very large assembly language programs, used interns to document per
Keane methodology

Insurance, enhancements, first project on CMM-3

Government Student Loan, enhancements, EDS

Government Child Welfare, enhancements, Accenture

Pharmaceutical discounts and rebates, rehost from AS/400 to Unix, CMM-3

Pharmaceutical charge clearinghouse, enhacements, CMM - one month iterations

Distribution, convert screens from text to GUI, CMM

Retail, add make for new platforms and test 500 programs, home-grown Wal-Mart

Soft drink, convert billing system to SAP, CMM (IBM)

Telephone, enhance billing for major acquisition, CMM - two month iterations

tlmfru

2008-01-24, 3:55 am

Robert <no@e.mail> wrote in message
news:lktfp31najs2v8eghvupu102v9j3b447n4@
4ax.com...
>
> Hey, crank up the Wayback Machine. How about IBM 650 SOAP (not to be

with Simple
> Object Access Protocol, this SOAP is about optimized drum storage)?

What new-fangled nonsense is this? Don't you know that mercury delay lines
haven't reached their full potential yet???

Pete Dashwood

2008-01-24, 3:55 am

<klshafer@att.net> wrote in message
news:5fc209c8-8bc2-483f-9e81-d8818fe51ab1@c23g2000hsa.googlegroups.com...
On Jan 22, 10:57 pm, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
>
> Not at this stage, Ken. I believe it will be too dry and Academic to
> interest me, and I can't/won't contribute to a pissing contest about
> methodologies, none of which I believe to be perfect... :-)
>
> Nevertheless, I wish you luck with it :-)
>
> Pete.

>Uhh, can you get me a pre-publication copy of your book? :-)

Sure. Can you get me the cover price :-)?

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-01-24, 3:55 am

"tlmfru" <lacey@mts.net> wrote in message
news:hfQlj.10319$M24.5411@newsfe17.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:5vns9hF1ns38fU1@mid.individual.net...
>
> If by this you mean that selecting the language first is a non-starter -
> then you're absolutely right. But if you mean that the language to be
> used
> is of no consequence, then I venture to disagree.

I have consistently maintained the position, (both here in CLC, and in
"real" life :-)), that the best tools for the job should be used. I
suggested this position here more than 12 years ago when the generally
accepted response was "Everything I want to do, I can do in COBOL". I
suggested people might do well to expand their skill sets, learn Java for
example, and get a few more tools in the box alongside COBOL. I took my own
advice and learned Java (it helped my understanding of OO COBOL apart from
anything else...), and later (just over a year ago) moved to C#. During my
career I have programmed with Fortran, PL/I, Delphi (Pascal), Basic, VB and
half a dozen Assembler Languages.

I would NEVER advocate tying development to a single language. Neither would
I advocate just using ANY language for any particular development (...the
Language IS of consequence...).

We got away with it for COBOL because it was a centralized platform, the
procedural paradigm was adequate for most of what we wanted to do, and it
was financially and technically intimidating to maintain costly skill bases
for more than one language, where code was maintained line by line.
Furthermore, COBOL is/was ideally suited to commercial batch processing,
anyway.

Today the environment is richer, the Network is King and we NEED a richer
toolset.

>Obvious examples: report
> writers (including the much maligned RPG); FORTRAN in its place; or
> assemblers for interacting directly with the hardware - shouldn't be a
> priori ruled out.
>

NOTHING should be a priori ruled out...:-)

> It'll be interesting to see your book. Something written by an
> experienced
> practitioner as opposed to a theorist (who quite often has an axe to
> grind)
> should be a treat.

Thank you for the encouragement. I'll try not to disappoint... :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-01-24, 3:55 am

s) as inherently uncontrollable. I knew one who
> said "it's like
> trying to herd cats."
>
> At one big company there was a checklist of the steps to get a change
> made, start to
> finish. There were 150 steps on the liist, of which ONE was the
> programming act. It said
> simply "Make the program change." There was SECOND checklist breaking that
> step out into
> 25 activities. That second list was maintained by technical management; it
> was not part of
> the corporate methodology. It is what passes for methodology in shops that
> don't really
> have a formal methodology, shops run by programmer types.
>
> Both lists aimed to avoid mistakes, increase productivity and make users
> happy. The
> difference was the methodology developed by programmers (second list)
> revolved around
> source code, whereas the first list regarded source code as almost
> irrelevant. The formal
> methodology (first list) was used on projects that involved no software at
> all.

I can relate to this and have been in companies where it was certainly the
case. Your analysis of it is perceptive.

>
>
> "You must know there are two ways of contesting, the one by the law, the
> other by force;
> the first method is proper to men, the second to beasts; but because the
> first is
> frequently not sufficient, it is necessary to have recourse to the second.
> Therefore it is
> necessary for a prince to understand how to avail himself of the beast and
> the man - just
> one is not enough."

Law and force are not the ONLY two ways... there are others.
>
>
> This made me smile. A running joke between computer company technical
> consultants is the
> introductory statement from Mr. Big, "This company is unique." We knew it
> wasn't; it was
> like all the others. It was difficult to suppress laughter until we were
> out of his
> office.
>
>
> I think it's ego. 'Only a genius like me can understand the complex
> problems we face.'
>
>
> So are ALL Agile methods .. they say. Close inspection reveals the only
> difference is
> shorter iterations. They seduce programmers into thinking they can be
> cowboys again, while
> management thinks it's getting more output for less money.
>
> Machiavelli wrote the seminal work on software management. He said a
> prince who does not
> raise the contempt of the nobles and keeps the people satisfied should
> have no fear of
> conspirators.
>
> "If a prince seizes a state, all the required injuries should be inflicted
> at one stroke.
> This way it is not necessary to every day be a little evil. Injuries
> should be inflicted
> once, swiftly - so that it may be forgotten. A prince should however
> deliver frequent,
> small benefits to his people so that its positive effects last longer."
>
>
> I don't understand this talk about cost overruns and missed deadlines.
> I've never worked
> on a project that wasn't delivered on time .. using existing
> methodologies.

Then you have done well, Robert. Most Project Managers cannot claim this. Of
course, it is easy to deliver projects on time if the deadlines are extended
:-) (I'm not suggesting you do that...:-)) Timeboxed projects CANNOT slip;
I like timeboxing.
>
>
> "In order to imitate war victories of other illustrious men and avoid
> defeats, a prince
> should study war histories to learn the causes of war victories and
> defeats."
>

Given your partiality to Machiavelli, I'm sure you'll not be surprised that
Politics and Manipulation can both be added to Law and Force as useful
methods for contesting... :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-01-24, 3:55 am

<klshafer@att.net> wrote in message
news:5ecae817-8dd9-4a00-b792-f5ff511f002a@e6g2000prf.googlegroups.com...
On Jan 23, 8:20 pm, Robert <n...@e.mail> wrote:
> On Wed, 23 Jan 2008 16:57:36 +1300, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz>
> wrote:
>
> I don't understand this talk about cost overruns and missed deadlines.
> I've never worked
> on a project that wasn't delivered on time .. using existing
> methodologies.

I am not being deliberately *ch

y* here, but could you cite me some
of those "existing" methodologies and the general application domain
(insurance, process control, government, etc.) that the project was
on? This is the real *empirical* heart-of-the-matter I am trying to
touch. And to point out the-not-obvious-to-others-lie-of "the
traditional methods never work." Or maybe the existing ones you are
referring to are Agile-OO?

>"If a prince seizes a state, all the required injuries should be inflicted
>at one stroke.
>This way it is not necessary to every day be a little evil. Injuries should
>be inflicted
>once, swiftly - so that it may be forgotten. A prince should however
>deliver frequent,
>small benefits to his people so that its positive effects last longer."

I have quietly fed up the rumor-chain, more than once to a management
clique, that it is far, far better to "cut once, cut deep, cut to the
bone", and then *immediately* reassure everyone left that they are
*safe* (well, as safe as any one can be nowadays.) There is nothing
more destructive of morale and deleterious to a project than the drip,
drip, drip of attrition and going to work every day wondering, "Am I
next?" That this is so self-evident and yet so often ignored always
amazes me.

(Your post, like Alistair's, seems to be missing a chevron level when
replied to, so I'll prefix my comments with...[Pete:])

[Pete:]

Nobody should have to work bearing this particular fardel.

Contractors don't (and, if they do, they shouldn't be contracting...)

The only security anybody has is how useful they are to have around. Knowing
you can go down the road and get another job goes a long way to building
confidence and letting you focus on the job in hand without wondering or
fearing whether you are next for the chop.

How do you get to be "useful to have around"? Expand your skill set,
educate yourself, and delight in what you do.

Pete.
--
"I used to write COBOL...now I can do anything."

2008-01-24, 7:55 am

In article <3khfp39ibgkkhus4ut98c2q6a20he77idq@4ax.com>,
Robert <no@e.mail> wrote:
>On Wed, 23 Jan 2008 16:57:36 +1300, "Pete Dashwood" <dashwood@removethis.enternet.co.nz>
>wrote:

[snip]

>Both lists aimed to avoid mistakes, increase productivity and make users happy. The
>difference was the methodology developed by programmers (second list) revolved around
>source code, whereas the first list regarded source code as almost irrelevant. The formal
>methodology (first list) was used on projects that involved no software at all.

It sounds like a good Corporate 'one size fits all' mentality, in that
software is considered to be just like any other tool or process. The
folks in charge of software developed their own steps to deal with what
they find to be different about installing a chunk o' code to, say, move
money in a different direction... as opposed to the needs of buying a
truck to move money in a different direction.

[snip]

>
>This made me smile. A running joke between computer company technical consultants is the
>introductory statement from Mr. Big, "This company is unique." We knew it wasn't; it was
>like all the others.

Grabbing but one example of the several times I've expressed the
sentiment,
<http://groups.google.com/group/comp...17?dmode=source>

--begin quoted text:

(Business Zen: If, in all places, 'Things Are Different' then, in all
places, things are the same.)

--end quoted text

[snip]

>"In order to imitate war victories of other illustrious men and avoid defeats, a prince
>should study war histories to learn the causes of war victories and defeats."

'The Great Prince issues commands, founds states, vests families with
fiefs. Inferior people should not be employed' - I Ching

DD

2008-01-24, 7:55 am

In article <5ecae817-8dd9-4a00-b792-f5ff511f002a@e6g2000prf.googlegroups.com>,
klshafer@att.net <klshafer@att.net> wrote:

[snip]

>There is nothing
>more destructive of morale and deleterious to a project than the drip,
>drip, drip of attrition and going to work every day wondering, "Am I
>next?"

I recall seeing an advertising-poster in Grand Central Station shortly
after the Crash of 1987 - a time which caused, I believe, a fundamental
change in the American Business Model - which showed a picture of a Young
Business Type sitting in the back seat of a town-car/limousine staring
blankly out a rain-spattered window. The copy read something like:

'Which is worse... being told Friday not to come back Monday or being told
Monday you have to take up the slack?'

DD

2008-01-24, 7:55 am

In article <eb399072-2ca3-42b8-867f-35fd27546fdd@y5g2000hsf.googlegroups.com>,
klshafer@att.net <klshafer@att.net> wrote:
>
>Palliative programming? That actually is very, VERY good! So apt! So
>descriptive! I'm so glad I prompted you! I will have to tell the
>*World* that it was a Doc who coined the term!

The best I can ask for is to be cited as a source by a good scholar... a
right close second, though, is to be the recipient of royalty-checks.

DD

klshafer@att.net

2008-01-24, 6:56 pm

On Jan 23, 8:20=A0pm, Robert <n...@e.mail> wrote:
> On Wed, 23 Jan 2008 16:57:36 +1300, "Pete Dashwood" <dashw...@removethis.e=
nternet.co.nz>
> wrote:
>

Robert,

I found your list of methods/applications of interest and significant
value to me (empirically speaking, :-) ). I am gratified. Thank you.

> So are ALL Agile methods .. they say. Close inspection reveals the only di=
fference is
> shorter iterations.

I suppose that *differences* make for interesting reading, and, as
they say, for generating much heat but little light, but for me, I
find "what is common" is more interesting. Maybe because I feel such a
need to just "get along." :-)

To wit -

- Is not Agile Continuous Integration very similar to what we used to
do as Top-Down development, with stubs?
- Isn't TDD (Test Driven Development) very similar to Unit Testing
with Top-Down Development?,
- Isn't Agile "customer on site" very similar to the Analyst part of
the Analyst/Programmer (when there were such people, before they were
overcome with rote coders) walking down the Hall to see his User?
- Didn't the original Royce Waterfall article show feedback loops, not
only between adjoining steps in the SDLC, but jumping over steps, and
are not _these_ the Agile Iterations? (as in the Barry Boehm spiral
method.) (I somehow found the Royce Waterfall .pdf on the Web; if I
can find it again, and be convinced it is quasi-public-domain now, I
will post the link.)

I don't have the link, but I know I read it somewhere on the Web (so
it *must* be true :-) ), that much of Agile, and maybe the entirety of
the Agile Manifesto was in essence a _marketing move_. Let us not
begrudge them their success, to the extent that they are successful.
But neither let us lower our heads, brow beaten, through self-
submission to the thought that "They have discovered something
Entirely New, which we Know Not."

Be not mistaken now, we, and by "we" I mean those such as *I*, neo-
Classicists, Traditionalists, Pragmatic Practitioners, in a Word, we
*Journeymen*, who do not deign to call ourselves Methodology Masters,
all owe the Agilists a great debt of gratitude.

It is they (the Agilists) who have brought "refactoring" into the
popular venacular, management-wise, so that "rework" is now not always
a "dirty word". And it is they who have, more successfully than
others, driven the stake into the ground regarding what I call
Indivisibility (of effort), which contends that is very, very
difficult to completely separate analysis, design, coding, and testing
across a multitude of individuals, no matter _how_ good the
_documentation artifacts_ are.
Once upon a time, that was the rationale for "Analyst/Programmer", was
it not?.

There once was a time, and maybe it was Our Time, and yes, maybe it is
*gone* now, that all of this was Common Knowledge.

But presently, what others might see as Nouveau Secrets are really
Ancient Wisdom, mostly forgotten.

As long as there are Journeymen and Apprentices, let it be passed
down.

How could we expect it to be otherwise?

Ken

klshafer@att.net

2008-01-24, 6:56 pm

On Jan 24, 3:06=A0am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> <klsha...@att.net> wrote in message
>
>
> Sure. Can you get me the cover price :-)?
>
> Pete.

Does your bank accept cheques in $USD? Or is it better to send
International Money Order. Kindly solicit me at klshafer -at- att.net
and let us see what we can do.

Ken

Howard Brazee

2008-01-24, 6:56 pm

On Thu, 24 Jan 2008 10:04:37 -0800 (PST), "klshafer@att.net"
<klshafer@att.net> wrote:

>*Journeymen*, who do not deign to call ourselves Methodology Masters,
>all owe the Agilists a great debt of gratitude.

....

>There once was a time, and maybe it was Our Time, and yes, maybe it is
>*gone* now, that all of this was Common Knowledge.
>
>But presently, what others might see as Nouveau Secrets are really
>Ancient Wisdom, mostly forgotten.

Nice post.

I am reminded of a management seminar where the lecturer stated that
his teachings weren't the most important element of the seminar. The
most important part was the reminder that it can be good to sit back
and think about your processes - and that management was willing to
spend time and money to remind us of that. He hoped that his
insights would help people do their common sense - but the important
part wasn't learning arcane secrets - it was to be reminded to make
the analysis and work on improvement.

2008-01-24, 6:56 pm

In article <17da85f2-7c47-4ecd-b5cf-07f25f6cbbd8@j78g2000hsd.googlegroups.com>,
klshafer@att.net <klshafer@att.net> wrote:
>On Jan 24, 3:06_am, "Pete Dashwood"
><dashw...@removethis.enternet.co.nz> wrote:
>
>Does your bank accept cheques in $USD?

Perhaps not... but maybe his banque accepts checks.

DD

Alistair

2008-01-24, 6:56 pm

On 23 Jan, 03:57, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> <klsha...@att.net> wrote in message
>
> news:519b9104-a107-4f9d-b341-781c2185da40@d4g2000prg.googlegroups.com...
>
>
>
> I believe that any attempt at problem solution that is driven from a
> Language perspective will not be optimum, so looking for approaches taken
> with COBOL (as opposed to anything else) for me, is a non-starter.
>
> I apply the same problem solution approaches no matter WHAT language is in
> use.
>
>
>
>
>
>
>
>
> Pre-supposes that there ARE different domains of problem; in commercial
> computer programming this is arguable: "Get a solution implemented that
> costs as little as possible, takes as little time as possible, meets the
> Business requirements, and is comfortable for users to use." If you can
> manage to also minimise future maintenance and make the new system integrate
> nicely with current and foreseeable technical environments, that's a
> bonus...:-)
>
>
>
>
>
>
>
>
>
>
>
>
> Glass should speak for himself.
>
> Personally, I've been researching, analysing, postulating, experimenting,
> and considering this for the last 43 years. I have arrived at some
> interesting conclusions which will be published in a forthcoming book that
> will be completed later this year.
>
> I can tell you this for nothing:
>
> 1. No single one of the current methodologies works to complete satisfaction
> (with the POSSIBLE exception of DSDM...) when applied by itself, alone.
> 2. There is a marked lack of imagination on the part of both Business
> Management and Technical Management when addressing this problem.
> 3. The main reason for software engineering failures is very bright
> technical people being poorly led by managers who secretly despise them, and
> have little or no understanding of what they do/need. (Point being: It isn't
> necessarily about Methodology...)
> 4. It IS possible to formulate a General Solution to commercial software
> engineering, that will solve more than 80% of the problems projects
> encounter. (However, doing so requires vision, imagination, and acceptance
> of change which most organisations are not capable of, or simply don't
> have.) This "general solution" is possible because, at least in the domain
> of commercial software solution engineering, there are the same (or very
> similar) "general problems" that manifest thermselves on every project,
> despite the fact that EVERY Management team believes THEY are unique and
> THEIR business is completely different from everyone else's. I think this
> myopia occurs because they are not capable of the pattern recognition that
> their tech staff do instinctively.
>
> I am postulating a completely different approach, but I don't want to spoil
> it by pre-announcing it here. I WILL say that it includes the best points of
> several currently successful methodologies, along with some quite innovative
> ideas, based on my own experience and what I've found to work. I can also
> say that it is as far divorced from Waterfall as it is possible to get :-)
>
> Amazingly, I have a track record of 20 years in PM without a failure (1
> project was not completed due to international corporate politics, over
> which I had no control), yet I have NEVER implemented (completely) the
> standard approach required on any particular site. Had I done so, the
> project would have failed.:-)
>
> I believe the factors required for successful implementation are not easily
> identifiable or quantifiable and I address this in the book. Certainly some
> of them cannot be taught, but must be learned by observation and experience.
> It IS possible to raise awareness of them and suggest some approaches...
>
>
>
>
>
>
>
>
>
>
>
> Not at this stage, Ken. I believe it will be too dry and Academic to
> interest me, and I can't/won't contribute to a pissing contest about
> methodologies, none of which I believe to be perfect... :-)
>
> Nevertheless, I wish you luck with it :-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

How is your management book coming along? My offer to proof read it is
still open.

Alistair

2008-01-24, 6:56 pm

On 23 Jan, 18:26, docdw...@panix.com () wrote:
> In article <a875426b-021a-440c-adf1-a1df30729...@e23g2000prf.googlegroups.=
com>,
>
> klsha...@att.net <klsha...@att.net> wrote:
s.com>,[color=darkred]
>
at[color=darkred]
>
> [snip]
>
>
> From *me*? =A0That's utterly impossible, just ask around the newsgroup.
>
>
> That is one of the difficulties, Mr Shafer... the reconciling of 'we want
> something new' with 'we're comfortable with what we do'. =A0If 'what we do=
'
> actually *works* then I've found the primary cause of 'we want something
> new' is a new Corner-Office Idiot who wants folks to say 'Jones is really
> shaking things up there.'
>
> (never mind the fact that more work is getting done, or less, or the
> employees are more satisfied, or less... it's just 'Jones is really
> shaking things up there')
>
>
>
>
> If I could do that I'd be writing advertising-copy... 'It's this, it's
> that, it's the other thing! =A0It's all three, in one... yes, it's new
> Three-in-One!'
>
> And so... I stick to COBOL.
>
eep[color=darkred]
y,[color=darkred]
ng[color=darkred]
>
>
> It could be the shift from 'curative coding to, perhaps, 'palliative
> programming'.
>
> DD

Or perhaps: Phase Six of any project - find a new job.

Alistair

2008-01-24, 6:56 pm

On 24 Jan, 01:20, Robert <n...@e.mail> wrote:
>
> "You must know there are two ways of contesting, the one by the law, the other by force;
> the first method is proper to men, the second to beasts; but because the first is
> frequently not sufficient, it is necessary to have recourse to the second. Therefore it is
> necessary for a prince to understand how to avail himself of the beast and the man - just
> one is not enough."
>
>
> Machiavelli wrote the seminal work on software management. He said a prince who does not
> raise the contempt of the nobles and keeps the people satisfied should have no fear of
> conspirators.
>
> "If a prince seizes a state, all the required injuries should be inflicted at one stroke.
> This way it is not necessary to every day be a little evil. Injuries should be inflicted
> once, swiftly - so that it may be forgotten. A prince should however deliver frequent,
> small benefits to his people so that its positive effects last longer."
>
>
> "In order to imitate war victories of other illustrious men and avoid defeats, a prince
> should study war histories to learn the causes of war victories and defeats."- Hide quoted text -
>

Successful Software Delivery By Machiavelli? Throw in Sun Tzu and
Miyamoto Musashi and you would have a winning methodology.

Keep quoting.

Pete Dashwood

2008-01-24, 6:56 pm

<docdwarf@panix.com> wrote in message news:fn9s1a$eak$1@reader2.panix.com...
> In article
> <eb399072-2ca3-42b8-867f-35fd27546fdd@y5g2000hsf.googlegroups.com>,
> klshafer@att.net <klshafer@att.net> wrote:
>
> The best I can ask for is to be cited as a source by a good scholar... a
> right close second, though, is to be the recipient of royalty-checks.
>
> DD
>
You'd rather fame than money, Doc?

Not me.

I'm very happy to ensure that the "success" is passed to the permanent
employees (for whom I usually throw a party with a percentage of the
cash...)

While this may sound mercenary, I find that acquiring cash, rather than
being an end in itself, is a great enabler; it lets me do the things I
really want to do.

We are having a glorious summer here (yesterday was 28 and today looks like
being the same). I am able to relax and enjoy it with friends, go to the
beach, take a walk around the Mount, sit and read a book, play my guitar, or
acquire some more information on C# or whatever... I can only do this
because I maximised the money when I last worked... :-)

Work is great (and I certainly enjoy mine...) but life is greater. We need
time for life as well as work, and cash is the enabler... :-)

By April or so, I'll probably need to refill the coffers, but until then...
(raises Jack Daniels with sparkling coke and fresh lime aromas, large ice
cubes just visible through the condensation on the glass...)... very good
health to you all. :-)

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-01-24, 6:56 pm

<klshafer@att.net> wrote in message
news:8fc01a64-2f4a-4973-8b20-c1691e16661d@s8g2000prg.googlegroups.com...
On Jan 23, 8:20 pm, Robert <n...@e.mail> wrote:
> On Wed, 23 Jan 2008 16:57:36 +1300, "Pete Dashwood"
> <dashw...@removethis.enternet.co.nz>
> wrote:
>

Robert,

I found your list of methods/applications of interest and significant
value to me (empirically speaking, :-) ). I am gratified. Thank you.

> So are ALL Agile methods .. they say. Close inspection reveals the only
> difference is
> shorter iterations.

I suppose that *differences* make for interesting reading, and, as
they say, for generating much heat but little light, but for me, I
find "what is common" is more interesting. Maybe because I feel such a
need to just "get along." :-)

To wit -

- Is not Agile Continuous Integration very similar to what we used to
do as Top-Down development, with stubs?
- Isn't TDD (Test Driven Development) very similar to Unit Testing
with Top-Down Development?,
- Isn't Agile "customer on site" very similar to the Analyst part of
the Analyst/Programmer (when there were such people, before they were
overcome with rote coders) walking down the Hall to see his User?
- Didn't the original Royce Waterfall article show feedback loops, not
only between adjoining steps in the SDLC, but jumping over steps, and
are not _these_ the Agile Iterations? (as in the Barry Boehm spiral
method.) (I somehow found the Royce Waterfall .pdf on the Web; if I
can find it again, and be convinced it is quasi-public-domain now, I
will post the link.)

I don't have the link, but I know I read it somewhere on the Web (so
it *must* be true :-) ), that much of Agile, and maybe the entirety of
the Agile Manifesto was in essence a _marketing move_. Let us not
begrudge them their success, to the extent that they are successful.
But neither let us lower our heads, brow beaten, through self-
submission to the thought that "They have discovered something
Entirely New, which we Know Not."

Be not mistaken now, we, and by "we" I mean those such as *I*, neo-
Classicists, Traditionalists, Pragmatic Practitioners, in a Word, we
*Journeymen*, who do not deign to call ourselves Methodology Masters,
all owe the Agilists a great debt of gratitude.

It is they (the Agilists) who have brought "refactoring" into the
popular venacular, management-wise, so that "rework" is now not always
a "dirty word". And it is they who have, more successfully than
others, driven the stake into the ground regarding what I call
Indivisibility (of effort), which contends that is very, very
difficult to completely separate analysis, design, coding, and testing
across a multitude of individuals, no matter _how_ good the
_documentation artifacts_ are.
Once upon a time, that was the rationale for "Analyst/Programmer", was
it not?.

There once was a time, and maybe it was Our Time, and yes, maybe it is
*gone* now, that all of this was Common Knowledge.

But presently, what others might see as Nouveau Secrets are really
Ancient Wisdom, mostly forgotten.

As long as there are Journeymen and Apprentices, let it be passed
down.

How could we expect it to be otherwise?

Ken

[Pete:]

An excellent post, Ken. There is much wisdom in what you say above.

Certainly, the Ancient Wisdom has been re-invented many times, and
re-marketed, and it is certainly true that unless Management are provided
with simple (usually one word) hooks like "refactoring", then the REAL work
is made much more difficult for everybody.

They have neither time nor inclination to understand what is actually going
on in Development and this creates severe anxiety (especially when they see
the cost of it...) If they can be given something that they "know" is right
there and up with current "Best Practices" (don'tcha just LOVE "Best
Practices"?...especially when it is used to cover some of the most senseless
and stupid decisions imaginable :-)), then it is like a cuddle blanket and
has a calming effect.

I've had a lot of contact with Managers over the years, including Doc's
"Corner Office Idiots" (COI). In general, Senior management (say, Board
level) are pretty astute and recognise that they don't know about IT. Their
approach is to buy expertise and get the best they can. It is usally the
middle managers and COIs who have SOME knowledge, that lose sight of the
real agenda and instead, look for the line of least resistance and short
term solutions. These same guys are often much more concerned about
building/protecting their own little empires than they are about providing
service to the Business. That is why there are so many IT departments with
incoherent strategies, risky tactical solutions, and Business departments
(Clients of IT) that think IT stinks...

A fundamental for success is Management buy-in. That is NOT COI buy-in
(although that is very useful, too...) it is SENIOR management buy-in. Of
course, to get this you have to establish credibility, and I have gone to
extreme lengths (and taken risks that made me shudder in retrospect :-)) on
many occasions to get it.

IT, especially when change is being introduced, needs the support of Senior
management.

As a consultant being brought in to manage something, I know I will
encounter animosity from the middle management. I deal with it in the
following ways:

1. Sit down with the COIs and assure them I am not after their jobs or
trying to make them look bad. Any and all "success" will be attributed to
them (and their teams, of course). (See post in response to Doc,
elsewhere...)

2. Make sure I have direct access to Senior Management and have primed them
with what I intend to do and the likely problems that will be encountered.
When issues arise with COIs, we negotiate and look for compromise. If none
is forthcoming, then it gets escalated to Board level. (I have only had to
do this very rarely, and it is always with the COI who is a control freak.
The kind who uses standards to inhibit and stifle, rather than to support
and ensure consistency. Unimaginative, incapable of thinking outside the
box, or even considering any solution that might violate one line of
"Standard Procedure". The kind who really should be a guard in a prison camp
(nobody leaves the site without his permission... and so on...) These guys
are walking examples of the Peter Principle...)

Once we have this nonsense sorted, I can sit down with the team and we can
get on with the REAL work.

Tech teams seem to enjoy working with me... :-) (I certainly enjoy working
with bright young people...)

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-01-24, 6:56 pm

<klshafer@att.net> wrote in message
news:17da85f2-7c47-4ecd-b5cf-07f25f6cbbd8@j78g2000hsd.googlegroups.com...
On Jan 24, 3:06 am, "Pete Dashwood"
<dashw...@removethis.enternet.co.nz> wrote:
> <klsha...@att.net> wrote in message
>
>
> Sure. Can you get me the cover price :-)?
>
> Pete.

Does your bank accept cheques in $USD? Or is it better to send
International Money Order. Kindly solicit me at klshafer -at- att.net
and let us see what we can do.

[Pete:]

The book is currently 75% written and I intend to finish it before end of
April this year. It will be POD published, as I have a number of writers
here who also want to get their books on the Net, and I will set up a Web
site that they can use too. This means you will be able to order it and pay
for it on-line, and receive it to your postal address within 7 days.

I don't expect people to buy a pig-in-a-poke, and excerpts of it will be
made available when it is ready for publication.

Thanks for your support, Ken. (I'll organise a signed copy for you... :-))

Pete.
--
"I used to write COBOL...now I can do anything."

Pete Dashwood

2008-01-24, 6:56 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:89cb04cd-7242-4a6c-839c-32914d1cded3@1g2000hsl.googlegroups.com...
> On 23 Jan, 03:57, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
> How is your management book coming along? My offer to proof read it is
> still open.

Thanks Alistair.

I am currently reviewing what I have (about 75% of the total). I'll send you
a proof copy for review when I have 100%.

Pete.
--
"I used to write COBOL...now I can do anything."

2008-01-24, 9:56 pm

In article <5vsi8cF1nflagU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
><docdwarf@panix.com> wrote in message news:fn9s1a$eak$1@reader2.panix.com...
>You'd rather fame than money, Doc?

One does not rule out the other, Mr Dashwood; one can ask for the best,
the second-best, the third-best... all the way down to a sub-zero sausage,
sometimes called the 'absolute wurst'. As... someone pointed out in a
posting to This Very Newsgroup, nigh a decade back:
<http://groups.google.com/group/comp...43?dmode=source>

--begin quoted text:

As I've said many times: 'Honor is a wonderful coin... but my landlord
doesn't accept it.'

--end quoted text

>
>Not me.

Well, if all you can think of is to ask for one OR the other to the
exclusion of any else... have at it!

DD

Robert

2008-01-24, 9:57 pm

On Thu, 24 Jan 2008 10:04:37 -0800 (PST), "klshafer@att.net" <klshafer@att.net> wrote:

>On Jan 23, 8:20_pm, Robert <n...@e.mail> wrote:
>
>Robert,
>
>I found your list of methods/applications of interest and significant
>value to me (empirically speaking, :-) ). I am gratified. Thank you.
>
>
>
>I suppose that *differences* make for interesting reading, and, as
>they say, for generating much heat but little light, but for me, I
>find "what is common" is more interesting. Maybe because I feel such a
>need to just "get along." :-)

Sounds like you have management potential. :)

>To wit -
>
>- Is not Agile Continuous Integration very similar to what we used to
>do as Top-Down development, with stubs?
>- Isn't TDD (Test Driven Development) very similar to Unit Testing
>with Top-Down Development?,

An 'old wine in new bottles' argument is unpersuasive because it makes the advocate sound
like a sore loser.

>- Isn't Agile "customer on site" very similar to the Analyst part of
>the Analyst/Programmer (when there were such people, before they were
>overcome with rote coders) walking down the Hall to see his User?

Usually not. Rarely can a programmer detach himself to truly think like a user.

I've learned from experience that knowing more then the user about his own technical
specialty, such as accounting, law and statistics, really pisses them off. :)

>- Didn't the original Royce Waterfall article show feedback loops, not
>only between adjoining steps in the SDLC, but jumping over steps, and
>are not _these_ the Agile Iterations? (as in the Barry Boehm spiral
>method.)

Yes, it does. Royce warns against a monotonic ("waterfall") process here:

"... the implementation described above is risky and invites failure. The testing phase
which occurs at the end of the development cycle is the first event for which timing,
storage, input/output transfers, etc., are experienced as distinguished from analyzed.
These phenomena are not precisely analyzable. ... Yet if these phenomena fail to satisfy
the various external constraints, then invariably a major redesign is required. A simple
octal patch or redo of some isolated code will not fix these kinds of difficulties. The
required design changes are likely to be so disruptive that the software requirements upon
which the design is based and which provides the rationale for everything are violated.
Either the requirements must be modified, or a substantial change in the design is
required. In effect the development process has returned to the origin and one can expect
up to a lO0-percent overrun in schedule and/or costs."

His argument is based on inadequate hardware being the greatest danger. The system is too
slow. That was widely believed in 1970, and I believe prematue optimization was the
greatest CAUSE of bad system design. I see it every day, 38 years later, on hardware that
runs a thousand times faster than computers did in 1970. The genesis of this attidude is
in the techie psyche, not the real world where users live.

Thus, a development process that revolves around 'optimized code' is a non-starter. The
process SHOULD revolve around the user.

>(I somehow found the Royce Waterfall .pdf on the Web; if I
>can find it again, and be convinced it is quasi-public-domain now, I
>will post the link.)

Here's the link:
http://www.cs.umd.edu/class/spring2...s/waterfall.pdf

>I don't have the link, but I know I read it somewhere on the Web (so
>it *must* be true :-) ), that much of Agile, and maybe the entirety of
>the Agile Manifesto was in essence a _marketing move_. Let us not
>begrudge them their success, to the extent that they are successful.
>But neither let us lower our heads, brow beaten, through self-
>submission to the thought that "They have discovered something
>Entirely New, which we Know Not."
>
>Be not mistaken now, we, and by "we" I mean those such as *I*, neo-
>Classicists, Traditionalists, Pragmatic Practitioners, in a Word, we
>*Journeymen*, who do not deign to call ourselves Methodology Masters,
>all owe the Agilists a great debt of gratitude.

You are being sardonic.

>It is they (the Agilists) who have brought "refactoring" into the
>popular venacular, management-wise, so that "rework" is now not always
>a "dirty word". And it is they who have, more successfully than
>others, driven the stake into the ground regarding what I call
>Indivisibility (of effort), which contends that is very, very
>difficult to completely separate analysis, design, coding, and testing
>across a multitude of individuals, no matter _how_ good the
>_documentation artifacts_ are.

Royce says divisibility is the acid test for adequate documentation.

" Many parts of the test process are best handled by test specialists who did not
necessarily contribute to the original design. If it is argued that only the designer can
perform a thorough test because he understands the area he built, this is a sure sign of a
failure to document properly."

>Once upon a time, that was the rationale for "Analyst/Programmer", was
>it not?.

It's just job title inflation. In some shops, everyone has been promoted to Senior
Technical Analyst or Lead Technical Engineer; there aren't any inadjectivated Developers.
In at least one state, Wisconsin, real engineers sued to stop debasement of their
occupational title.

>There once was a time, and maybe it was Our Time, and yes, maybe it is
>*gone* now, that all of this was Common Knowledge.
>
>But presently, what others might see as Nouveau Secrets are really
>Ancient Wisdom, mostly forgotten.

The evolution of methodologies is the confluence of two sets of cycles. The first is the
generational cycle brilliantly described by Strauss and Howe in their book Generations.
The second is the tug of war between users and management and techies. In both, attempts
to correct past deficiencies overshoot the mark and become candidates for correction
during the next iteration. The path is not as simple as a two-dimensional sine wave.
Because of multiple degrees of freedom (dimensions), there can be multiple stages before
the supercycle starts over. There are four stages in the Generations model: Hero,
Technocrat/Artist, Puritan/Yuppie and XGen/Punk (my terminology). A methodology that seems
right to one generational style will seem all wrong to its successor. For example, the
Artistic style that you seem to favor seems undisciplined to Yuppies, who don't trust
anyone to do things right, least of all themselves. That's how we got Waterfall, which
seems too rigidly structured to XGens, who just want to get the job done as quickly as
possible. That XGens also disdain beautiful code shows the cycles are not simple
oscillation.

http://en.wikipedia.org/wiki/Generations_%28book%29

2008-01-25, 7:55 am

In article <dn9ip39ak344qlvd5clil31hvvi5gdcbao@4ax.com>,
Robert <no@e.mail> wrote:

[snip]

>Here's the link:
>http://www.cs.umd.edu/class/spring2...s/waterfall.pdf

Waw haw haw haw... this guy's *serious*? Give this a listen, from .pdf
page 5 (showing book page 332):

--begin quoted text

Step 2: DOCUMENT THE DESIGN

At this point it is appropriate to raise the issue of - 'how much
documentation?' My own view is 'quite a lot'; certainly more than most
programmers, analysts or program designers are willing to do if left to
their own devices. The first rule of managing software development is
ruthless enforcement of documentation requirements.

Occaisionally I am called upon to review the progress of other
software design efforts. My first step is to investigate the state of
documentation. If the documentation is in serious default my first
recommendation is simple. Replace project management. Stop all
activities not related to documentation. Bring the documentation up to
acceptable standards.

--end quoted text

All righty, by a show of hands... has anyone ever seen anything like this
happen?

(My experience, of course, is with 'sick shops' so I haven't run across an
instance of a single manager - let along an entire project's management -
being replaced because documentation was not 'up to acceptable standards',
even where 'acceptable' was construed as 'scribble something in cuneiform
- Akkadian or Hittite, your choice - on a bit of bathroom-tissue'.)

DD

Alistair

2008-01-25, 6:56 pm

On 24 Jan, 23:17, "Pete Dashwood"
> Tech teams seem to enjoy working with me... :-) (I certainly enjoy working
> with bright young people...)
>

Many years ago I said to a senior manager that the user was happy with
the system because he had never complained about it. I was wrong (I
was not aware of the complaints that he had made). Just because people
wear happy smiley faces does not necessarily mean that they enjoyed
working with you. It may just mean that they are stoned. And I have
been known to attend leaving dos just to ensure that we've finally got
rid of the individual concerned.

Alistair

2008-01-25, 6:56 pm

On 24 Jan, 23:33, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Alistair" <alist...@ld50macca.demon.co.uk> wrote in message
>
> news:89cb04cd-7242-4a6c-839c-32914d1cded3@1g2000hsl.googlegroups.com...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks Alistair.
>
> I am currently reviewing what I have (about 75% of the total). I'll send you
> a proof copy for review when I have 100%.
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."- Hide quoted text -
>
> - Show quoted text -

Cheers, I can't wait :-)

2008-01-25, 6:56 pm

In article <bde70ea5-7ba0-44f2-b903-0cc794a6aeb7@q21g2000hsa.googlegroups.com>,
Alistair <alistair@ld50macca.demon.co.uk> wrote:
>On 24 Jan, 23:17, "Pete Dashwood"
>
>Many years ago I said to a senior manager that the user was happy with
>the system because he had never complained about it. I was wrong (I
>was not aware of the complaints that he had made).

Well, now that you mention it... years on back I had a contract at a place
where the consultants were used as pawns in Corner-Office Wars. Given a
simple rectangular arrangement it went something like this:

Corner-Office Idiot A comes out of the top-left office, looks around and
snarls 'Bah! Not enough getting done here, bring in some consultants!'

They'd then bring in a raft of consultants/contractors/hired guns, between
twelve and twenty... and folks would get ID badges and logons, find out
where the source libraries were, start to get a handle on things and begin
to do some work...

.... and then Corner-Office Idiot B would come out of the top-right office,
look around and snarl 'Bah! Too many consultants here, costs too much
money... get rid of them!'

.... and folks would pack up and go, and work would pile up and deadlines
start to slip... and then Corner-Office Idiot C would come out of the
bottom-right office and snarl 'Bah! Not enough getting done here, bring
in some consultants!'...

.... and another dozen or so folks would be brought in, get ID badges,
logons, etc.

Anyhow... I'd been there for a while, a Corner-Office Idiot came out and
said 'Too many consultants!' and a bunch of folks (I was not included)
were given two w

s' notice.

Being consultants/contractors/hired guns they began to behave as Dead Men
do; they hit the telephones and began calling up friends, agencies, pimps,
telephone-numbers they saw on restroom walls... and began looking for new
contracts. Listening to folks the next desk/cubicle over trying to wangle
new work did not have a good effect on morale.

So... the Corner-Office Idiot has a brilliant ides: Consultants Don't Need
Telephones. (this was in the Oldene Dayse, before cellular service) We
all came in one day, those leaving and those staying, and saw our desks
telephonically denuded... and the problem was solved, right?

Well... maybe *that* problem was solved... but others generated. Later
that day the Idiot went over to the Lead Consultant's desk - the Lead,
like me'n another fellow or two, were spared during the firing - and asked
'Well, what about those ABEND problems they've been having in the Prod
online system?'

The Lead looked over to the naked, dusty spot where the telephone had been
and said 'Oh, I haven't heard anything about those all morning'...

.... and the Idiot brusquely said 'Very good, very good... no news is good
news' and strode off.

DD

Charles Hottel

2008-01-25, 6:56 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:7046e06f-2944-4fd6-8e01-94c42d579b58@v67g2000hse.googlegroups.com...
> On 24 Jan, 23:33, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
> Cheers, I can't wait :-)

Hey, I'd like a free, ah, oh, a err, ... I mean a proof copy too!

klshafer@att.net

2008-01-25, 6:56 pm

On Jan 24, 10:47=A0pm, Robert <n...@e.mail> wrote:
> On Thu, 24 Jan 2008 10:04:37 -0800 (PST), "klsha...@att.net" <klsha...@att=
..net> wrote:

> An 'old wine in new bottles' argument is unpersuasive because it makes the=
advocate sound
> like a sore loser.

If I take comfort in discovery of Eternal (or at least Persistent)
Threads, what care *I* about whether others are unpersuaded? For me, a
successful project is one where I leave things a bit better than when
I came, with integrity, that I be paid adequately for it, and that I
be Happy. Should that coincide, even approximately, with others' needs
such as 'Meets Requirements', 'Within Budget', and 'On Time' - then so
much the better.

> Here's the link:http://www.cs.umd.edu/class/spring2...38p/Process/wa=
terfall.pdf

Thanks for the lookup - yes, that is the one! :-)

>
> You are being sardonic.

Actually, no. Really. It *is* simply as stated something that I
believe.

>
> Royce says divisibility is the acid test for adequate documentation.
>
> " Many parts of the test process are best handled by test specialists who =
did not
> necessarily contribute to the original design. If it is argued that only t=
he designer can
> perform a thorough t