Re: Mapping (CoBOL) Methodologies to Problem Domains

On Fri, 25 Jan 2008 09:17:36 -0800 (PST), "klshafer@xxxxxxx" <klshafer@xxxxxxx> wrote:

On Jan 24, 10:47 pm, Robert <n...@xxxxxx> wrote:
On Thu, 24 Jan 2008 10:04:37 -0800 (PST), "klsha...@xxxxxxx" <klsha...@xxxxxxx> 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.

If software DOESN'T meet requirements and budget, sooner or later they'll assign the work
to someone else, which will make you UNhappy. :)


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."

Robert Glass makes the case more succintly and more articulately than
I can. In his landmark (for me) _Facts and Fallacies of Software
Engineering_, he sets forth Fact #29:

'Programmers shift from design to coding when the problem is
decomposed to a level of primitives that the designer understands. If
the coder is not the same person as the designer, the designer's
primitives are unlikely to match the coder's primitives, and trouble
will result.'

Commentary by me on what I think is a brilliant insight by Glass: If
the designer and coder are different people, then three situations are
possible - (1) the designer primitives are at the same level of
abstraction as the coder wants; (2) the designer primitives are at a
level of abstraction more detailed than the coder wants; or (3) the
primitives are at a level of abstraction more *general* than the coder
can handle.

Scenario (1), in my opinion is the least likely to occur. And that is
why we have trouble.

When Scenario (2) occurs, we all know what the coder does - he simply
throws away the design spec! Haven't all of us done that? :-)

When Scenario (3) occurs, what we have is "churn". As first-iterated
coded, just a little bit of testing reveals the program falls far
short of its "intended purpose", and then we go into a loooonnng cycle
of code-and-fix.

Scenario (3) is how good programmers learn to be better, and mediocre ones learn they
don't have what it takes. When the first attempt falls short, don't try to fix it, rewrite
from scratch.

This has profound implications for the phenomenon of "outsourcing".

My team was outsourced this week. The outsource company will do the same work with the
same people making the same money, for 60% of the cost. The only differences will be
management and the length of a work week.

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

It's just job title inflation.

Hmmmm.. I rather think Analyst/Programmer is an honest attempt to deal
with the Indivisibility issue described above.

But I do grant you, with much appreciation, that Analyst/Programmer
would fall into that Technocrat/Artist generational category that you
so clearly communicated to me.

Programming management inherits from the problem solving style outside computers. The
technocrat generation is now aged 65 and above. Former yuppies, who gave us waterfall, are
aged 45 to 64. Today's programmers are mostly XGens, who respect pragmatism over
bureaucratic structure.

The ones to watch are the generation behind them, the Millennials, now under 27. They'll
laugh in your face if you tell them to work 60 hours a week. They want it all, want it to
work the first time and want it NOW. I think they'll change programming more than any
previous generation.

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.

Wow, this last section I find very, very helpful to my understanding -
with your permission, I would like to excerpt it, along with the link
below, to cross-post (without attribution), in that other forum.
Really... and I am not being sardonic :-).

Please do, but I think the four generational styles should be explained with examples such
as US Presidents. Good talking points would be why Jimmy Carter, the ineffective
technocrat, was relaced by a step backward to the heroic Reagan. Historically, a
generation took political power 40 years after its first birth. For yuppies, that would
have been the 1988 presidential election between G.H.W. Bush and Michael Dukakis. Why was
there no yuppie candidate? The only serious yuppie contender from either party was Al
Gore, who was 40. Dan Quayle, Bush's VP, was the token yuppie in the election. I think I
know why they held back (until Clinton), but would be interested to hear others'
hypotheses.

The Strauss & Howe generaltional model applies only to Anglo countries. Suppose WE have a
spoiled rotten generation with poor work ethic (Millennials), but India or China has one
with a strong work ethic. Wouldn't it make sense to move software development to the more
salubrious country? Suppose further that country has a long tradition of superior
education.

I remember helping a Japanese 10th grader with his math homework. He was doing
differential equations. I said this is a college subject in the US; you must be in an
honors or accelerated program, right? The answer as nope, this is normal curriculum that
every student takes. I thought to myself, shit in forty years these people will bury us.
Looks like I was right.

.

Relevant Pages

  • Re: workaround for generating gui tools
    ... > the text-world than with a good designer like qt-designer. ... think of the HTML widgets as having capabilities much like Tkinter ... your "core app" doesn't itself look like one. ... off would put most C programmers off their feed, ...
    (comp.lang.python)
  • Re: Evolution and Observation Gap
    ... We learned our designer is an ancient inhuman intelligence, ... Code implies a coder. ... Since dna antedates human life, ...
    (talk.origins)
  • Re: Mapping (CoBOL) Methodologies to Problem Domains
    ... decomposed to a level of primitives that the designer understands. ... the designer and coder are different people, ... generational cycle brilliantly described by Strauss and Howe in their book Generations. ...
    (comp.lang.cobol)
  • Re: Design flow for Code-behind
    ... The coder creates a simplet interface in the skin with the controls defined. ... interface with the HTML the designer gives him and makes his changes. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Why is web design so damned complicated?
    ... designer and have had no problems learning the rules of the road when it ... it's programmers like that that have gotten use farther and farther ... widgets. ...
    (microsoft.public.publisher.webdesign)