Home > Archive > Cobol > June 2007 > COBOL is Number One
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
COBOL is Number One
|
|
|
|
|
| On Jun 3, 8:47 pm, "Charles Hottel" <chot...@earthlink.net> wrote:
> on the list of top 10 dead (or dying) computer skills:
>
> http://www.computerworld.com/action...ewArticleBas...
>
> or if this wraps trywww.computerworld.com/careers
Sure, that's true. There's simply the matter of how many existing
billions of lines of code currently running in production, plus all
the current code being created every day, oh and the millions of
dollars needed to convert Cobol to X-language. Other than that, it's
as dead as Jimmy Hoffa, or will be in another X years. Phew, glad
that's settled, lol.
Even at my workplace they are pushing big for Java as the front end,
but Cobol will still be the back end, so to speak. Plus our Java
people keep quitting, so that's a bit of a snag.
Cobol: The New Back End
| |
|
| Charles Hottel wrote:
> on the list of top 10 dead (or dying) computer skills:
Interesting. COBOL is more obsolete than OS/2. heh... I've used COBOL
a *lot* more recently than I've used OS/2!
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com/linux/blog ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| Pete Dashwood 2007-06-04, 7:55 am |
|
"Impy" <Impy.McFerguson@gmail.com> wrote in message
news:1180925017.731346.135590@w5g2000hsg.googlegroups.com...
> On Jun 3, 8:47 pm, "Charles Hottel" <chot...@earthlink.net> wrote:
>
>
> Sure, that's true. There's simply the matter of how many existing
> billions of lines of code currently running in production, plus all
> the current code being created every day, oh and the millions of
> dollars needed to convert Cobol to X-language. Other than that, it's
> as dead as Jimmy Hoffa, or will be in another X years. Phew, glad
> that's settled, lol.
All of that is negated if the existing systems are replaced. Whether by a
package or by moving to a different development platform that refactors
legacy code. No maintenance, no conversion. You can wrap existing COBOL
functions and programs and continue running them until you actually NEED to
replace them... (I've been doing this with C# and it is quite simple; Java
can do it too...)
Don't be too smug. I believe X is NOT > 8.
>
> Even at my workplace they are pushing big for Java as the front end,
> but Cobol will still be the back end, so to speak.
And, as expertise in Java increases, they will see less and less need to
maintain two schools of programming. The Java guys will be building
component based solutions using OO, and the COBOL guys will be maintaining
COBOL ... How long would you see that scenario lasting?
Within 20 years there won't be programmers (as we understand the term) in
organizations anyway. End users will use natural language and graphical
front ends to do whatever they want done and code will be generated by
software. It will be encapsulated and reused automatically. Maintenance of
source code is unnecessary, expensive, and error prone.
>Plus our Java
> people keep quitting, so that's a bit of a snag.
:-) Maybe they don't feel welcome (or understood... ), or maybe they are
being told to write COBOL in Java...or maybe they can get better offers
(unlike the COBOL guys whose options are severely limited.) Whatever the
reason, it will only delay the inevitable;
COBOL will be phased out because it is simply too expensive to write in
today's world. Those billions of lines of code you mentioned were mostly
written during the latter half of the last century when there was no other
option. Gartner claim there are still about 3 billion lines a year being
written, but even if this were true (and I seriously doubt it), it means
nothing if the systems are replaced, as mentioned above.
> Cobol: The New Back End
I'm sure many here have maintained COBOL that looked like it came from
SOMEONE's back end... :-)
The distinction between front and back end processing is already blurring
and will eventually fade to a single unified transactional system, as
hardware and software continues advancing to the point where the most
complex transactions can be fully completed online. Databases and
warehouses will become real time repositories, modelling the real world and
giving accurate pictures at any level required, including summaries and time
series, up to the millisecond.
I don't think we'll be doing it in COBOL.
Pete.
| |
| Pete Dashwood 2007-06-04, 7:55 am |
|
"Charles Hottel" <chottel@earthlink.net> wrote in message
news:KaK8i.13307$296.11284@newsread4.news.pas.earthlink.net...
> on the list of top 10 dead (or dying) computer skills:
>
> http://www.computerworld.com/action...&intsrc=kc_feat
>
> or if this wraps try www.computerworld.com/careers
>
>
I'm not entirely convinced of the accuracy of some of this, although the
gist of it is hard to argue against. Certainly, COBOL is in decline, but I
don't think the article addresses the reasons for this at all well. To
simply say that Universities generally (a few exceptions) are not teaching
it, is a bit of a "chicken and egg" scenario in my opinion. A good reporter
would have tried to find out WHY they are not teaching it; we don't expect
Acadaemia to simply follow fashion without good reasons.
There are many good reasons for the decline of COBOL; I couldn't find any of
them in this article. It seemed to be based on hearsay and the views of a
very limited number of interviewed people, who may or may not be well
informed about it.
Even if they are right, and COBOL is the top dying computer skill, there are
still reasons why knowledge of it could be useful.
For myself, I've never regretted learning it.
Pete.
| |
| Pete Dashwood 2007-06-04, 7:55 am |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:ju2dncUdJ6KUDv7bnZ2dnUVZ_s3inZ2d@co
mcast.com...
> Charles Hottel wrote:
>
> Interesting. COBOL is more obsolete than OS/2. heh... I've used COBOL a
> *lot* more recently than I've used OS/2!
>
The announcemnet about OS/2 is apparently official; no such announcement has
been made about COBOL... :-)
Pete.
| |
| Alistair 2007-06-04, 7:55 am |
| On 4 Jun, 11:25, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Impy" <Impy.McFergu...@gmail.com> wrote in message
>
>
> I'm sure many here have maintained COBOL that looked like it came from
> SOMEONE's back end... :-)
I don't normally use this phrase but: ROFL.
Some of us still write Cobol that way! ;-)
| |
| Alistair 2007-06-04, 7:55 am |
| On 4 Jun, 11:25, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
>
> The distinction between front and back end processing is already blurring
> and will eventually fade to a single unified transactional system, as
> hardware and software continues advancing to the point where the most
> complex transactions can be fully completed online. Databases and
> warehouses will become real time repositories, modelling the real world and
> giving accurate pictures at any level required, including summaries and time
> series, up to the millisecond.
>
> I don't think we'll be doing it in COBOL.
>
> Pete.
Too late. Britannia Music ( ly now demised) wrote their sales order
and warehousing systems in Cobol and they were online realtime.
| |
| Pete Dashwood 2007-06-04, 7:55 am |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1180956260.164378.186050@w5g2000hsg.googlegroups.com...
> On 4 Jun, 11:25, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
> Too late. Britannia Music (ly now demised) wrote their sales order
> and warehousing systems in Cobol and they were online realtime.
>
With no BackEnd (batch) processing?
Pete.
| |
| Michael Mattias 2007-06-04, 7:55 am |
| "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5ci7kcF30ujccU1@mid.individual.net...
>
> Within 20 years there won't be programmers (as we understand the term) in
> organizations anyway. End users will use natural language and graphical
> front ends to do whatever they want done and code will be generated by
> software. It will be encapsulated and reused automatically. Maintenance of
> source code is unnecessary, expensive, and error prone.
Programmers (as we understand the term then) may be using natural language
and graphical front ends to create applications, but end users? I think not.
It will be pretty much as it is today except the tools will be more
powerful.
MCM
| |
|
| Pete Dashwood wrote:
> "LX-i" <lxi0007@netscape.net> wrote in message
> news:ju2dncUdJ6KUDv7bnZ2dnUVZ_s3inZ2d@co
mcast.com...
> The announcemnet about OS/2 is apparently official; no such announcement has
> been made about COBOL... :-)
Right - so why does COBOL rank ahead of OS/2? (It's a shame too - back
in the day, OS/2 rocked! I ran a 3-node BBS on an OS/2 box, with no
problems. I switched it over to NT 3.51, and it was never the same.)
I must say, though, in NT 3.51's defense, that it was a *ton* better
than Windows 3.11. I had gone to OS/2 from Windows 3.11 because it
sucked so bad. I renamed "win.com" to "lose.com", so to start Windows,
you had to type "lose" instead of "win". ;) (And, of course, I had
started trying Windows because I could only run one node under DOS.)
darn - now I've gone and dated myself...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com/linux/blog ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
|
| In article <5ci7kcF30ujccU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
[snip]
>Within 20 years there won't be programmers (as we understand the term) in
>organizations anyway. End users will use natural language and graphical
>front ends to do whatever they want done and code will be generated by
>software. It will be encapsulated and reused automatically.
Mr Dashwood, this prediction's been around, in one form or another, for a
few decades now... I recall it being made when users began to get access
to QMF. Please pardon me if my reaction is not as... positive and
encouraging as yours.
What you describe may work well with reporting functions - 'tell me what I
want about whom I want' - as long as the Prod system doesn't get tied up
with too many Cartesian joins. Insofar as modifying data in Prod... I've
seen enough systems designed by 'The Professionals' which allow for
incorrect/inappropriate update that I'd be a bit... wary about allowing
each and every 'end user... us(ing) natural language' to, say, change
personnel and claim records.
Not everything is the equivalent of a cash-register or library-book
inventory system... and even *those* 'simple' mechanisms get thrown
out-of-balance by people familiar with their use. I recall posting
something about this before... ahhhhhh, there it is,
<http://groups.google.com/group/comp...78?dmode=source>
(moderately lengthy quotation follows)
--begin quoted text:
>I don't see immediately how the architecture of a typical COBOL application
>would manage to accomplish this easily. For existing function, it seems
>that there is a multi phase approach that is required - the extraction of
>business rules that define the operation (what is needed to update a
>customer), the extraction of the logic rules (who and how is this allowed)
>and the creation of the presentation of the rules.
Let me sing this back to see if I'm learning the song.
1) Initiate customer update request.
A) Does the initiating user have any customer update authority?
i) No - send 'not you, buddy' notice and terminate transaction
ii) Yes - CONTINUE.
2) Prepare to and accept user input to identify customer for update.
3) Validate input
A) is input in valid format (all letters/numbers in the right places)?
i) No - send 'bad format' message and GO TO 2)
ii) Yes - see if customer exists in system
a) No - send 'not here - re-enter or use A)dd function'
and GO TO 2)
b) Yes - does user have auth to update this class of customer?
1) No - send 'lowly peon' msg and GO TO 2
2) Yes - CONTINUE
4) Prepare to and accept user input to modify identified customer.
5) Validate input
A) is input in valid format (codes entered are valid update types)?
i) No - send bad code(s) msg and GO TO 4)
ii) Yes - are codes valid for this kind of customer?
a) No - send 'not for this one, you don't' msg and GO TO 4)
b) Yes - send 'are you sure?' msg and get response
1) is response valid?
A) No - send 'Y/N, please?' msg and GO TO 5.A.ii.b
.... etc.
Now... the question of 'the extraction of business rules' and 'the
extraction of logic rules' is where it gets sticky. Take the example of
an insurance-claims system. It seems logical and businesslike to allow
for a claim to be made for the treatment of uterine infections... BUT NOT
if the policy's group doesn't have a rider to cover such treatments...
.... then it's OK... BUT NOT IF the claimant is a male...
.... BUT IF the claimant is a male who has a female relative who is also
covered by the policy then it's OK...
.... BUT NOT IF the claimant is a male who has a female relative who is
also covered who has had a hysterectomy...
.... BUT IF the claimant is a male who has a female relative who is also
covered who has had a hysterectomy AND the date of the hysterectomy is
greater than the date of the uterine infection treatment (someone left the
claim in a drawer for six months) then it's OK...
.... BUT NOT IF the claimant is a male who has a female relative who is
also covered who has had a hysterectomy AND the date of the hysterectomy
is greater than the date of the uterine infection treatment (someone left
the claim in a drawer for six months) AND the date of the uterine
infection treatment precedes the effective date for policy's rider which
covers such treatments...
.... et and cetera. I think I'll stop now.
--end quoted text
All of this 'stuff' - the rules for the adding or updating of a single
transaction against a single account - is the result of a combination of
'complex logic' ('a policy issued to a man can cover someone who is not a
man under certain conditions') to legal fiat ('the Court just decided that
uterine infections in women 18 - 24 years old who live in (area) are the
responsibility of (trash-dumping company)') to an individual corporation's
policies and experiments... and if one expects an 'end user, using natural
language' to be aware of this then one might be disappointed.
Where does it come from, then... who relates and co-ordinates all of these
disparate factors into something that Does What The Company Wants?
(notice I say 'The Company' here, not the user... there are user requests
that are at odds with what benefits The Company... but that's another
topic for discussion, entire)
As I understand it, at present the person who takes these various
relatings and co-ordinatings and presents them in a fashion which uses The
Company's current data requirements (what data are available and what
machine resources can be used to manipulate these data) to quickly and
efficiently satisfy and end-user request is 'a programmer'. I wonder how
delighted or disappointed one may get should one expect the end-users to
assume these tasks... good system design will help, up to a point, so
perhaps there'll be less emphasis on programming and more on
architecture...
.... but there isn't yet, to my knowledge, an architecture that will
prevent Cartesian joins or flat scans due to a lack of key access or a
provide a mused 'Hmmmmm... you know, given our data structure and the
nature of this request... maybe *this* tool would work better.'
Yes, it might be that some day the architecture will look at usage
statitistics and say 'We need an alternate key here' or 'In this case a
SORT will be more appropriate than an EasyTrieve job' or 'What Department
A is calling an 'organisation code' Department B has stored as an
'internal accounting code''... and the likelihood of such architecture may
be more probable than, say, predictions about personal helicopters and
flying cars and one-piece cellophane jumpsuits, I do not know... after
all, some day there'll be computers small enough for you to carry around,
no?
DD
| |
| Pete Dashwood 2007-06-04, 6:55 pm |
|
"Michael Mattias" <mmattias@talsystems.com> wrote in message
news:CUT8i.5981$u56.336@newssvr22.news.prodigy.net...
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5ci7kcF30ujccU1@mid.individual.net...
>
> Programmers (as we understand the term then) may be using natural
> language and graphical front ends to create applications, but end users? I
> think not.
>
> It will be pretty much as it is today except the tools will be more
> powerful.
>
The history of tool use suggests otherwise, Michael.
The more powerful tools become, the more empowered the people who use them
become.
Comparing the situation in 20 years with the situation today, in terms of
tools and use, is like comparing our ape-like ancestors using a stick to dig
for grubs, with today's operator of a caterpillar bulldozer excavating the
foundations for a skyscraper. They both get fed and both have an effect on
the environment, but the one with the most powerful tool eats better and has
more impact, in a way that his earlier counterpart could never even begin to
imagine.
End users will become so empowered by software/hardware that they won't
hesitate to interact with it and discuss what they require. And before
everyone chimes in and says: "But users NEVER know what they want...", the
software will offer them "what if" and "would you like...?" scenarios, with
examples using live data.
It is also important to remember that this will be a new generation of
users, not like the past lot... :-).
We are already seeing "computer literacy" filtering into the workplace
(sometimes to the chagrin of computer professionals, who are not happy at
seeing their empire eroded by spreadsheets and personal databases,
especially when the people doing the eroding are end users, and they are
very capable. In one place I worked in England a few years ago, there were
3 times more computer science graduates in the Business than there were in
the whole IT department. (It was a major Power Company...))
In the same way that we now have a generation of youngsters who cannot
conceive of a world without TV and cell phones, taking these things for
granted the same way some of us took books and radio, the generation in 20
years will be technophiles who will think no more of interacting with a
computer to derive a business solution, than they would think of browsing
the web to select a restaurant for dinner.
Said it before, I say it again: "History will show that computer programming
was a phenomenon of the latter half of the 20 th century."
(OK, so there's some spillage into the early part of the 21st century, but,
as a percentage of the total years where computers needed programming, this
is trivial. We are seeing it's Goetterdammerung even as I write. Would you
seriously suggest that nothing has changed since you were a junior
programmer? For decades people have been trying to obviate computer
programming with generators and packages and better tools; now that
technology is starting to come to fruition. Take speech recognition... a
pipe dream for 30 years. (I remember in the late 1970s it taking the entire
resources of what was then one of the world's most powerful computers to
recognise around 900 words with 80% accuracy. Now my laptop can recognise
100,000 words with over 95% accuracy. There are curves in emerging
technology; some of them are S shaped. Computer programming may well be one
such. We are due for a paradigm shift.)
Time will tell.
Pete.
| |
| Howard Brazee 2007-06-04, 6:55 pm |
| This discussion of languages as tools reminds me of an article I just
read:
How is an AK-47 like a QWERTY keyboard?
http://www.salon.com/tech/htww/2007...k_47/index.html
Maybe CoBOL fit into that category as well, and Java is now fitting
in.
| |
| Pete Dashwood 2007-06-05, 3:55 am |
|
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:4lu8631nd7dbok22nghatbneb4k1q8qv2j@
4ax.com...
> On Tue, 5 Jun 2007 02:20:48 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> I have serious qualms about end users understanding the effects their
> actions have on the rest of the organization. Coding has always been
> a smaller part of the overall process. Finding out and understanding
> what has to be done always has been a larger part of the process.
> Testing has been given far too little importance in many
> organizations. Simple things like getting the definition of a sale or
> what constitutes a product can be time consuming and spur great
> inter-deartmental fights. The tools you envision can help in this
> area.
The important thing here is that this will not be a scenario where a single
user sits at a single wortkstation and interacts with it (although that will
happen too), rather, it will be networked with policy decisions discussed
and agreed then picked up by smart software and on file for use whenever
someone in the organization is doing something in that area of operations.
We are already seeing things moving in this direction. Video conferencing is
used for policy discussions across companies and continents. The minutes and
conclusions reached are manually entered into policy and procedure manuals
and distributed throughout the organization. All of this can be automated,
with meetings automatically recorded and videoed. I see a time when the
"virtual assistant" will be present at meetings and will ensure that the
decisions made are distrubted into policy and that action points are
followed up. The Network empowers this.
[color=darkred]
>
> Great. Computer scientists are not needed as much as business
> analysts who actually understand the business.
Yes. My point was that there is increasing computer literacy in the work
force. This has a major impact on the implementation of the solutions I have
been predicting here.
A good question is: Why do we need a Business Analyst? Is the business so
complex that it requires specialists to understand it? (It may well do so
but there are SMEs (Subject Matter Experts) who can fulfill this role.) No,
the BAs are needed so that IT can develop systems appropriately and ensure
that the data resource is used as effectively as possible. I foresee this
being done by smart software with possibly a couple of IT people as
"caretakers" of it.
It does mean a change in methodology; the current procedural practices would
not fit the model. Instead it is likely that Object modelling would be used,
with users and smart software devising Use Cases to make paper models of the
proposed systems. All of the "stamp collecting" with data utilization,
downstream feeds, and integration with existing systems (much easier in an
Object Oriented environment) can be carried out by networked smart software
tools. The users will simply decide what they want and formulate policy. The
software will implement it and optimize it.
>Given the curriculum
> of most Computer Science departments, it probably was even worse for
> the organization than having MBAs (Masters of Business
> Administration).
I'm not arguing the effectiveness of Computer Science courses in a Business
environment (...I try to pick battles that are winnable :-)); all I'm saying
is that there is dramatically increasing computer awareness and familiarity
in the work force, with people doing Computer Science who have no intention
of going into IT as a career, but who know that whatever they DO go into,
computer skills are going to be necessary.
> The problem is in knowing what needs to be done with
> what constraints.
Yes, there will be some dramatic shakeups in the way organizations are
managed as well. Future managers will use advanced software to help them
formulate policy (smart managers already do...) with the system providing
paper models and "what if" scenarios. Policy decisions are unlikely to be
taken in isolation (except maybe in the very smallest companies), management
will be networked just like everybody else and will have access to the same
tools and software as everybody else. The whole idea of hierarchical
management is an anachronism best left to the military and nostalgic control
freaks. Company policy will be decided by steering committees comprised of
personnel who have had years of experience on the shop floor or who have
specialist knowledge of the business (SMEs). IT need not be involved; (but
will be for some time to come...) Management will become more of an Admin
role except at the top level where, as currently, the Board have the final
say on overall policy.
The important thing here is that the technology will not affect the decision
making process or the policies and procedures implemented by the
organization, as is currently the case. Right now we have Business Analysts,
Programmers, DBAs and Operations all constraining what systems can be
implemented, and steering requirements around what they can make available.
In 20 years, I don't believe that will be the case. The organization will be
so empowered in terms of its IT that humans won't be needed (or able) to get
involved in the nitty gritty of how and where data is stored and accessed.
It will be taken as read that the data required to support a given process
will be available as and when needed, to the people who need it, in the form
they want it, instantly. All of the IT "infrastrucure" will be carried out
by smart software; tools will monitor each other and Audit Agents will
patrol the network ensuring that unauthorized access is prevented and
transactions that depart from the norm are diaried and raised for human
attention if they exceed agreed bounds.
Humans will argue with each other, rather than with the system; the system
will adapt itself to whatever they decide, and will ensure that full
disclosure is made to the decision making process.
The keys here are data on tap, and networking.
>After figuring that out some database theory could
> help. In regard to spreadsheets, there was an estimate by Gartner
> (which may not be worth that much given the source) that over 30% of
> the spreadsheets in an organization are wrong.
On this occasion I would agree with them; in fact, I think that is
conservative. But it depends on what you mean by "wrong". There is minor,
trivial, inaccuracy, right through the gamut to devastatingly misleading...
Fortunately, the more serious the degree of "wrongness" the quicker it is
picked up and either corrected or binned. To some extent, these errors are
self correcting.
[color=darkred]
>
> Now make sure that the solution meets all of the requirements of the
> Sarbanes Oxley Act (financial reporting), the appropriate privacy acts
> (you mean that you can't give every clerk access to the customer files
> with credit data?), data retention and destruction rules, etc. Oh and
> make sure that the processes are documented so the organization can
> prove it meets those requirements and also get ISO 9000 certification.
Don't you think computers can do all oif the above better than humans can?
They LOVE to have rules and documents; that's what they were born to do :-)
Tick IT, BS 5750, and ISO 9000 are all attempts to ensure some consistency
and auditability within an organization. The forms and processes they use
are ideally suited to computerization. (It is done under the blanket of QA
but anyone who has dealt with it knows it isn't about quality of product, it
is about quality of process and showing that the process was followed. (If
it is a crap process, it will still be followed and receive ISO 9000
signoff, provided the right boxes are ticked.) As you might gather, I've
been involved in some of this stuff and my assessment is it is like the
Curate's egg, "good in parts". It is certainly a ticket to the gravy train
for certified Auditors... :-)
> Yes and make the help prompts useful and have good tutorials. There
> are tools out there for this sort of thing but I doubt that they are
> yet powerful enough for your average business person to use them all
> and get the job done right.
Tutorials and help are necessary for technical environments because they are
currently complex. Even in this area, video tutorials that allow you to stop
the movie, back up, rerun, and learn at your own pace are revolutionizing
the whole struggle to keep up with technical innovation. I did 9 video
tutorials on VS 2005 and C# (say, 11 hours) and was then comfortable and
productive in it. Contrast this with a three w classrom course in COBOL
back in the 60s, 2 ws full on from books for Java, in the 90s, and a
trend becomes apparent.
Policies and Procedures for an organization can be provided in video
tutorial form and each user can have their own personal learning program.
If it works for complex things like computer programming, it can certainly
work for relatively straughtforward things like business processes.
Complexity in the process can be handled and re-organized by the system.
Interaction between system and users can ensure that "uncomfortable" areas
are reviewed and redesigned, even as the system continues to be used.
> Incidentally, the programmers of today
> (myself included) have done at best a mediocre job of verification,
> documentation and analysis in most cases. The skills for each of
> these tasks is different.
And the requirement for them is diminishing in importance, as far as the
tech level goes. Objects will (and even currently, do...) contain their own
documentation. If objects in the future are generated by the system, the
system can generate documentation into them. I was interested to see that it
is possible to make C# document itself (Java has always been able to do so).
If you are never going to maintain an object, the documentation you need for
it is different to what you WOULD need if you were taking it apart
regularly. It's a bit like the difference between a maintenance handbook for
your car and a workshop manual for it. They are both useful, but meet
different requirements.
>The tools will enable organizations to
> better focus on these tasks because the coding and construction will
> become easier and automated.
Absolutely. I believe that.
> The tools should also enable the
> organizations to address the other tasks in a more organized manner
> but there is a reason people pay big dollars to true security
> professionals, DBAs, data administrators, and other professionals.
Certainly true today, and likely for some time yet, but twenty years? (given
an ever increasing exponential rate of change). Most of these roles are
simply analysing and organizing, and computers, interacting with humans, can
become expert enough in these areas for them to be fully automated.
> I
> have no disagreement with your assessment that COBOL programming will
> be almost gone by 2015 and not used for new programming unless
> something changes drastically. However, designing any major system or
> verifying that a major enhancement won't have adverse effects is an
> interdisciplinary task.
Yes and no. Like I said above, the model of how we currently do things would
need to change (and my bet is that it will).[color=darkred]
>
> The programming will be done at more and more abstract levels. The
> tuning will be interesting as will the dealing with integrity issues.
Yes, agreed.
[color=darkred]
| |
| Pete Dashwood 2007-06-05, 3:55 am |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:hfi863hgfgoibfjeaa8rl8fdpi2fhfm9jk@
4ax.com...
> On Tue, 5 Jun 2007 03:51:02 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> So I say, as I pass the 44th floor...
>
>
> It may be doing so exponentially - I love reading Vernor Vinge.
>
Not familar with that name... I'll GOOGLE it later.
> But falling off the Empire State Building, has a similar increase in
> speed.
>
Except that it stops at terminal velocity. There is no indication that the
current expansion of human knowledge will do that; it may well be asymtotic.
> ================================
>
> I suspect I will not see the same kind of world changing events that
> my grandmother saw. She remembered the first time she saw a car, a
> phone, and a man walking on the moon. I don't think computers have
> changed society quite that much. The bigger change in my lifetime
> is the switch from conventional warfare to what we have today (is
> that change accelerating?), although it is possible that climate
> change will be bigger before I die.
I suspect you could be wrong about that (first sentence). It may just be
that the full impact of some of the things you have seen have not become
appparent yet.
Pete.
| |
| Pete Dashwood 2007-06-05, 3:55 am |
|
<docdwarf@panix.com> wrote in message news:f41j62$ap5$1@reader2.panix.com...
> In article <5ciqn8F2vbnhpU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> Mr Dashwood, I don't know how to convince you that I am neither negative
> nor positive... usually I report on what I have seen and dealt with and I
> don't make many predictions for what the morrow will bring, if I could do
> that well I'd make my living off the stockmarkets.
You don't need to persuade me, you certainly don't need my approval.
I also report what I see, and I have seen a distinct tendency to see the
darkness in your previous posts.
You say that is what you have experienced, I'm not arguing. Neither am I
suggesting we should ignore darkness in the interests of all being sunbeams.
But I don't think we should revel in it either. My impression is that you
actually enjoy a cynical and jaded view.
It isn't right or wrong; I value your posts for the most part, and certainly
always read what you write.
I do enjoy your style and totally respect your right to be whatever you want
:-)
>I really can't respond
> to your repeated assertions of 'Now it is different, Stuff has Changed,
> This Time for Sure!'... because I barely know yesterday and tomorrow is a
> mystery. Just a few bits, here and there.
"Can't respond", but are doing so... OK :-)
>
> [snip]
>
>
> Mr Dashwood, I do not know of examples of the 'intelligent agents and
> expert systems' which fill you with such hope... but I *do* know that just
> about every system I've ever worked on has had, at some level, an
> 'over-ride', a switch/flag/checkbox which says 'Yes, this is against your
> rules but I, a Human Being, am telling you to go ahead'.
>
> This is, I would say, Good, True and Right... the machines should do what
> Human Beings tell them to; one of the most chilling representations of
> what could happen were things otherwise is the interchange from Kubrick's
> '2001, A Space Odyssey':
As long as the humans are smarter than the machines. What happens if they're
not?
>
> 'Open the pod bay doors, HAL.'
> 'I'm sorry, Dave, I'm afraid I can't do that.'
That's not fair to HAL. He was the only entity who knew what the real
mission was about and the knowledge drove him "insane".
You can't judge AI on the basis of a single postulated insane instance.
(My favourite line in that film is where HAL says: "I know I've made some
very bad decisions lately." Unfortunately, I was the only person in the
cinema who laughed at this point, and the lady I was with was embarrassed
and we split up not long after... :-) (I blame Kubrick... :-)))
Besides, if that were for real there would be three HALs on board, just as
there are on every Boeing 747. One to fly the plane, one to monitor the one
that's flying the plane, and a third one as backup for either of the first
two, should they fail.
>
> So... just about every system I've worked on has this over-ride
> capability... and just about every system I've worked on has had this
> over-ride capability used in a manner for which it was not intended and
> which has caused Really Big Problems somewhere down the line.
>
> Let the Machine have the Last Word? No. Let Humans foul up processing
> because Humans can sometimes do that? No. The logical, and absurd,
> conclusion is... Don't Let Anyone or Anything Do Anything.
>
:-) Sometimes it can seem that way.
>
> [snip]
>
>
> [snip]
>
>
> Mr Dashwood, what I described was the simple stuff, the processing of an
> insurance claim... and insurance was one of the earliest 'industries' to
> adopt data-processing nigh a half-century back. Perhaps this history
> works to their divantage in that they are tied to doing it the old
> way... but it makes me wonder, then, what kind of organisations are 'the
> right companies and people'.
The "right company" would be one where they have vision and imagination and
see these attributes as part of their competitive edge. Not afraid to rock
the boat (within parameters that prevent it from capsizing) , and with an
elightened management team that values, listens to, and respects their
workforce.
The "right people" are happy to work for such a company, see the company
goals as part of their own aspirations, and are motivated by sharing the
rewards.
I know of one such company; hopefully there are others...
>
>
> Are you familiar with punch-line number 865 for the joke about A Thief Who
> Could Teach A Horse To Sing?
>
No.
[color=darkred]
>
> That is one view, Mr Dashwood... but since I'm full of jokes today,
> another view is found in the answer to 'What do you get when you pour two
> gallons of pure water into four hundred ninety-eight gallons of crap?'
>
You get a starting step towards diluting the crap. You may never remove it
entirely, but you can make it so dilute it no longer dominates the mix.
>
> Mr Dashwood, with all due respect... I do not know of five organisations
> where these criteria are met so I am not able to confirm this assertion by
> my experience.
We are talking about 20 years on.
>
> [snip - and I interrupt myself]
>
>
> Those familiar with the history of the United States might be familiar
> with a promise made about six decades back of 'A chicken in every pot and
> a car in every garage!'
>
They're also probably familiar with how totally irrelevant that promise was
to today's world, where we do in fact have a chicken in every pot and a car
in every garage (unless you don't lke cars and are allergic to chicken, or
have decided that the chicken will place itself in your pot and the car will
drive itself into your garage.)
>
> I understand.
>
>
> If this is the case, Mr Dashwood, then the difference is not to be
> compared to 'gas lighting'... it might be compared to 'lighting fixtures'
> in their entirety. The structures used to organise data, at present, are
> a part of determining how best to access them just as the location of
> electric (or gas) outlets are a part of determining how a room is to be
> lit.
>
> What you posit is not so much a shift from gas- to other-powered lighting
> fixtures but a shift from lighting fixtures to lighting implementations, a
> sort of 'How are you going to design this workspace given the fact of
> fluorescent wall panels?'
>
> It is an interesting exercise, yes... but when it comes down to designing
> workspaces one deals, at present, with lighting fixtures.
>
What part of "in 20 years" have you failed to grasp?
> [snip]
>
>
> Not 'dreams', Mr Dashwood... humdrum, every-day workplaces, where people
> go to do their jobs. That they 'will not exist' in the future is, at the
> moment, as verifiable an assertion as 'they will too'.
So you don't think people accessing data should have dreams and aspirations?
Or system designers should not want to aspire to a dream system? A
workplace is humdrum and everyday when you consider it so. Those of us who
actually enjoy our work, don't mind getting up to go to work and derive
pleasure and satisfaction from doing so, can work in the most appalling
conditions and still not see it as humdrum. (I've worked in artificially lit
subterranean offices where, in the winter, you never saw the light of day,
I've worked in prefabricated shacks that were freeezing in winter and
boiling in summer, and I've worked in beautiful, architect inspired,
air-conditioned buildings with views that take your breath away. Had the
time of my life in all of them. There is TV ad here about recruitment: "Find
a job you love, and never work again." Worth thinking about.
>
>
> Mr Dashwood, 'relevance' may depend, once again, on one's experience; when
> sequencing (or the lack thereof) causes an operator to wait more than
> three seconds after whacking Return for a patient's data to come up then
> the Director of Nursing may, at the next inter-departmental meeting, have
> a few choice words for the CIO about how people in the Emergency Room have
> to wait for those screens to come up...
I honestly don't know whether you are just being obtuse or actually have no
imagination whatsoever.
Either way, I see no point in pursuing this.
So I won't... :-)
Pete
<remainder snipped>
| |
|
| In article <5cjt4mF2an1vtU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
[snip]
>I honestly don't know whether you are just being obtuse or actually have no
>imagination whatsoever.
What's Life without a bit of Mystery, eh?
>
>Either way, I see no point in pursuing this.
A pity... some of the points you raised might have had some responses of
value, not necessarily immediately... but, perhaps, in twenty years.
>
>So I won't... :-)
It was fun while it lasted, Mr Dashwood.
DD
| |
| Michael Russell 2007-06-05, 9:55 pm |
| Top post:
Top post, Doc.
Michael
docdwarf@panix.com wrote:
> In article <5ci7kcF30ujccU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>
> Mr Dashwood, this prediction's been around, in one form or another, for a
> few decades now... I recall it being made when users began to get access
> to QMF. Please pardon me if my reaction is not as... positive and
> encouraging as yours.
>
> What you describe may work well with reporting functions - 'tell me what I
> want about whom I want' - as long as the Prod system doesn't get tied up
> with too many Cartesian joins. Insofar as modifying data in Prod... I've
> seen enough systems designed by 'The Professionals' which allow for
> incorrect/inappropriate update that I'd be a bit... wary about allowing
> each and every 'end user... us(ing) natural language' to, say, change
> personnel and claim records.
>
> Not everything is the equivalent of a cash-register or library-book
> inventory system... and even *those* 'simple' mechanisms get thrown
> out-of-balance by people familiar with their use. I recall posting
> something about this before... ahhhhhh, there it is,
> <http://groups.google.com/group/comp...78?dmode=source>
>
> (moderately lengthy quotation follows)
>
> --begin quoted text:
>
>
> Let me sing this back to see if I'm learning the song.
>
> 1) Initiate customer update request.
> A) Does the initiating user have any customer update authority?
> i) No - send 'not you, buddy' notice and terminate transaction
> ii) Yes - CONTINUE.
>
> 2) Prepare to and accept user input to identify customer for update.
>
> 3) Validate input
> A) is input in valid format (all letters/numbers in the right places)?
> i) No - send 'bad format' message and GO TO 2)
> ii) Yes - see if customer exists in system
> a) No - send 'not here - re-enter or use A)dd function'
> and GO TO 2)
> b) Yes - does user have auth to update this class of customer?
> 1) No - send 'lowly peon' msg and GO TO 2
> 2) Yes - CONTINUE
>
> 4) Prepare to and accept user input to modify identified customer.
>
> 5) Validate input
> A) is input in valid format (codes entered are valid update types)?
> i) No - send bad code(s) msg and GO TO 4)
> ii) Yes - are codes valid for this kind of customer?
> a) No - send 'not for this one, you don't' msg and GO TO 4)
> b) Yes - send 'are you sure?' msg and get response
> 1) is response valid?
> A) No - send 'Y/N, please?' msg and GO TO 5.A.ii.b
> ... etc.
>
> Now... the question of 'the extraction of business rules' and 'the
> extraction of logic rules' is where it gets sticky. Take the example of
> an insurance-claims system. It seems logical and businesslike to allow
> for a claim to be made for the treatment of uterine infections... BUT NOT
> if the policy's group doesn't have a rider to cover such treatments...
>
> ... then it's OK... BUT NOT IF the claimant is a male...
>
> ... BUT IF the claimant is a male who has a female relative who is also
> covered by the policy then it's OK...
>
> ... BUT NOT IF the claimant is a male who has a female relative who is
> also covered who has had a hysterectomy...
>
> ... BUT IF the claimant is a male who has a female relative who is also
> covered who has had a hysterectomy AND the date of the hysterectomy is
> greater than the date of the uterine infection treatment (someone left the
> claim in a drawer for six months) then it's OK...
>
> ... BUT NOT IF the claimant is a male who has a female relative who is
> also covered who has had a hysterectomy AND the date of the hysterectomy
> is greater than the date of the uterine infection treatment (someone left
> the claim in a drawer for six months) AND the date of the uterine
> infection treatment precedes the effective date for policy's rider which
> covers such treatments...
>
> ... et and cetera. I think I'll stop now.
>
> --end quoted text
>
> All of this 'stuff' - the rules for the adding or updating of a single
> transaction against a single account - is the result of a combination of
> 'complex logic' ('a policy issued to a man can cover someone who is not a
> man under certain conditions') to legal fiat ('the Court just decided that
> uterine infections in women 18 - 24 years old who live in (area) are the
> responsibility of (trash-dumping company)') to an individual corporation's
> policies and experiments... and if one expects an 'end user, using natural
> language' to be aware of this then one might be disappointed.
>
> Where does it come from, then... who relates and co-ordinates all of these
> disparate factors into something that Does What The Company Wants?
> (notice I say 'The Company' here, not the user... there are user requests
> that are at odds with what benefits The Company... but that's another
> topic for discussion, entire)
>
> As I understand it, at present the person who takes these various
> relatings and co-ordinatings and presents them in a fashion which uses The
> Company's current data requirements (what data are available and what
> machine resources can be used to manipulate these data) to quickly and
> efficiently satisfy and end-user request is 'a programmer'. I wonder how
> delighted or disappointed one may get should one expect the end-users to
> assume these tasks... good system design will help, up to a point, so
> perhaps there'll be less emphasis on programming and more on
> architecture...
>
> ... but there isn't yet, to my knowledge, an architecture that will
> prevent Cartesian joins or flat scans due to a lack of key access or a
> provide a mused 'Hmmmmm... you know, given our data structure and the
> nature of this request... maybe *this* tool would work better.'
>
> Yes, it might be that some day the architecture will look at usage
> statitistics and say 'We need an alternate key here' or 'In this case a
> SORT will be more appropriate than an EasyTrieve job' or 'What Department
> A is calling an 'organisation code' Department B has stored as an
> 'internal accounting code''... and the likelihood of such architecture may
> be more probable than, say, predictions about personal helicopters and
> flying cars and one-piece cellophane jumpsuits, I do not know... after
> all, some day there'll be computers small enough for you to carry around,
> no?
>
> DD
>
| |
|
| Howard Brazee wrote:
> This discussion of languages as tools reminds me of an article I just
> read:
>
> How is an AK-47 like a QWERTY keyboard?
>
> http://www.salon.com/tech/htww/2007...k_47/index.html
>
> Maybe CoBOL fit into that category as well, and Java is now fitting
> in.
Very interesting article. :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com/linux/blog ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
|
| Pete Dashwood wrote:
> <docdwarf@panix.com> wrote in message news:f41j62$ap5$1@reader2.panix.com...
>
> They're also probably familiar with how totally irrelevant that promise was
> to today's world, where we do in fact have a chicken in every pot and a car
> in every garage (unless you don't lke cars and are allergic to chicken, or
> have decided that the chicken will place itself in your pot and the car will
> drive itself into your garage.)
I'm gonna swipe that... :)
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Albuquerque, NM! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com/linux/blog ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
"Who is more irrational? A man who believes in a God he doesn't see, or
a man who's offended by a God he doesn't believe in?" - Brad Stine
| |
| tlmfru 2007-06-06, 3:55 am |
|
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
news:5ci7kcF30ujccU1@mid.individual.net...
>
> Within 20 years there won't be programmers (as we understand the term) in
> organizations anyway. End users will use natural language and graphical
> front ends to do whatever they want done and code will be generated by
> software. It will be encapsulated and reused automatically. Maintenance of
> source code is unnecessary, expensive, and error prone.
>
A lot of you fellows will remember that in the beginning there was a clear
distinction between software and applications. Software was what came with
the computer - the OS, the compilers, the utilities: and usually it was all
written by the manufacturer. Applications were the programs & systems we
wrote using the software that came with the computer. For a long time now,
the two concepts have both referred to by the term software. That's a
pity, because I think that the distinction is still useful.
PD may be right that programmers as we know them won't exist in 20 years;
one could argue that anybody who uses any sort of commands - in natural
language or not - is programming in some sense, but it's a feeble argument.
Whatever. Somebody will still have to write the "software" that does all
the functions that the un-programmers will use to get their work done. I
doubt that the day will ever come that all possible user functions have been
written; I also doubt that all users will agree that they aren't unique and
can use whatever's already been written. So PD may be right in that
"applications" may no longer be written in 20 years, but "software"
certainly will be.
PL
| |
| Pete Dashwood 2007-06-06, 7:55 am |
|
"LX-i" <lxi0007@netscape.net> wrote in message
news:YqqdndbRjbfKkvvbnZ2dnUVZ_qjinZ2d@co
mcast.com...
> Pete Dashwood wrote:
>
> I'm gonna swipe that... :)
I'm flattered :-) Please, be my guest...
Pete.
| |
| Pete Dashwood 2007-06-06, 9:55 pm |
|
"tlmfru" <lacey@mts.net> wrote in message
news:03s9i.10406$6z4.8288@newsfe19.lga...
>
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote in message
> news:5ci7kcF30ujccU1@mid.individual.net...
>
> A lot of you fellows will remember that in the beginning there was a clear
> distinction between software and applications. Software was what came
> with
> the computer - the OS, the compilers, the utilities: and usually it was
> all
> written by the manufacturer. Applications were the programs & systems we
> wrote using the software that came with the computer. For a long time
> now,
> the two concepts have both referred to by the term software. That's a
> pity, because I think that the distinction is still useful.
>
> PD may be right that programmers as we know them won't exist in 20 years;
> one could argue that anybody who uses any sort of commands - in natural
> language or not - is programming in some sense, but it's a feeble
> argument.
> Whatever. Somebody will still have to write the "software" that does all
> the functions that the un-programmers will use to get their work done. I
> doubt that the day will ever come that all possible user functions have
> been
> written; I also doubt that all users will agree that they aren't unique
> and
> can use whatever's already been written. So PD may be right in that
> "applications" may no longer be written in 20 years, but "software"
> certainly will be.
>
> PL
>
I think you are right about the distinction between "applications" and
"software". It is a useful distinction. I tend to say "applications" rather
than "software" if I am referring to application software.
I believe the boundaries became blurred when applications started being
developed which appeared to be extensions of the OS. If an OS is comprised
of object classes (as, for example, Windows is...), and applications are
also deveoped by combining object classes and even using the ones that are
part of the OS, then the whole lot becomes like an extended Operating
System... "software"...
>"Somebody will still have to write the "software" that does all
> the functions that the un-programmers will use to get their work done. "
Not necessarily. I believe that in 20 years user functions will be generated
by smart software interacting with users. You may be thinking that someone
will need to write that smart software. Again, I believe it will "evolve"
from where we are today. We are already starting to see expert software that
encapsulates knowledge acquired over decades (monitoring, routing,
diagnosing, and fixing networks is just one example where software can do
the job more acccurately and faster than a human expert, pre-diagnosis of
medical conditions is getting
accurate enough to be credible, my dentist can cut a perfect crown in 10
minutes with a computer that works from a video image of the tooth... it
used to take days, with a specialist making the crown from an impression,
and sometimes the crown didn't actually fit...).
My point is that we are already experiencing software that is smarter and
more expert than humans in the same field. I have had experience with
heuristic programs that modify themselves millions of times a minute and
require specialist programs to monitor them and debug them. They can achieve
a result and it is not realistically possible to know how they arrived at it
(It could take a year for a human to debug the audit trail from the
monitoring system, even with assistance from yet another specialist program
:-)). The time is rapidly approaching when we will have to simply trust
software. (Actually you are doing this every time you board an aircraft or
enter an elevator, but most of us prefer not to think about that...)
"I doubt that the day will ever come that all possible user functions have
been
> written; I also doubt that all users will agree that they aren't unique
> and
> can use whatever's already been written."
That is certainly true at the moment. However, in 20 years, organizations
will be concerned with functionality rather than technicality. (The
"technical infrastructure" will all be hidden and the user interface will be
everything.). Certainly most companies believe they are unique, and even if
they are not, they want some degree of difference so they can believe they
have a competitive edge :-). This is where the ability to generate processes
and procedures at will, without needing technical skill, to have the ability
to try different scenarios "on the fly" and to focus on the business and
business functionality, rather than being constrained by Database
Administration, or programming backlog, or insufficient operational
capacity, will make all the difference. Users won't care about what has or
hasn't been written or whether it is in use by someone else; all they will
care about is getting what they want, and smart software running on
intelligent networks will deliver it to them
As a clincher, there will be huge advances in technology (some of which are
already in existence in University labs), and we can expect storage to
continue getting larger, faster, and cheaper for some time to come. The
network model will slowly establish itself as the model of choice and we
will see an explosion in bandwith and intelligent networks.
Interconnectedness, interoperability, and data sharing will be the
catchwords that will take us in this direction.
(C# and DotNET are primarily driven by the need for interoperability. I have
been stunned by how cleverly this is achieved. Watching a Unix machine
access my C# code which in turn wraps COBOL code running on a Windows
server, across global distances, is something we could only have dreamed of
15 years ago.)
If you look at everything in the light of how we do things right now, then
it is very hard to see how what I am proposing can come about.
(The trouble with exponential curves (like the current rate of change) is
that when you're at any given point on them, they look linear. The rate of
change is increasing, even more than Alvin Toffler recognised when he took 4
years to write "Future Shock" back in the 70s.))
I believe there will be sea changes in the way systems are developed over
the next 10 years or so and it is this evolution which will finally lead to
software being smart enough to organise itself. The Windows OS (which is
Neanderthal in terms of what I am discussing) has already taken a quantum
leap in implementation of the User interface...compare Vista with Win 3.1
and then win 95 with XP and even XP with Vista... every few years a better
(and smarter) user interface. And, under the covers, better organisation of
the object classes, huge libraries of functionality (DotNET has around
80,000 classes and Vista is designed to be the desktop user interface to
it), all completely transparent to the user. Vista is capable of selecting
alternate functions depending on available resources. This is a step
towards self organising... (Think about the creature in "2001 - A Space
Odyssey" throwing the bone to the sky...)
Object classes were the first step. Then encapsulated components, then
functional programming (Lambdas) for data retrieval. Combine all of this
with multiprocessor broad bandwith networks and you have the keys to the
kingdom. But it needs a sea change in approach and attitude. It is necessary
to look beyond the SDLC that is still in place in so many places.
Investigate, analyse, specify, code, debug, and implement, all as separate
and phased steps to a solution is just archaic, in the light of the new
technology and the empowerment that comes with it..
Having tried both approaches over a number of years, I am firmly persuaded
that systems should be "evolved", not "designed".
I know that sounds heretical, but, before anyone gets apoplexic, I should
say that it doesn't mean you shouldn't think carefully about what you want.
Object modelling, Use Cases, a paper model, are all very useful for getting
functionality and data flows defined. Object workshops let the entities and
components of the processess be recognised before any code is cut. The
emphasis should be on the functionality; an object approach allows the
elements which will support the functionality to be recognised and defined.
Once you have the atoms, you can easily build the molecules, and then the
proteins, then the stem cells until you have an organism... sorry,
system...:-)
(No matter how carefully you design, it will still have to be changed, so
why not use a model that thrives on change?
Imagine, instead of saying to a user: "Sorry, you signed that off and it
can't be changed now...maybe in release 2...", you could say: "You want it
changed? Sure, no problem. Which changes would you rather have? If you want
all of them, it will take longer." And finally (in 20 years)... "OK, here's
the latest smart development package. Just interact with it and you'll get
whatever you want. If you don't like it or need to change it, tell Igor,
the smart interface agent... he'll see you right." (He also speaks any one
of 128 different natural languages, and communicates with other agents all
over the world to get what you need, instantly...)
Interact, build, evaluate, iterate is a mch better model, whether you RAD it
or not (and, personally, I do...)
" So PD may be right in that
> "applications" may no longer be written in 20 years, but "software"
> certainly will be.
Well, Peter, I dispute your use of "certainly". It is by no means certain. I
would see "software houses" employing the same techniques used by commerce
in general (Interacting with smart software to make even smarter software,
until eventually (probably around 2050) the software can write itself).
After all, system software is just a specialised kind of Application...
Notice I have left AI completely out of the picture. If advances in that are
factored in, then it is even less certain that humans will still be writing
software.
Nevertheless, you could be right.
Time will tell.
Pete.
| |
| Howard Brazee 2007-06-06, 9:55 pm |
| On Tue, 5 Jun 2007 12:11:12 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
[color=darkred]
>I suspect you could be wrong about that (first sentence).
So you suspect that I could possibly not suspect that I will...?
| |
| Howard Brazee 2007-06-06, 9:55 pm |
| On Tue, 5 Jun 2007 13:38:28 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>
>As long as the humans are smarter than the machines. What happens if they're
>not?
Intelligence is over-rated. There's plenty of evidence that
extremely smart people make some dangerous or otherwise wrong
decisions and choices.
Of course, in fiction, the author can make whatever choice he wants
"right", leading to such things as _Jurassic Park_ "proving" that
technology is too dangerous to have. In _2001, A Space Odyssey_,
Bowman was acting for his own survival, possibly at the expense of the
mission, and of the survival of the Earth. Maybe HAL wasn't crazy
nor wrong - but only the loser who didn't get to write the history.
| |
| Howard Brazee 2007-06-06, 9:55 pm |
| On Mon, 4 Jun 2007 23:31:16 +0000 (UTC), docdwarf@panix.com () wrote:
>
>Anyhow, the professor once asked the class 'Given these data and this kind
>of volume... what kind of sort would you write for this?'... and the
>fellow I knew responded 'I'd never write a sort... I'd *buy* one.'
My education in various types of sorts was fun, but if CoBOL had had
internal table sorts in the compilers I have used, I probably would
never had used this education.
| |
|
| In article <hkvd635d9b896e5bkqo3qqsvks292leedp@4ax.com>,
Howard Brazee <howard@brazee.net> wrote:
>On Mon, 4 Jun 2007 23:31:16 +0000 (UTC), docdwarf@panix.com () wrote:
>
>
>My education in various types of sorts was fun, but if CoBOL had had
>internal table sorts in the compilers I have used, I probably would
>never had used this education.
There are things which one learns that are used, Mr Brazee, and things
which one learns which might have no use; it may be that the learning,
it'sself, is the most useful of them all.
DD
| |
| Pete Dashwood 2007-06-06, 9:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:utud63tm3s7fbl9mkrsg142vb7u08rdhq9@
4ax.com...
> On Tue, 5 Jun 2007 12:11:12 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
>
> So you suspect that I could possibly not suspect that I will...?
Touche :-)
Of course I can't possibly suspect anything about what you may or may not
suspect :-) I was referring to the proposition that you may not see "the
same kind of world changing events that my grandmother saw".
But you knew that :-)
Pete.
| |
| Pete Dashwood 2007-06-06, 9:55 pm |
|
"Howard Brazee" <howard@brazee.net> wrote in message
news:14vd639spjcqubabc873b5bfvncvbukr8t@
4ax.com...
> On Tue, 5 Jun 2007 13:38:28 +1200, "Pete Dashwood"
> <dashwood@removethis.enternet.co.nz> wrote:
>
>
> Intelligence is over-rated. There's plenty of evidence that
> extremely smart people make some dangerous or otherwise wrong
> decisions and choices.
Absolutely. I've sometimes wondered in retrospect how someone as smart as me
could make some of the dumb choices I've made in my life...:-) I think most
of us are smarter in retrospect... :-)
>
> Of course, in fiction, the author can make whatever choice he wants
> "right", leading to such things as _Jurassic Park_ "proving" that
> technology is too dangerous to have. In _2001, A Space Odyssey_,
> Bowman was acting for his own survival, possibly at the expense of the
> mission, and of the survival of the Earth. Maybe HAL wasn't crazy
> nor wrong - but only the loser who didn't get to write the history.
I'm gradually getting through Kurzweil's book ("The Singularity is near")
which Charlie recommended.
He sees a time (around 2045) when human and machine intelligence will merge
to create a completely new way of looking at things. It isn't as crazy as it
sounds. The human brain has certain superiority over computers (at the
moment) but the computers cream us in other areas. If the best of both these
worlds were combined, the results could be startling. It would start out as
computer assisted human intelligence but it would end up as something
completely different. He is in general agreement with some of my own ideas
on this (and I agree with many of his).
For computer programmers, who are used to being in control, this is pretty
hard to swallow, but we are already starting to trust software in our
everyday lives (and that is software that was written by humans; imagine
when we have software that isn't written by humans...) and extrapolating
this trend brings us inexorably to a point where the software will be
smarter than we are.
Intelligence and an opposable thumb have given Mankind domination of the
planet. These same two attributes may enable us to create something that
will supersede us. It will still be human, but not as we are. There is
precedent in the evolution of our current species.
I guess as long as Homo Nova retains all the things that make us decent, we
should welcome it.
It's pretty likely we will pollute ourselves into extinction before it
arrives, anyway :-)
Pete.
| |
| Alistair 2007-06-07, 6:55 pm |
| On 4 Jun, 15:20, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> "Michael Mattias" <mmatt...@talsystems.com> wrote in message
>
> news:CUT8i.5981$u56.336@newssvr22.news.prodigy.net...
>
>
>
>
>
>
>
> The history of tool use suggests otherwise, Michael.
>
> The more powerful tools become, the more empowered the people who use them
> become.
>
I don't wish to stoke the fires too much but history teaches us many
things and one of those is that those who do not learn the lessons of
history are doomed to repeat it endlessly and those who learn the
lessons of history are doomed to repeat it (not endlessly).
History teaches us that a tool will be used both properly and
improperly regardless of the perceived power of the tool.
History teaches us that slow or inappropriate responses to development
requests will drive users into the arms of tool manufacturers allowing
the user to byepass the IT department (so it is inevitable that users
will use tools).
History teaches us that even intelligent users (and that includes IT
wallahs) are capable of making mistakes in choosing an inappropriate
tool or using an appropriate tool improperly or incorrectly.
History also teaches us that even proper and correct use of a tool can
result in an incorrect result.
In history it has been said about both Cobol and SQL that these were
the languages that would do away with the need for programmers as an
intelligent user could write their own programs. I have had
intelligent users who were capable of writing programs in both Cobol
and SQL but that did not always result in their producing the correct
figures on their reports (they usually blamed the data and not their
code).
I think that more powerful tools will facilitate the rapid development
of solutions which are more likely to be correct but that, even with
natural language (try SuperNatural from SAG) the likelihood is that
programmers will still be a necessary evil as users will not, unaided,
be capable of producing workable viable efficient solutions.
Perhaps as proof I should offer the case of a charity where I do
voluntary work as an example. They have a working CRM (admittedly bug-
ridden, awkward to use and prone to losing just-entered data) but
decided to write their own CRM using that powerful tool, MS Access.
When I got involved the development had 7 tables which were a very
rudimentary skeleton detailing the type of data that they had and very
simplistic relationships. Bearing in mind that the finance director
had no prior knowledge of database development or of using MS Access
it can be said that she had done a credible job in getting that far.
However, the data had repeating groups and some cells needed to
reference other rows within the same table. No analysis had been done
to determine what the reporting requirements were so when I had the
temerity to ask the Big Pointy Haired Boss what she wanted as reports,
the result was a complete restructuring of the data structures and
relationships (we had to say NO to the idea of adding budget data into
the system to keep the system to a workable level). 7 tables is now 19
tables. There are link-tables galore. I get dizzy looking at the
relatioship diagram (I do suffer from vertigo) and I have a reasonable
level of understanding of databases and relationships. I have no doubt
but that the original user-developer would have had no chance of
developing the current structure and that is with what I consider to
be a powerful tool.
History teaches us that the more powerful the tool, the greater the
opportunity for the tool user to get their knickers (or y-fronts) in a
twist. I can not envisage an era when programmers will not be needed
unless you believe that Andromeda-style computation will become a
reality. I suspect that the vagaries of natural language will defeat
the developers of natural language tools. We touched on an issue in
this newsgroup: how do you define the colour red to a blind man (or
restricted artificially intelligent computer).
| |
| Alistair 2007-06-07, 6:55 pm |
| On 4 Jun, 15:20, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> For decades people have been trying to obviate computer
> programming with generators and packages and better tools; now that
> technology is starting to come to fruition. Take speech recognition... a
> pipe dream for 30 years. (I remember in the late 1970s it taking the entire
> resources of what was then one of the world's most powerful computers to
> recognise around 900 words with 80% accuracy. Now my laptop can recognise
> 100,000 words with over 95% accuracy.
And what about when you have a cold or a sore throat or a head-ache or
have just come back from the dentist?
| |
| Alistair 2007-06-07, 6:55 pm |
| On 4 Jun, 18:58, Howard Brazee <how...@brazee.net> wrote:
> On Mon, 04 Jun 2007 14:27:07 -0300, Clark F Morris
>
> <cfmpub...@ns.sympatico.ca> wrote:
>
> Is that because they don't approve of such a commercial language?
>
> Or is that because they are commercial entities that want to attract
> paying customers with different demands?
I was taught Fortran by a Computer Science Professor who did not
program (he was heavily into the Law and Computers). I suspect that
Comp Sci schools didn't teach Cobol because to do so would have
required that they pay serious money for a compiler and serious
hardware and that they would have had to learn an unglamourous
language for which they had no use. Better to use a language where the
same command in different variants of the language using the same
switch settings produces completely different results.
| |
| Alistair 2007-06-07, 6:55 pm |
| On 4 Jun, 22:35, Clark F Morris <cfmpub...@ns.sympatico.ca> wrote:
> On Tue, 5 Jun 2007 02:20:48 +1200, "Pete Dashwood"
>
>
>
>
>
> <dashw...@removethis.enternet.co.nz> wrote:
>
>
>
>
>
>
>
>
>
> I have serious qualms about end users understanding the effects their
> actions have on the rest of the organization. Coding has always been
> a smaller part of the overall process. Finding out and understanding
> what has to be done always has been a larger part of the process.
> Testing has been given far too little importance in many
> organizations. Simple things like getting the definition of a sale or
> what constitutes a product can be time consuming and spur great
> inter-deartmental fights. The tools you envision can help in this
> area.
>
>
>
>
>
> Great. Computer scientists are not needed as much as business
> analysts who actually understand the business. Given the curriculum
> of most Computer Science departments, it probably was even worse for
> the organization than having MBAs (Masters of Business
> Administration). The problem is in knowing what needs to be done with
> what constraints. After figuring that out some database theory could
> help. In regard to spreadsheets, there was an estimate by Gartner
> (which may not be worth that much given the source) that over 30% of
> the spreadsheets in an organization are wrong.
>
>From Louise Pryor's web site:
<QUOTE>
A few years ago Professor Ray Panko, at the University of Hawaii,
pulled together the available evidence from field audits of
spreadsheets. These are the results he shows:
Study Number of
spreadsheets Number with
errors Percentage
with errors
Coopers & Lybrand, 1997 23 21 91%
KPMG, 1997 22 20 91%
Lukasic, 1998 2 2 100%
Butler (HMCE), 2000 7 6 86%
Total 54 49 91%
More recently Lawrence and Lee analysed 30 project financing
spreadsheets. All 30 had errors; the error rate was 100%.
</QUOTE>
Of course, my spreadsheets are all 100% error free :-)
| |
| Alistair 2007-06-07, 6:55 pm |
| On 5 Jun, 01:06, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
>
> The important thing here is that this will not be a scenario where a single
> user sits at a single wortkstation and interacts with it (although that will
> happen too), rather, it will be networked with policy decisions discussed
> and agreed then picked up by smart software and on file for use whenever
> someone in the organization is doing something in that area of operations.
>
> We are already seeing things moving in this direction. Video conferencing is
> used for policy discussions across companies and continents. The minutes and
> conclusions reached are manually entered into policy and procedure manuals
> and distributed throughout the organization. All of this can be automated,
> with meetings automatically recorded and videoed. I see a time when the
> "virtual assistant" will be present at meetings and will ensure that the
> decisions made are distrubted into policy and that action points are
> followed up. The Network empowers this.
Presumably, the virtual assistant will use the install-time default US
English dictionary supplied by M$ which can not be over-ridden buy the
European English dictionary until service pack two has been installed?
I suspect that the virtual assistant will have serious difficulties
defining the correct shade of red (I would always want Burgundy not
that dreadful Cadmuim Red) to be used and probably determining when a
meeting has actually raised an action point (and to whom it is to be
assigned).
>
At last! Intelligent users?
[color=darkred]
>
A friend (you know of him already from other posts) was not worried
about the users using spreadsheets but was more worried about the fact
that they deleted columns, relocated columns, inserted columns, used
the incorrect data format for the data being used and generally had
the power to mess up the feeds to his mainframe system. He was quite
happy that they had the ability to query spreadsheets but would have
prefered the structures of the spreadsheets to be in tablets of stone.
[color=darkred]
>
> Yes. My point was that there is increasing computer literacy in the work
> force. This has a major impact on the implementation of the solutions I have
> been predicting here.
Increased computer literacy is not a bad thing. It works both ways.
They can understand why you can not do it now (although their use of
Basic has taught them that everything is a one line five minute
change) and they can understand how to better use a computer system to
improve the business.
>
> In 20 years, I don't believe that will be the case. The organization will be
> so empowered in terms of its IT that humans won't be needed (or able) to get
> involved in the nitty gritty of how and where data is stored and accessed.
I like this idea. Networked databases (aren't they already here?).
What if I switch the server off when I go home (to save power)?
> It will be taken as read that the data required to support a given process
> will be available as and when needed, to the people who need it, in the form
> they want it, instantly.
IBM must be rubbing there hands in glee at the thought of selling all
that Big Iron.
All of the IT "infrastrucure" will be carried out
> by smart software; tools will monitor each other and Audit Agents will
> patrol the network ensuring that unauthorized access is prevented and
> transactions that depart from the norm are diaried and raised for human
> attention if they exceed agreed bounds.
And who will configure/program those audit agents? I suppose they
could be allowed to monitor the system for a month and that would
define normality. But what about year end?
| |
| Alistair 2007-06-07, 6:55 pm |
| On 5 Jun, 02:38, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> That's not fair to HAL. He was the only entity who knew what the real
> mission was about and the knowledge drove him "insane".
>
> You can't judge AI on the basis of a single postulated insane instance.
>
> (My favourite line in that film is where HAL says: "I know I've made some
> very bad decisions lately." Unfortunately, I was the only person in the
> cinema who laughed at this point, and the lady I was with was embarrassed
Try being the only person in the cinema who laughed at the moment when
Sid Vicious sticks the knife into Nancy Spungen in the film 'Sid and
Nancy'.
| |
| Alistair 2007-06-07, 6:55 pm |
|
> Whatever. Somebody will still have to write the "software" that does all
> the functions that the un-programmers will use to get their work done.
I can envisage, in 20 years or so * ;-) *, software that writes
itself. We already have computer programming languages that were
written iteratively (the programmers wrote the original source and
that was then used by the programmers to write the final product) eg
User Files Online.
An interesting concept in PL's original is the advent of the un-
programmer. Presumably a one time hack who has unlearned everything
they once knew about programming (probably refered to as a bag-lady in
colloquial terms by the more-socially useful call centre operatives).
| |
| Howard Brazee 2007-06-07, 6:55 pm |
| On Tue, 5 Jun 2007 12:11:12 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>Not familar with that name... I'll GOOGLE it later.
He is former San Diego State professor and a SF writer who has won
Hugos. His ex-wife won one for fantasy and has the same last name.
Actually, she won her Hugo in 1982 in Denver, and I came across his
works first when she read his "True Names" in a reading at the
WorldCon (they were already divorced). That novelette had people
"programming" by living in virtual worlds and doing what appears to be
magic. Time hasn't hurt that story at all. I think you would find
that interesting.
Outside of the SF community, he is probably best known for his concept
that we have a singularity coming, where human life changes beyond
recognition due to technology.
His _Rainbows End_ (a character wonders if the lack of an apostrophe
is intentional) is quite likely to win another Hugo for him - it's a
near future novel, approaching his singularity. It is interesting to
see how they teach in schools where everybody "wears". People pause
in conversations to quickly look things up in the net. Amusement
parks have people walking through virtual worlds without bumping into
each other. And students are graded in how creative they are in
getting useful results from the world database. One character is
probably an AI. Governments are in constant battles against the
increasingly powerful cyber terrorists, Not to mention a YGBM (You
Gotta Believe Me) technology being developed by a more organized foe.
I'd check out http://en.wikipedia.org/wiki/Vernor_Vinge .
| |
| Howard Brazee 2007-06-07, 6:55 pm |
| On Thu, 7 Jun 2007 13:19:43 +1200, "Pete Dashwood"
<dashwood@removethis.enternet.co.nz> wrote:
>I'm gradually getting through Kurzweil's book ("The Singularity is near")
>which Charlie recommended.
Googling Kurzweil, Vinge, & singularity got me:
http://en.wikipedia.org/wiki/Technological_singularity
| |
| Alistair 2007-06-07, 6:55 pm |
| On 6 Jun, 17:40, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
>
> Not necessarily. I believe that in 20 years user functions will be generated
> by smart software interacting with users.
Genetic Programming? I'm not sure of the correct term but programs can
be developed as rudimentary sources, mutated, measured for fit against
the desired result, selected and iteratively developed to the point
where they can meet the requirements. This has already been done for
programs and logic circuits with surprising results (unexpected
solutions or tighter code than would be expected).
Also, knowledge based systems being taught, as by London Transport, to
recognise when a platform is full, or not.
> :-)). The time is rapidly approaching when we will have to simply trust
> software. (Actually you are doing this every time you board an aircraft or
> enter an elevator,
I don't trust the software but I do trust the fail-safe brake.
> Having tried both approaches over a number of years, I am firmly persuaded
> that systems should be "evolved", not "designed".
Just how not-designed is the evolved solution. You could start with
GUI screens and add functionality to the system (isn't that part of
RAD?) but you must start with some understanding of the requirements
and each iterative step in the evolved solution must encompass some
level of design. Otherwise you are likely to end up with un boit de
verre, as the Germans say.
I suspect that all systems now are Evolved systems in that they all go
through an iterative series of requirements-design-code-test-change-
retest stages before meeting the final solution.
>
> (No matter how carefully you design, it will still have to be changed, so
> why not use a model that thrives on change?
Because you test-change-retest-rechange ..... and it all costs money
which users don't want to part with. One of the reasons for the
standard model (quarks and leptons excluded) is that it is cheaper to
think carefully about what you want to achieve before you put coding
pencil to code-sheet.
>
> Imagine, instead of saying to a user: "Sorry, you signed that off and it
> can't be changed now...maybe in release 2...", you could say: "You want it
> changed? Sure, no problem. Which changes would you rather have? If you want
> all of them, it will take longer."
Actually, what we say is'You want a change? OK, what? I can not
guarantee to meet the original project plan with the original
resource, to budget and schedule if you increase the work load by 50%
at this stage.' User wonders off to Pointy Haired Boss (male in the
example of which I am recalling) and says (I paraphrase) 'Maclean is
being a wet blanket and wants to stop the project.' Pointy Haired Boss
tells me 'When the user says JUMP our only comment should be "How
high?"' What they meaned was: work overtime, neglect your family and
forget that you once had a life. Do it and do it now. By the way, you
won't be getting a pay rise this year.
And finally (in 20 years)... "OK, here's
> the latest smart development package. Just interact with it and you'll get
> whatever you want. If you don't like it or need to change it, tell Igor,
You really should start reading Terry Pratchett's Discworld novels.
Coz, you wouldn't have chosen Igor as the smart agent's name.
> the smart interface agent... he'll see you right." (He also speaks any one
> of 128 different natural languages, and communicates with other agents all
> over the world to get what you need, instantly...)
Does he/she (Igors can be of either sex and, like dwarves, the sexes
are indistinguishable to outsiders) pop up at the most awkward moment
and ask if you are writing a letter because it looks like a letter and
he/she has a proforma for that?.
>
| |
| Alistair 2007-06-07, 6:55 pm |
| On 7 Jun, 02:02, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
wrote:
> Of course I can't possibly suspect anything about what you may or may not
> suspect :-) I was referring to the proposition that you may not see "the
> same kind of world changing events that my grandmother saw".
>
Philosophically speaking, as one does, He could not see the SAME kind
of world changing events that his grandmother saw but he might see
SIMILARLY world changing events in his life time.
| |
| Pete Dashwood 2007-06-07, 6:55 pm |
|
"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:1181221883.025986.32140@p77g2000hsh.googlegroups.com...
> On 4 Jun, 15:20, "Pete Dashwood" <dashw...@removethis.enternet.co.nz>
> wrote:
>
> I don't wish to stoke the fires too much but history teaches us many
> things and one of those is that those who do not learn the lessons of
> history are doomed to repeat it endlessly and those who learn the
> lessons of history are doomed to repeat it (not endlessly).
>
> History teaches us that a tool will be used both properly and
> improperly regardless of the perceived power of the tool.
>
> History teaches us that slow or inappropriate responses to development
> requests will drive users into the arms of tool manufacturers allowing
> the user to byepass the IT department (so it is inevitable that users
> will use tools).
>
> History teaches us that even intelligent users (and that includes IT
> wallahs) are capable of making mistakes in choosing an inappropriate
> tool or using an appropriate tool improperly or incorrectly.
>
> History also teaches us that even proper and correct use of a tool can
> result in an incorrect result.
>
> In history it has been said about both Cobol and SQL that these were
> the languages that would do away with the need for programmers as an
> intelligent user could write their own programs. I have had
> intelligent users who were capable of writing programs in both Cobol
> and SQL but that did not always result in their producing the correct
> figures on their reports (they usually blamed the data and not their
> code).
>
> I think that more powerful tools will facilitate the rapid development
> of solutions which are more likely to be correct but that, even with
> natural language (try SuperNatural from SAG) the likelihood is that
> programmers will still be a necessary evil as users will not, unaided,
> be capable of producing workable viable efficient solutions.
>
> Perhaps as proof I should offer the case of a charity where I do
> voluntary work as an example. They have a working CRM (admittedly bug-
> ridden, awkward to use and prone to losing just-entered data) but
> decided to write their own CRM using that powerful tool, MS Access.
> When I got involved the development had 7 tables which were a very
> rudimentary skeleton detailing the type of data that they had and very
> simplistic relationships. Bearing in mind that the finance director
> had no prior knowledge of database development or of using MS Access
> it can be said that she had done a credible job in getting that far.
> However, the data had repeating groups and some cells needed to
> reference other rows within the same table. No analysis had been done
> to determine what the reporting requirements were so when I had the
> temerity to ask the Big Pointy Haired Boss what she wanted as reports,
> the result was a complete restructuring of the data structures and
> relationships (we had to say NO to the idea of adding budget data into
> the system to keep the system to a workable level). 7 tables is now 19
> tables. There are link-tables galore. I get dizzy looking at the
> relatioship diagram (I do suffer from vertigo) and I have a reasonable
> level of understanding of databases and relationships. I have no doubt
> but that the original user-developer would have had no chance of
> developing the current structure and that is with what I consider to
> be a powerful tool.
>
> History teaches us that the more powerful the tool, the greater the
> opportunity for the tool user to get their knickers (or y-fronts) in a
> twist. I can not envisage an era when programmers will not be needed
> unless you believe that Andromeda-style computation will become a
> reality. I suspect that the vagaries of natural language will defeat
> the developers of natural language tools. We touched on an issue in
> this newsgroup: how do you define the colour red to a blind man (or
> restricted artificially intelligent computer).
>
"Give us the job and we will finish the tools..." (Apologies to W. S.
Churchill...)
So, based on a single instance of an untrained user, working with something
he had no idea how to use, you are not surprised that he makes a mess...
Neither am I. Where I disagree is in your statement that ACCESS is a
powerful tool. The power of tools is all relative. A hammer is much more
powerful than a rock, but a hydraulic drill is much more powerful than a
hammer.
ACCESS is arguably a useful tool, but the tools of the future will make it
look like a rock...
I have tools that will build RDBs in 3rd normal form from COBOL ISAM
definitions. (And, having done that, will generate load modules to read your
existing data and populate the new databases. All pretty much cutting edge
when I wrote them in the early 90s...) Much more powerful than doing it
yourself, but they are nothing compared to what is coming.
Your inability to envisage a time when programmers will not be needed may
have much more to do with flaws or deficiencies in your observation of what
is already under way, and ability to extrapolate based on that, than it has
to do with such an event being impossible.
I have already given examples here of areas where human expertise is being
replaced by software. Apply the current rate of change and growth to that
and it isn't such a huge leap to realise that software will eventually
"write" itself. (It won't write itself in the way we write software today;
perhaps "create" or "organize" are better words. The end result is that
software will produce new and better versions of itself, and humans won't
necessarily know how it did it. (Neither will we care. We will simply use it
to do what we want done.)
Huge amounts of money are going into automation of software error
correction (debugging, today) and AI. At the same tiime the human brain
itself is being "reverse engineered" and significant progress with that
engineering is being made. Combine all of these factors together, plus a
good number of others which have not been discussed here, and smart software
is not just science fiction.
One thing you can be absolutely certain of: The future (in terms of computer
technology) will be very different from the present.
Could you have foreseen the coming of the Internet and the effect it would
have, in, say, the 1940s? Even in the 60s when ARPANET existed, the people
who used it, for the most part, would not have been able to conceive of its
descendents carrying the sum total of human knowledge with a billion users
every day, and flashing live video around the world.
| | |