"Mick" wrote in message
news |
| Jacksons Structured Programming springs to mind.
| When i was learning the black art of COBOL programming many moons
ago we
| *had* to produce a flowchart ON PAPER
| and dry run it, again on paper before we where allowed anywhere near
a
| keyboard !
| Just my 2 cents worth
|


I mentioned "flowcharting" for a good reason, as an experienced
flowcharter/programmer will readily concede, if it works on paper then
the probability that it will work in real code is very high. In fact,
tho I was not seriously fond of flowcharting, I fortunately learned
early on that when the time was taken to flowchart a project in the
beginning, the end coding/debugging time was significantly reduced
versus the "jump in there and cut some code" approach.

Heh, I suppose your COBOL days were back in the day when CPU time was
billed/paid-for in tenths of seconds eh? Thank the Lord I did not
have to learn much more than that COBOL used verbs and subjects names
and such, lol. My upbringing in the software world coincided nicely
with the introduction of the Intel 4004, 8008 and 8080 (late 70's) so
my painful experiences with mainframe and mini-computer setups was,
quite fortunately, limited to one deck of punch-cards dropped on the
floor at college. A seasoned veteran typically has many juicy
"dropped deck" or "deck destroyed by punch card reader" stories.

Regarding the other posts about the quality of programmers, I have no
doubt that some are not really good code-cutters. I experienced such
when I worked as an engineer for GM. Many good people, not that many
really good programmers.

Of particular consideration though is the never ending progress of the
computing world. Noting that the computing world's "state of
technology" is constantly in the process of evolution, I do sympathize
with programmers from the perspective that one must continually
discard old and reliable (and well known) tools and start anew and
learn to use new programming tools (most with their own new set of
bugs/character flaws), which process creates its own new
challenges/headaches/learning booboos.

As to products such as installers and in particular the Microsoft
Installer, all I can say is what a miserably conceived POS (and yes, I
have taken a look at its underlying capabilities during a painful time
when I experienced the malady of every time I restarted my win2k
system the MS Installer fired up 4 or 5 times trying to install some
program that was already installed). Whenever a software tool
requires mastery of a cryptic set of commands, the outcome is not
surprisingly what we see with the MSI installer/uninstaller problem
arena. It's no wonder the registry is a mess after taking a hard look
at MSI. In fact, I nowadays get a warm-fuzzy when I see a new program
I am installing does NOT use MSI.

--
Best regards,
Kyle