The Maturing of a Software Project Manager

                        Kouichi Kishida

  Nearly 20 years ago, Professor Manny Lehman gave a seminar in Tokyo. His
topic was the evolution dynamics of large-scale software systems. Someone
asked Dr. Lehman from the floor, "What is your definition of a large-scale
system?"  "I consider it 'large,'" he answered, "if it is developed and/or
maintained by a team with more than one level of management hierarchy."

  Hmm, I thought, largeness related to hierarchy.  And I put that idea away
in my mind.

  At the 10th International Conference on Software Engineering (Singapore,
1988), Dewayne Perry and Gail Kaiser presented a paper entitled "Models of
Software Development Environment". They classified Software Development
Environments into four sociological categories: Individual, Family, City,
and State.

  Here again were the combined concepts of hierarchy and largeness.  It
reminded me of one of the Confucian classics, called  "Great Learning":

     "Those who wish to conquer the world would first bring order to
     their states. Those who wish to bring order to their states would
     first regulate their families. Those who wish to regulate their
     families would first cultivate their personal lives by rectifying
     their minds...."

We might almost be listening to a Watts Humphrey lecture about the Personal
Software Process.

                        *       *       *

  In the Spring of 1990, I visited the Eureka Software Factory in Berlin,
where I chanced to come across a report written by Professor Trygve Reenskaug,
a description of his own version of an object oriented method. In passing,
this Norwegian professor indicated that, in his mind, a 19th century German 
philosopher named Max Weber was the true "father" of O-O methods. Weber's
concept of the "ideal" bureaucracy has key characteristics in common with
O-O:
	(1) emphasis on form,
	(2) concept of hierarchy,
	(3) specialization of task,
	(4) specified sphere of competence, and
	(5) established norm of conduct.

  This left my thoughts spinning; I made a mental time trip back in time
two thousand years.  One of the Confucian philosophers Hsun-tzu (BC
298-238) was then writing a considered essay on rectification of names.
He described therein a systematic hierarchy of concepts and their names (in
OO terminology, relationship between meta-class, class, instance, etc.).
Confucius himself speculated about this issue a little differently:

  "If names are not rectified, then language will not be in accord with
truth. If language is not in accord with truth, then things cannot be
accomplished.  If things cannot be accomplished, then rites and music will
not flourish.  If rites and music do not flourish, then the punishment will
not be just.  If punishment is not just, then the people will not know how
to move hand or foot. Therefore, the superior man will give only names that
can be described in speech, and say only what can be carried out in
practice."

  What might this have to do with software project management?  Well, apply
the thought using this  simple conversion table:

            Names      <----->  Concepts
            Language   <----->  Process Model
            Things     <----->  Projects
            Rites      <----->  Methods
            Music      <----->  Tools/Environment
            Punishment <----->  Management
            People     <----->  Software Developers
            Hand/Foot  <----->  Development Activities

                        *       *       *

  Certainly there are levels of concerns about team efforts in software
development, and large-scale projects do begin to look like cities, as
Perry and Kaiser indicated. But, what kind of cities are they?

  In the tradition of our agricultural civilization, a city exists mainly
for management. Typical examples are the walled city-states in ancient
China and Europe. They all have concentric urban planning around the royal
palace, reflecting a hierarchical structure of management.

  Such cities look beautiful, but are easy to corrupt from within. Sure
enough, there is much historical evidences of political corruption of
Confucian city-style (or bureaucratic) management. Further, these
hierarchical social structures tend to lack creative power of their own.
Innovations are brought from outside, typically by some wandering philosopher
like Confucius himself.

  Cities in today's industrial society (a successor to agricultural society
and now being transformed into an information society), have functions
above and beyond management. Walls surrounding them have almost disappeared
(we can only find a few remaining immigration barriers, similar to
firewalls on the Internet). Modern cities are essentially "free" places for
exchanging information, trading materials, and mixing cultures.

  Historically speaking, we can trace the origins of such  "free" cities to
the 7th and 8th century Arab world.  Commercial civilization was the mother
of the new cities and the reason that the global empire of Jinghis Khan was
able, a few centuries later, to interconnect them with an "internet" of
highways.

I believe such a "free" city is the appropriate symbolic image of a
large-scale software project.  Software project exist to produce some
software system. But the project does not exist only for the sake
of management of production. there are other inportant products other than
software products. Large-scale oftware project is also a place for cultural
exchange for a variety of people coming and going. Through this process,
people grow up and new concepts or technologies are evolving out.

                        *       *       *

  In 1981, I was assigned as the director of a national strategic
initiative called SMEF (Software maintenance Engineering Facility),
the first project in Japan to construct a unix-based Software Development
Environment.

  Formal goal of the project was to produce a set of useful tools to support
application software maintenance. It was a good excuse to get research funds
from the government. But, real goal should be different. 
So I undertook this project as an effort "to build a Unix amusement
park for the software industry."

  We had a productive prototyping experience and a useful series of
working group discussions. Our approache was proved to be very effective
to promote technology transfer of state-of-art
concept of integrated software development environments into practice.
Most of member companies of SMEF started to construct their own in-house
UNix-based environment utilyzing knowledge they get through the project.

  Then another national strategic initiative called SIGMA (I can't remember
what does it stand for: "Software Industrialization something"!?) was started.
Originally it was conceptualized as a succesor of SMEF to perform 
experimental R&D about the architecture of future distributed software
environment using workstaions, PCs, and networks.

  At first I was a member of planning group but soon given my walking papers
because MITI (the sponsoring organization) did not feel comfortable
spending budget for the construction of a "park" of any kind. They stuck
rather to  beautiful old-fashioned software-factory style Confucian management
just to produce easy-to-use products into market . . . and failed beautifully.