NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/software/4217

Text File | 1992-11-10 | 4.2 KB | 88 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!think.com!ames!decwrl!csus.edu!netcom.com!mcgregor
From: [e-mail] (Scott Mcgregor)
Subject: Re: Software Factory (was: Re: Do Software Engineers Actualy Do So Badly?)
Message-ID: <[e-mail]>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 10 Nov 1992 19:39:14 GMT
Lines: 77

In article <[e-mail]> [e-mail] (Ralph Johnson) writes:
>[e-mail] (Cameron Laird) writes:
>
>>Successful software organizations of the year
>>2000, in my estimation, will not be those that
>>regard applications problems as solved by "coding
>>up a program"--the tradition in which most of us
>>grew up--or even by design, in its lower-level
>>senses.  They will, as one contributor recently
>>complained, have a "de-skilling" attitude.  They
>>will expect their employees to show facility at
>>combining standard components, at translating
>>high-level specifications into solutions, and at
>>carrying out their business within a *measured*
>>workplace.
>
>"De-skilling" implies that companies will try to do the job
>with ignorant people.  That is a bad conotation, even though
>I know that it is true in some cases.  The right way to
>explain the situation is that companies want to solve
>business problems, not programming problems, and they don't
>want to spend most of their energy on software problems.
>So, they will buy prepackaged solutions to software problems,
>and will combine them to solve their business problems.

I agree.  One person's de-skilling is another person's career
enhancement. We talk about the de-skilling of the automotive industry,
but it didn't really happen that way. Before Taylor and Ford, autos
were custom built by small teams of master mechanics, a few journeymen
mechanics and a few apprentices. But most of the potential workforce
didn't have these skills, they were primarily rural agricultural
workers. Taylor's methods and Ford's factories allowed these
agricultural workers to get factory jobs. For those people these were
NEW skills. (Master mechanics didn't necessarily get shunted into dead
in work. Often they became the process and factory designers,
engineers, or  rework specialists.

Similarly, people writing Lotus 1-2-3 spreadsheets and using macros
are often not programmers, but "end users".  In the '70's MIS
departments were full of programmers who wrote special report programs
for such people.  Now the people do it themselves, and don't need the
same MIS contract programming.  And MIS programming staffs HAVE
shrunk. Some MIS programmers left to commercial or technical software
development organizations.  Some grew into management.  Some joined a
user organization. Very few were "de-skilled" but it is true that
comparatively less programming is going on in MIS, and that MIS needs
people who can select, and support off-the-shelf solutions instead of
writing their own.  This is a different group of people with different
skills, and different pay rates.

From a programmers point of view, the advent of off the shelf
solutions "programmed" by end users is inefficient and de-skilling
compared to custom solutions by skilled programmers.  But from the end
user's point of view it is more direct control over their own success
criteria, less communication overhead, and a raise in their skills.

These are the people who will embrace OOP, without knowing that it is
OOP. They'll probably experience it as dragging and dropping icons
into some kind of simulated process layout -- an information assembly
line. They won't know they are programming. But they will accomplish
alone what used to require a C++ programmer. And they'll regard that
as a productivity boost.  Programmers will complain about the
inefficiencies of such methods, and the inelegancies created by under
trained end users--but the solutions will have the advantage that they
work well enough for the people who created them and use them.


--

Scott L. McGregor        [e-mail]
President            tel: [phone]
Prescient Software, Inc.    fax: [phone]
3494 Yuba Avenue
San Jose, CA 95117-2967