NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/software/5478

Text File | 1993-01-28 | 10.4 KB | 191 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!charon.amdahl.com!netcomsv!netcom.com!mcgregor
From: [e-mail] (Scott L. McGregor)
Subject: Re: Why is the Software Process NOT working
Message-ID: <[e-mail]>
Organization: Prescient Software, Inc.
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 28 Jan 1993 02:03:25 GMT
Lines: 180


There are some really good points made here. In order to be a bit more
succinct, I have decided not to quote each individual that I am
responding to, but rather respond in general.

Several sources for problems in SWE have been identified, cheif among
these are 1) Universities, and 2) Management.  I'd like to make some
comments about each.

First, Universities. Joshua Levy and others have eloquently cataloged
the failures of universities in these areas. But can we expect changes
in these areas? While many students believe that universities exist to
train them to be better in their chosen field, I think that this can
sometimes be confusing goals with realities.  In many (most?) cases,
universities exist to perpetuate themselves and to provide rewarding
employment to those who operate them: administrators and tenured
faculty. The way to achieve this goal may be to teach students a
trade, however this may not be strictly necessary, especially if
students enroll anyway when the organization is not successfully
preparing them for a trade. Ironically, I find relatively few students
pay much attention to the university's placement department when they
apply, they tend to focus on other things including academic
reputation and campus life.  It is extremely rare that a university
applicant will contact a potential post graduation employer and ask
what they think of the suitability of educations offered by various
universities for success in that organization.  Before we put all the
blame entirely on the universities we ought to consider what the
consumers who support them (students) are requiring of them.

Since universities (not unlike most organizations including
corporations) exist to sustain the employees (admin & sr. faculty) we
should not be surprised that given a student body accepting of
whatever is taught that many university professors prefer to teach
programs that will prepare others to become professors, and not
particularly SWEs in industry.  Furthermore, to the degree that
universities desire to prepare their students for an industrial career
at all, they are rarely interested in dealing with short term needs
(which they see as more of a "trade school" and less of an "academic"
approach). They are more likely to be interested in teaching you
things that they think will be important to you throughout your
career, or at least mid way through your career when you have achieved
sufficient power to excercise your own perogatives. If a career is
about 40 years, half way would be 20 years.  That's just the mark I am
at now.

As I review back, I see that particular languages that I learned
(Basic, FORTRAN, COBOL, BAL) haven't been that important to me in
recent years. Even other languages (LISP, Pascal, Ada, Smalltalk) that
became popular to teach 10-15 years ago have peaked in importance. C
has been more important to me more recently, and C++ and objective-C
may come to surpass it in another 5-10 years.  So languages taught
didn't have the desired durability. Similarly, OS's have had their day
in the sun and passed into quiessence too. OS-360, RTE, RSTS, TOPS-20,
VMS, MPE aren't nearly as important today to top grads as Unix, Mach, MS-DOS
and Macintosh OS. NT, NeXTstep, etc. could become the rage too.
Similarly with databases, etc.

On the other hand, basic principles of parsing (from compiler
classes), data organization (databases), communication and
synchronization (OS classes) do remain largely the same, even if the
exemplar systems change. In that respect, professors can credit
themselves for successfully teaching something of lasting value.
Unfortunately though very little of these principles turn out to be of
much importance outside that specific market segment.  By and large,
the number of compiler writers, database authors, and OS builders is
small relative to the number of people doing applications work in
other areas. The number of compiler users, database users and OS users
is large, and it is these skills, not the ability to produce your own
compiler, database or OS that is usually important to success on most
applications products.  The fact that students are taught how to
build these from scratch, but not how to find or re-use tools that
others have created can miss-set expectations and build the wrong
skill-sets. That's ironic.

What skills are keys to success for most programmers? The ability to
understand the application area you are producing for is probably far
more important than anything else I.e. Doing the Right Thing is more
important than Doing Things the Right Way. If you focus on the latter
before you have a grasp on the former, you are most likely to go broke
sooner!)  But these are the LEAST coding oriented skills. These are
skills of organizational analysis, interviewing and even knowledge of
models and terminology of the application discipline. (Joshua's
Physics classes may have done relatively little to help him prepare
for writing a configuration management tool, but would have proved
invaluable if he had been writing scientific analysis programs for
various physical phenomena).

But this shows why CS and SWE is wrong for preparing for a career
writing applications programs.  Programming is but a tool for solutions in
those areas.  If we wind up empowering financial analysts so that they
can solve problems in Lotus 1-2-3 without having someone in MIS
program a report in COBOL that's a plus.   A career in sales may be
critically dependent upon communication, and telephones, airplanes,
rental cars, slide and flip charts may all be valuable tools to help
sales people accomplish their goals.  But would a curriculum that
focusses on teach telephone operator skills, piloting, driving and
graphics design be right for preparing sales staff?  Or is a grounding
in the discipline you are selling into more important (e.g.
electronics for sales engineers who sell electronics equipment, or
mechanical engineering for people who sell tool and die systems)

SECOND, MANAGEMENT.  It is clearly the case that the senior manager
ARE people who grew up with Assembler, before CM tools were common,
before Software Metrics was in vogue, etc.  But would we be better off
if we just dispensed with them and put the new college grads in
charge?  I wonder if the senior management brings something to the
table that new hires might also be missing.  For instance, the
experienced manager might have a bit better understanding of customer
needs than the green engineer, because that senior manager may have
had many opportunites to talk with customers in the past, and to learn
from previous products successes and failures. Now it is possible to
have those opportunities and still not learn anything from them. But
they are valuable learning opportunties for those who do have the
ability to learn from experience.  Secondly, those experienced managers
might have a better understanding of the amount of overhead, turnover,
change in requirements, etc. that occur in that company--and with such
information they could perhaps predict time and effort better than
someone with no past experience in that organization to draw on.
(Whether they choose to use that information to make better estimates
or keep that to themselves may reflect other experience that they have
gained about success in that organization).

Again, doing the right thing tends to be more important than doing
things right, so experience about your customer base can be more
important than knowing the latest SWE techniques.  However, a good
manager and a good organization will find ways to not reduce
everyone's success to the senior manager's limitations, but to augment
his own expertise with the expertise and capabilities of others.
Sometimes engineers are more knowledgeable about these things than
their managers--in such cases it is a better strategy to take
responsibility for influencing management than to just note that it is
really management's responsibility and grouse.  Engineers can have
influence if they apply it (labor unions know that products aren't
produced if workers don't build them--engineers often loose sight of
this and discount their own power and influence as a result).

However, it is also worth remembering that applications development is
a commercially competative field and darwinism is at play.  If
organizations creek with too much stultified management and baggage of
the past, they can be passed by new organizations that lack the
experience but also the baggage. Twenty years ago, the major computer
companies were mainframe companies: IBM, the BUNCH and later Amdahl.
Younger companies like DEC (managed by Ken Olson, who just retired)
and HP (managed by John Young, who just retired) threatened to succeed
to IBM's detriment in the new market. Later, workstation companies
like Apollo (which HP bought), Sun, SGI and NeXT threatened to roll
past the Minicomputer vendors. PC players like Apple, Compaq, Dell
rose up.   In short, we should remember that the only way to make
progress is not necessarily to retrofit elephants born in the past
but can also come from the fast growing start-ups who pass them by.
Take a look at where IBM, DEC and HP are today.

IN CONCLUSION:

If  SWE is to make a difference to the productivity of the industries
we develop applications for, if we who read and write in this forum
are to make a difference, we cannot be satisfied with placing blame,
whether we do so on universities, or on managers.  Rather, we must
take action, we must identify not only sources of problems, but how we
can change things either by indirect influence or by direct action. We
must take personal responsibility for fixing what universities and
management have not--even though it is not our fault that these things
are wrong.  If we fail to do so, darwinian competition by those who do
attend to things things will remove us from the game.

Scott McGregor

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

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.