From: Robert McArthur
Reply: mcarthur@morakot.nectec.or.th
Date: Wed, 21 Dec 1994 07:32:13 +0700 (GMT+0700)
Subj: OW tutorial
____________________________________________________________

Jeff, I saw yr posting on comp...talk about the tutorial for ObjectWorld.
Thought yr comments about project breakdown etc. were *exceedingly* on
target... would 'preciate seeing anything you've got that you feel like
letting out ahead of time.

By way of a personal intro, I've been involved on and off for the last 8
yrs in building training and adv-design courses for comm'l OO packages.
Am currently leading a ST project building a subscription DB for int'l
publishers -- an interesting war story as it is one of those apps that
have (literally) eaten up millions of $$$ with nothing useful coming out
at the end, whereas we're up and running after 3 m-yrs starting from *no*
direct ST experience.

Thanks in advance...

Group: comp.lang.smalltalk
From: jsutherland Jeff Sutherland, Winchester, MA
Org: Galahad
Date: Thu, 26 Jan 1995 18:39:40
Subj: Re: OO Project Management
____________________________________________________________

>I am researching modeling techniques for object-oriented development
>projects and was wondering what experiences people have had in using
conventional
>project management tools (e.g., Primavera Project, Microsoft Project,...)
>in modeling OO projects. In particular, how does one depict iteration and
>reuse within these project models? How successful have such models been in
real
>project planning?

I have used Microsoft Project on numerous OO projects over the years. It
does the job barely, and with a lot of overhead, because it is the wrong
metaphor.

For a good overview of Smalltalk project management, one of the best papers
to read is:

Pittman, Matthew (1993) Lessons Learned in Managing Object-Oriented
Development. IEEE Software, Jan 1993, pp. 43-53.

Usability studies, however, have convinced us that only one paper in the
literature describes the rapid application development environment achieved
with Object Studio (the combination of Enfin Smalltalk and Synchronicity
Business Object Modeling and Persistent Object Mapping). Read this next:

Takeuchi, Hirotaka and Nonaka, Ikujiro. The New Product Development Game.
Harvard Business Review, Jan/Feb 1986, pp. 137-146.

Takeuchi and Nonaka describe the SCRUM methodology (a Rugby term) which we
use internally. It is significantly different than anything you have seen
because there is no project management schedule, only a committed delivery
time for a release. The Japanese auto and electronic companies are using
it to clean our clocks in the global economy. Did you notice that U.S.
auto companies had a banner year and still lost market share in 1994?

Small teams are given objectives to meet in a fixed time frame. They take
the existing software (you never build anything from scratch) and small
projects (2 days to 2 weeks per person) are assigned as SynchSteps.
SynchSteps are dynamic pulses generated against the existing code structure
that causes mutations (as in a biologic organism).

A project team is typically 3 developers, 3 QA people, 3 doc people, and
one or two users. They meet daily and all agree on steps completed and
next steps. For large projects, small teams of this size build components
and a SCRUM of SCRUMs meets less frequently to work out interfaces between
components. Developers must be outnumbered on the team by QA and
documentation people or they generate too much code too fast (malignant
functionality).

The code evolves like a biological system via punctuated equilibrium. You
can read about this process as modeled by Denny Hillis on a Connection
Machine in the book "Artificial Life." When enough mutations occur in
multiple parts of the organism, the system shifts to a higher plateau of
functionality. We say at this time that a "package" is emitted. This will
be a new piece of the software system we are building. For example, we are
adding Use Cases to the Synchronicity product at this time and when the
package appears, an objective for the release cycle is met.

A release cycle, typically six months, is built of packages which are
loosely defined as objectives at the start of the release cycle.

Management must release control of the team and let it function as a
self-organizing entity that grows a system like a plant. We have found
that we get dramatically more functionality in less time and a much cooler
product with this approach. This approach rationalizes the comments that
Fred Brooks made in 1987 in his paper "There is No Silver Bullet". There,
he stated that the only way to speed up development was to grow a prototype
like a plant.

We track the process by the velocity of SynchStep assignments versus the
velocity of SynchStep completion. This gives an estimate of package time
completion, kind of like launching a rocket, watching its trajectory, and
predicting impact point. We can adjust the impact point by lowing the arc
(less functionality) or adding rocket fuel (more resources) to hit the time
frame committed to management.

We monitor progress regularly via demonstrations. Nothing counts with
management except delivered code that works. Packages are regularly
shipped out as alpha components that people can drop into the current
release of Synchronicity. Synchronicity dynamically changes, menus and
all, so that people can try out the new functionality and see if they like
it.

With SCRUM schedules are obsolete (developers love it) and delivery dates
never slip (management loves it). If this sounds too good to be true, I
suppose it is, but management will agree there is more functionality and
less slippage with this process than anything they have ever seen. Our
users are asking us to lengthen the product delivery schedule because we
are delivering too many new releases with major upgrades too fast. (This
still doesn't stop them from complaining about not getting everything on
their wish list.)

We find that the paridigm shift required for optimum utilization of the
SCRUM process is significant. The object-oriented paridigm requires a
shift in thinking, but SCRUM requires a shift in the organization and the
way people work and relate to one another.

Send a note to info@ easel.com if you have trouble locating these papers.
Also, since I need to write a White Paper on this process, I am willing to
do it dynamically as a thread in response to comments by the newsgroup, if
there is sufficient interest.

Jeff Sutherland
jsutherland@easel.com (via Galahad BIX blinker)

From: Marc Davidson
Org: State of Oklahoma
Reply: marcus@ionet.net
Date: Sat, 28 Jan 1995 19:37:51 -0600 (CST)
Subj: Re: OO Project Management
____________________________________________________________

>With SCRUM schedules are obsolete (developers love it) and delivery dates
>never slip (management loves it). If this sounds too good to be true, I
>suppose it is, but management will agree there is more functionality and
>less slippage with this process than anything they have ever seen. Our
>users are asking us to lengthen the product delivery schedule because we
>are delivering too many new releases with major upgrades too fast. (This
>still doesn't stop them from complaining about not getting everything on
>their wish list.)
>
>We find that the paridigm shift required for optimum utilization of the
>SCRUM process is significant. The object-oriented paridigm requires a
>shift in thinking, but SCRUM requires a shift in the organization and the
>way people work and relate to one another.
>
>Send a note to info@ easel.com if you have trouble locating these papers.
>Also, since I need to write a White Paper on this process, I am willing to
>do it dynamically as a thread in response to comments by the newsgroup, if
>there is sufficient interest.
>
>Jeff Sutherland
>jsutherland@easel.com (via Galahad BIX blinker)

You sound like a person I would like to share several pots of coffee with.
Your views on OO program managment are facinating. I would be very
interested in reading your white paper when you finish it.

On another subject, I belive I read in an article posted by you that you are
useing Visual SmallTalk? If this is correct and if I may impose on you, I
would like the, vendors name, address, phone, so on and so forth...

I have been aware of SmallTalk for quite some time now but have never had a
chance to investigate the language. Visual SmallTalk and several others
I've seen are new to me. I am a programmer with the state of Oklahoma and
our shop is in the process of a total change in direction. From a main
frame environment to a client/server environment. So far the for runner for
application development is PowerSofts PowerBuilder and MS Windows. I have
been developing in C on the OS/2 platform for a couple of years and see the
move to PowerBuilder & the Windows only platform, as a step backwards (no
flame on Windows intended. smirk). I am encouraged by all the products
available for SmallTalk and the fact that it supports both Windows and OS/2.

Any information you could offer to help me show management that SmallTalk is
a more productive environment for application development would be greatly
appreciated.

First I get managment to buy into SmallTalk, then comes OO managment, next
nirvana! Or at least I may be able to catch up.

Thanks
Marc Davidson

Group: comp.lang.smalltalk
From: goochb@swim5.eng.sematech.org William D. Gooch
Org: SEMATECH, Austin
Date: Wed, 1 Feb 1995 13:52:39 -0600
Subj: Re: OO Project Management
____________________________________________________________

On Thu, 26 Jan 1995 ron@rschultz.pdial.interpath.net wrote:

> I am researching modeling techniques for object-oriented development projects
> and was wondering what experiences people have had in using conventional
> project management tools (e.g., Primavera Project, Microsoft Project,...) in
> modeling OO projects. In particular, how does one depict iteration and reuse
> within these project models? How successful have such models been in real
> project planning?

I have been using MS Project for OO projects for a couple of years
with pretty good success. I don't agree with those who say that a
conventional tool like MS Project isn't well-suited to OO projects.
Time and resource management are the same whether you're doing OO
or not. I do agree that MS Project and tools like it are not ideal,
but that's true regardless of what type of software you're developing.

The main problems are (1) there is no planning component in Project,
everything is a schedule with dates and durations, (2) schedules are
necessarily based on guesswork about what will happen during projects,
(3) software projects are typically ventures into the unknown to some
degree (more or less depending on the specifics), which means that
schedule estimates are likely to be wrong, and (4) management often
doesn't really understand (2) or (3), so they expect schedules to be
met. And this doesn't even consider the changes and extraneous problems
that get thrown at us in the midst of projects.

The trick for handling iteration is simple: decide how many cycles make
sense for the specific project you are planning, and put in that many
copies of the appropriate task(s). I generally find that each project
involves different demands, and the number of iterative cycles varies
according to those demands. It doesn't make much sense, for example, to
plan for five iterations of prototyping when you only have three months
to get the final result completed and delivered. Longer term projects
involve more variables in this context, but I think that it's generally
good to plan for a specific number of iterative cycles so that everyone
knows what to expect. Anything less specific can too easily lead to
conflicts.

Reuse is a very different issue, but also not that hard to plan around.
If you're reusing existing software, you'd better either understand
clearly what it is and what it can do for you up front, or include some
time in the analysis phase to determine all that. If you're planning
for later reuse, then be sure to include extra development time for
reusability design and engineering. In one case, I was managing two
simultaneous projects with a reusable common core which was designed
and implemented as part of both, saving time on both projects overall
and reducing the total volume of code.

Group: comp.lang.smalltalk
From: ron@rschultz.pdial.interpath.net ron
Org: Interpath -- Providing Internet access to North Carolina
Date: Thu, 02 Feb 95 09:07:56 PDT
Subj: Re: OO Project Management
____________________________________________________________

Responses to this thread on OO project management still point out that

the project management aspects of object-oriented software development is

significantly different than that of other software development approaches,

and that available project management tools are not ideal to modeling such

efforts (albeit it can be accomplished, sometimes painfully).

But back to my original premise that managing OO projects is different

than managing other types of system development. Berard, Henderson-Sellers,

Booch, and others have noted that the definition of objects and other larger

object-oriented entities (i.e., kits and systems of interacting objects) can

occur with a significant amount of parallelism. A common theme in articles

about object-oriented projects is the realization that development proceeds not

along one major path of analyze the system, design the system, implement the

system, test the system, then deliver, but along many independent and parallel

paths of analyze an object(s), design an object(s), implement an object(s),

test an object(s), integrate objects, then deliver.

The question then is, how does the project manager estimate, schedule and

manage such parallel activity?

Most project plans are currently managed using some form of a project

management tool. Such tools (on a personal computer) include, but are not

limited to: Project Workbench, Primavera Planner, Microsoft Project, and Claris

Mac Project. These tools provide support for the creation of PERT charts,

GANTT Charts, and other form of network diagrams showing task precedence and

succession.

Consider for the moment how these tools deal with a PERT chart. A PERT chart

consists of a network of nodes representing activities, and directed arcs

depicting the required precedence and succession of the tasks. Each node is

unique. A node can not be connected to itself, or any other node that was

completed prior in time to the current node. PERT charts generally depict time

from left to right, and nodes previously completed can not be reopened. Each

node may be exploded into a sub-network.

The waterfall lifecycle is easily represented using PERT charts. The high

level nodes of the PERT chart are identified as Analysis, Design, Implementing,

and Testing. Precedence relationships are established that do not allow Design

to start until after Analysis is complete, and Implementing to Start before

Design is complete, and so on. The project is depicted as four (or some other

number) of nodes, with sub-networks further describing the activities taking

place within each major node.

The recursive and parallel nature of object-oriented development is not nearly

as easy to depict. Instead of having a project lifecycle that consists of four

large activities, the project itself is the summation of possibly thousand of

individual objects with their own separately executing set of activities. Each

object is analyzed, designed, implemented, and tested. These objects are then

integrated into more complex, or larger object-oriented entities, such as kits

and systems of interacting objects. These larger object-oriented entities are

similarly analyzed, designed, implemented, and tested. The instances of

analyze a little part of the system, design a little part of the system,

implement a little part of the system, and test a little part of the system

occurs both from the top-down, as well as the bottom-up.

An automobile manufacturing analogy (a simple and not necessarily technically

accurate one) serves to clarify the situation. When a new automobile is

scheduled for development, one of the first tasks is to generally define the

architecture of the vehicle. This architecture defines the high level

components of the automobile, and how these components will interface. Once

established, separate teams are created to start development. The engine

teams effort proceeds concurrent to the body design team, whose effort

proceeds concurrent to the transmission design team. At points in time the

products of each team are brought together and tested to ensure that the

architecture is still valid and workable. If changes are needed to the system

architecture, each change is identified, the impact assessed, and each team

then acts upon each change and continues completing its object(s). When done,

each team integrates their assembly with the other team, and an automobile is

delivered. Each object, from the automobile itself (the highest-level object,

in this case a system of interacting objects) to the engine, to the pistons,

down to the camshaft bearings, is analyzed, designed, implemented, and tested.
Where certain objects are not well understood, or a high degree of risk is

present, the team may create iterations of prototypes to evaluate facets of an

objects design. Information garnered from the creation and evaluation of

these prototypes is then factored back into the design.

Modeling such concurrent activity, as well as such iterations, is not

straightforward in currently available project management tools. Individual

object life cycles can be input into available tools to deal with concurrent

development. The same set of activities can be repeatedly entered to depict

iterative development. But the level of complexity becomes overwhelming for

many tools.

Assume that an object-oriented system is proposed that contains 100 objects.

Each object requires 25 kernels to be executed. Assume ten objects are

identified as candidates for iterative development, and each require three

iterations of prototyping. The project management modeling of such a project

will require the inputting of , and establishing of precedence relationships

for, 3000 activities ((90 objects * 25 kernels) + (10 objects * 25 kernels * 3

iterations)). This exceeds the capabilities of many tools available today.

But the sheer effort to load this amount of information is a significant cost.

For a large project, managing this complexity can be overwhelming. Current

project management tools can be used, and abused, to meet the immediate need of

project planning and management. The project manager must be cautioned not to

abuse the project to meet the limitations of the project management tool,

rather than abusing the tool to meet the needs of the project. This occurs

often if the project manager is not adequately educated in the management of

object-oriented development efforts. But in the long term new tools need to

be developed that more adequately support the recursive and parallel nature of

object-oriented development.

The Future of Object-Oriented Project Management Tools

An ideal project management tool for object-oriented development would start by

including the following features:
o A set of predefined object-oriented development roles that can be

easily tailored into project position descriptions.
o A set of predefined object-oriented development kernels that can be

easily tailored into project tasks.
o A set of kernel clusters that can be readily assigned to object types.

These object types are definable by the project manager. The project manager

may, for example, define one object type to be simple objects that requires

only design, implementation, and testing. Another object type may include

objects that require analysis, design, implementation, and testing, while

another object type may be those objects that are available from the In-house

Reusability Library.
o A cluster assignment facility that allows the project manager to assign

an object to an existing kernel cluster, or create a new kernel cluster for the

object.
o A networking capability that allows the project manager to establish

precedence relationships between kernel clusters.
o A report generation facility that provides for basic reporting, as well

as project manager defined queries.
o Graphics output using both GANTT, PERT, and other graphical

representations.
o Storage of all entered and computed information in a tool repository.
o A set of defined interfaces that allow external tools (e.g., word

processing packages, spreadsheets, and desktop publishing tools) to directly

access the tool repository as well as all tool facilities. The defined

interface should allow the same access to third party tools as the user

interface(e.g., tool screens, keyboard or mouse input) allows to the tool.
o A simulation or modeling facility that allows the identification of

potential bottlenecks, as well as computing project duration and cost.
This list can be readily expanded with little difficulty. But the above
capabilities serve as an adequate starting point.

The key to such a tool is that the tool should represent the project in terms

of objects. The project manager would, in effect, use the same object-oriented

approach to developing and refining the project plan that the project team uses

to construct the system itself. An attribute of such an tool would be high

conceptual integrity.

Project managers of object-oriented software development projects should seek,

and over time, demand such facilities be made available by project management

tool vendors. Only through communicating these requirements directly with

vendors can the project manager hope to see such features become available.

Ron Schultz
Knowledge Systems Corporation
919-481-4000

Group: comp.lang.smalltalk
From: rmartin@rcmcon.com Robert Martin
Org: R. C. M. Consulting Inc. 708-918-1004
Date: Fri, 3 Feb 1995 16:05:49 GMT
Subj: Re: OO Project Management
____________________________________________________________

The question has been asked: "How do we use our standard project
management tools to help manage OO projects?" On the surface of
things, this appears to be a significant problem. We have used the
normal suite of tools for managing "waterfall" projects, and it is
difficult to see how they can be used to manage "iterative" projects.

However, the standard suite of project management tools (e.g. PERT and
CPM and Ghant) are not incompatible with iterative development. They
are designed to model the schedules of projects, and iterative
projects still have a schedule.

The difficulty is that the items on the schedule are different. In
waterfall project management, the items on the schedule are
"Analysis", "Design", "Implementation", "Test", etc. However in
iterative development it does not normally make sense to use such
items. What items should we use?

There is a common myth that iterative projects are projects without
schedules. They ramble about, hither and yon, until some techie
decides that they have done enough work and declare the project
complete. This is not the case. An iterative projects has a schedule
just like any other project, and that schedule can be modeled with
standard project managment tools

When an iterative project begins, the application is broken down into
many sub-projects, each with a very small number of features. These
sub projects are sometimes called vertical slices, or just slices.
Each slice represents a small amount of work that needs to be
accomplished. It must be possible to array the slices in time, such
that the features implemented in earlier slices do not depend upon the
features implemented in later slices. Thus the slices can be
implemented in a chronological order.

Once the slices are allocated, each can be estimated as to the
resources that will be required to implement it. Then these slices
can be arrayed on a PERT chart, or any other project managment tool to
produce a complete project estimate. However, this estimate is
extremely unreliable.

When the project begins, the time required to implement the initial
slices is recorded, and fed back into the schedule. Each time a slice
in completed we learn more about how much time the other slices will
take. Thus our schedule becomes more and more accurate as time goes
on. The end date on the schedule will change (probably recede) as
more data on the implementation of the slices is gained.

Fred Brooks once said: "Adding manpower to a late project makes it
later." This is certainly true when 80% of the schedule has been
exhausted and only 40% of the project has been completed. The benefit
to iterative scheduling is that feedback concerning the accuracy of
the schedule comes back very early. After the first few slices,
project managers can begin to measure the error in their initial
estimates and plan for resource changes. Thus they can add manpower
to an early project so that it does not become late. (Or they can
decide to scrap the project altogether).

Note, that the items that are placed into the project management tool
are not "Analysis", "Design", etc. They are the slices themselves.

In projects that are really big, the slices should be broken down into
sub-slices, using exactly the same scheme. The schedule for these
slices should also be broken down into sub-schedules, and the process
repeated in a hierarchical fashion.

--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis
2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 | C++

Group: comp.lang.smalltalk
From: jsutherland Jeff Sutherland, Winchester, MA
Org: Galahad
Date: Fri, 03 Feb 1995 14:39:17
Subj: Re: OO Project Management
____________________________________________________________

>When an iterative project begins, the application is broken down into
>many sub-projects, each with a very small number of features. These
>sub projects are sometimes called vertical slices, or just slices.
>Each slice represents a small amount of work that needs to be
>accomplished. It must be possible to array the slices in time, such
>that the features implemented in earlier slices do not depend upon the
>features implemented in later slices. Thus the slices can be
>implemented in a chronological order.
>
>Once the slices are allocated, each can be estimated as to the
>resources that will be required to implement it. Then these slices
>can be arrayed on a PERT chart, or any other project managment tool to
>produce a complete project estimate. However, this estimate is
>extremely unreliable.

There are other issues here that make project estimation difficult using a
traditional schedule. It is not clear at the beginning of a slice what
parts of the system will need to be modified in what order to complete the
slice. As development proceeds unexpected opportunities arise that must be
capitalized on to gain optimum speed, flexibility, and functionality. So
the problem is how to schedule the completion of a project when you do not
know specifically the steps or what each step contains, i.e. the steps must
be allowed to dynamically change as the project proceeds.

The SCRUM process resolves this as follows. Identify areas where change
needs to occur to meet the goals of the project piece. Break the next few
weeks of work into 2-5 day pieces and schedule these "Synchsteps". Start
development and meet daily with the entire team to review and assess
progress.

In daily meetings some Synchsteps will complete, new ones will be
generated, some will be cancelled, and others deferred. Direction can be
changed mid-stream to take advantage of unexpected opportunity and
direction is driven by the consensus of the team.

A chart of cumulative Synchsteps generated is maintained. It rises quickly
and then starts to level off. Cumulative Synchsteps completed are plotted
on the same graph as cumulative Synchsteps generated. The curve rises more
slowly and then starts to asymptotically approach the total Synchsteps
curve. The rate of closure of these curves determines the velocity of the
project. Distance to project completion = velocity x time.

In the SCRUM approach the termination date of a release cycle is fixed.
The only thing that changes it the distance (functionality to complete) or
the speed by which you get there (the rate of change of (Synchsteps
generated minus Synchsteps completed)). You can restrict functionality,
alter the approach, or achieve unexpected breakthroughs which limits
Synchsteps generated. Or you can add resources or otherwise close
Synchsteps which raises the completion rate.

This is equivalent to controlling the impact point of a rocket by raising
and lowering the trajectory, or adding or taking away thrust. If fact,
this is all management can manipulate in this process. To get involved in
any finer detail, management must participate directly in the SCRUM as an
equal player with developers, QA, doc, and users who are part of the daily
SCRUM meetings. The direction of the development moves only by the
consensus of the SCRUM.

This development process is a growing experience for all who participate,
including the management. Control must be released to the SCRUM to enable
it to function as a self-empowered team. In return, applications are
delivered faster, better, and cheaper.

At the same time, the process must be managed, but the manager must be more
like the coach of a rugby team. This is a more rough and tumble
environment than some managers are comfortable with. Also some developers
have problems in really being open about what they are doing and working
with a group process.

The average project using todays methods is 189% over budget. 31% of them
are cancelled before they are complete (see PC Week, 18 Jan). Conventional
project management techniques are a failure. SCRUM works.

Jeff Sutherland
"C++ runs slightly faster than Smalltalk but a lot later!"
jsutherland@easel.com (via Galahad BIX blinker)

Group: comp.lang.smalltalk
From: goochb@swim5.eng.sematech.org William D. Gooch
Org: SEMATECH, Austin
Date: Mon, 6 Feb 1995 10:58:06 -0600
Subj: Re: OO Project Management
____________________________________________________________

On Fri, 3 Feb 1995, Jeff Sutherland wrote:

> ....
> The average project using todays methods is 189% over budget. 31% of them
> are cancelled before they are complete (see PC Week, 18 Jan). Conventional
> project management techniques are a failure. SCRUM works.

True or not (certainly I think the second-to-last sentence is an
overstatement), this doesn't solve anything. Until such time as
the software managers of the world become convinced that SCRUM works
*and they start using it* (and allowing contractors to use it), none
of this very interesting discussion is relevant to my work. You're
addressing the wrong audience.

Group: comp.lang.smalltalk
From: jsutherland Jeff Sutherland, Winchester, MA
Org: Galahad
Date: Tue, 07 Feb 1995 11:07:47
Subj: Re: OO Project Management
____________________________________________________________

>> ....
>> The average project using todays methods is 189% over budget. 31% of
>them
>> are cancelled before they are complete (see PC Week, 18 Jan).
>Conventional
>> project management techniques are a failure. SCRUM works.
>
>True or not (certainly I think the second-to-last sentence is an
>overstatement), this doesn't solve anything. Until such time as
>the software managers of the world become convinced that SCRUM works
>*and they start using it* (and allowing contractors to use it), none
>of this very interesting discussion is relevant to my work. You're
>addressing the wrong audience.

The audience in this newsgroup is the best audience to address when the
need for a complete change in development methodology is required.
Smalltalkers have already demonstrated that they are flexible and willing
to hang in there for the best long term solution, even if it is unpopular.

I find that software managers in companies that I think are going to be
around after the turn of the century are very interested in SCRUM and
trying to implement it on small projects. I'm tremendously impressed at
some of the innovation coming out of some of the MIS shops who are moving
to Smalltalk. (I am also appalled at the lack of productivity in those MIS
shops who are not moving to Smalltalk)

Also, the Pittman paper I referenced which is a highly constrained version
of SCRUM (and therefore more conservatively acceptable) won the IEEE award
for best paper of the year. Software managers who won't read the best
paper of the year should be replaced. And you should refuse to work for
them. There are better things to do in life that will further your career
than work for people who will be shortly obsolete.

Jeff Sutherland
"C++ runs slightly faster than Smalltalk but a lot later!"
jsutherland@easel.com (via Galahad BIX blinker)

Group: comp.lang.smalltalk
From: goochb@swim5.eng.sematech.org William D. Gooch
Org: SEMATECH, Austin
Date: Wed, 8 Feb 1995 09:52:16 -0600
Subj: Re: OO Project Management
____________________________________________________________

On Tue, 7 Feb 1995, Jeff Sutherland wrote:

[In an earlier post, I said:]
> > .... Until such time as
> >the software managers of the world become convinced that SCRUM works
> >*and they start using it* (and allowing contractors to use it), none
> >of this very interesting discussion is relevant to my work. You're
> >addressing the wrong audience.
>
> The audience in this newsgroup is the best audience to address when the
> need for a complete change in development methodology is required.

Development methodology? I thought we were discussing OO project
management tools and techniques. Project management and development
methodology are two very different things, and often handled by
different people within any given project, in my experience.

> Smalltalkers have already demonstrated that they are flexible and willing
> to hang in there for the best long term solution, even if it is unpopular.

Sure, in the arena of software technology. When it comes to project
management, I observe that we often don't have the choice, because
the tools and approach to using them are dictated to us by (who else)
managers.

> I find that software managers in companies that I think are going to be
> around after the turn of the century are very interested in SCRUM and
> trying to implement it on small projects. I'm tremendously impressed at
> some of the innovation coming out of some of the MIS shops who are moving
> to Smalltalk. (I am also appalled at the lack of productivity in those MIS
> shops who are not moving to Smalltalk)
>
> Also, the Pittman paper I referenced which is a highly constrained version
> of SCRUM (and therefore more conservatively acceptable) won the IEEE award
> for best paper of the year. Software managers who won't read the best
> paper of the year should be replaced. And you should refuse to work for
> them. There are better things to do in life that will further your career
> than work for people who will be shortly obsolete.

Sorry, but I think you're living in a dream world. Do you know many
consultants who will turn down paying work because they don't like the
project management tools required by the client? Formal project plans
and schedules, etc., are not something I generally need in order to do
good work, but managers usually require them as a means of predicting
the future, and to some extent as levers to control the future. It's
when they do the latter that there are frequently real problems, and if
SCRUM methodology prevents that, great. However, if managers perceive
that SCRUM takes away from their ability to predict or (try to) control
the future, or if they simply don't feel they quite understand it, they
aren't likely to accept it. In that case, people like me will have no
choice but to continue using MS Project or whatever they will accept,
or simply go out of business.

BTW, I guess I missed the reference to the paper (I looked back at your
previous post on this topic, and didn't find it). Can you please re-post
it or email it to me? Thanks.

Group: comp.lang.smalltalk
From: chandra@lmis.loral.com B. Chandramouli
Org: Loral Medical Information Systems
Date: Wed, 8 Feb 1995 17:59:04 GMT
Subj: Re: OO Project Management
____________________________________________________________

In article <1995Feb3.160549.2349@rcmcon.com>, rmartin@rcmcon.com (Robert
Martin) wrote:

> The question has been asked: "How do we use our standard project
> management tools to help manage OO projects?" On the surface of
>
> There is a common myth that iterative projects are projects without
> schedules. They ramble about, hither and yon, until some techie
> decides that they have done enough work and declare the project
> complete. This is not the case. An iterative projects has a schedule
> just like any other project, and that schedule can be modeled with
> standard project managment tools

Absolutely true. Any manager of some competence would not let a
marketplace driven (in terms of timely delivery of a quality product)
software project
to be executed as above. Agreed. but....

> When an iterative project begins, the application is broken down into
> many sub-projects, each with a very small number of features. These
> sub projects are sometimes called vertical slices, or just slices.
> Each slice represents a small amount of work that needs to be
> accomplished. It must be possible to array the slices in time, such
> that the features implemented in earlier slices do not depend upon the
> features implemented in later slices. Thus the slices can be
> implemented in a chronological order.

The more I think about this, it is becoming clear to me that what Booch
talks about and what the above discussion alludes to, they do not have
much to do with OO Project Management. I have worked on projects involving
100s of engineers, geographically separated, millions of lines of code
with a project duration of year and a half. There were vertical slices and
each slice had its own schedule
(of requirements, architecture, design, coding, etc) and a grand
integration plan. This project itself is a (fairly thick) slice of the
entire product
release cycle which are executed in the Chronological order that you talk
about. But no body even pretended that the project used any OO
methodologies.

So how does OO project management differ from the above style of management?
I think most people would agree with the following observations.

1) OO schedules tend to have lot of internal milestones. Demonstrable
features early in the product release cycle.

2) Prototyping in encouraged.

3) Good OO engineers and managers in general don't believe in "Full and Complete
Analysis" followed by "Full and Complete Design" etc. They do what they
can with analysis, then move on to design probably lot sooner than
traditionally done.

Here are my questions which I am trying to find an answer for myself:

1) So given the above, how can one create a project management philosophy
to accomodate points 1, 2 and 3 above?

2) Why are the above points relevant only to OO? Can a project using a
methodology of Process Decomposition followed by Functional Decomposition
adopt this approach?

3) Along Macro terms, OO, to many seasoned engineers, has a history:
a) Really, OO techniques started at the coding level:
Data Abstraction led to modular code and better maintainable code.
Inheritance and Polymorphism led to better extensible code.
People then started looking for an Analysis and Design techniques
which will lead to good use of Abstraction, Inheritance Hierarchies
that makes good use of Polymorphism. The following general
themes emerged.
b) Analysis reflects the real world problem domain
c) Design is a continuation of analysis with adding computer domain
concepts to analysis.

Given the above history, it looks to me that Iterative Development,
Prototyping etc. that are usually associated with OO are just incidental to
the main OO objective. They probably apply to any type of methodology.

4) This lead to my final observation and question: I think the words Analysis
and Design have too much ingrained meaning from the days before OO.

If Data Abstraction (leading to modular and maintainable design) and
Meaningful Inheritance Hierarchies that makes good use of Polymorphism (
leading to
extensible systems) are our ultimate objective, should n't we been thinking
about how to best to arrive at them starting from requirements and then "invent"
a management philosophy to manage those steps?

Thanks for putting up with my ramblings.

Chandra

Group: comp.lang.smalltalk
From: chandra@lmis.loral.com B. Chandramouli
Org: Loral Medical Information Systems
Date: Wed, 8 Feb 1995 17:59:04 GMT
Subj: Re: OO Project Management
____________________________________________________________

In article <1995Feb3.160549.2349@rcmcon.com>, rmartin@rcmcon.com (Robert
Martin) wrote:

> The question has been asked: "How do we use our standard project
> management tools to help manage OO projects?" On the surface of
>
> There is a common myth that iterative projects are projects without
> schedules. They ramble about, hither and yon, until some techie
> decides that they have done enough work and declare the project
> complete. This is not the case. An iterative projects has a schedule
> just like any other project, and that schedule can be modeled with
> standard project managment tools

Absolutely true. Any manager of some competence would not let a
marketplace driven (in terms of timely delivery of a quality product)
software project
to be executed as above. Agreed. but....

> When an iterative project begins, the application is broken down into
> many sub-projects, each with a very small number of features. These
> sub projects are sometimes called vertical slices, or just slices.
> Each slice represents a small amount of work that needs to be
> accomplished. It must be possible to array the slices in time, such
> that the features implemented in earlier slices do not depend upon the
> features implemented in later slices. Thus the slices can be
> implemented in a chronological order.

The more I think about this, it is becoming clear to me that what Booch
talks about and what the above discussion alludes to, they do not have
much to do with OO Project Management. I have worked on projects involving
100s of engineers, geographically separated, millions of lines of code
with a project duration of year and a half. There were vertical slices and
each slice had its own schedule
(of requirements, architecture, design, coding, etc) and a grand
integration plan. This project itself is a (fairly thick) slice of the
entire product
release cycle which are executed in the Chronological order that you talk
about. But no body even pretended that the project used any OO
methodologies.

So how does OO project management differ from the above style of management?
I think most people would agree with the following observations.

1) OO schedules tend to have lot of internal milestones. Demonstrable
features early in the product release cycle.

2) Prototyping in encouraged.

3) Good OO engineers and managers in general don't believe in "Full and Complete
Analysis" followed by "Full and Complete Design" etc. They do what they
can with analysis, then move on to design probably lot sooner than
traditionally done.

Here are my questions which I am trying to find an answer for myself:

1) So given the above, how can one create a project management philosophy
to accomodate points 1, 2 and 3 above?

2) Why are the above points relevant only to OO? Can a project using a
methodology of Process Decomposition followed by Functional Decomposition
adopt this approach?

3) Along Macro terms, OO, to many seasoned engineers, has a history:
a) Really, OO techniques started at the coding level:
Data Abstraction led to modular code and better maintainable code.
Inheritance and Polymorphism led to better extensible code.
People then started looking for an Analysis and Design techniques
which will lead to good use of Abstraction, Inheritance Hierarchies
that makes good use of Polymorphism. The following general
themes emerged.
b) Analysis reflects the real world problem domain
c) Design is a continuation of analysis with adding computer domain
concepts to analysis.

Given the above history, it looks to me that Iterative Development,
Prototyping etc. that are usually associated with OO are just incidental to
the main OO objective. They probably apply to any type of methodology.

4) This lead to my final observation and question: I think the words Analysis
and Design have too much ingrained meaning from the days before OO.

If Data Abstraction (leading to modular and maintainable design) and
Meaningful Inheritance Hierarchies that makes good use of Polymorphism (
leading to
extensible systems) are our ultimate objective, should n't we been thinking
about how to best to arrive at them starting from requirements and then "invent"
a management philosophy to manage those steps?

Thanks for putting up with my ramblings.

Chandra

Group: comp.lang.smalltalk
From: jsutherland Jeff Sutherland, Winchester, MA
Org: Galahad
Date: Wed, 08 Feb 1995 22:16:32
Subj: Re: OO Project Management
____________________________________________________________

>Development methodology? I thought we were discussing OO project
>management tools and techniques. Project management and development
>methodology are two very different things, and often handled by
>different people within any given project, in my experience.
>goochb@swin4.eng.sematech.org

But this is precisely my point. The reason that the average project is
189% over budget, not to mention late, is that the project management and
development process are closely intertwined in reality, and artificially
separated in our organizations. On successful projects, I have controlled
the architecture, the development process, and the project management, and
involved the entire team in synchronizing them. I've brought $50M projects
to completion this way. I much prefer a SCRUM of 12 people that needs to
deliver a new application within six months using Smalltalk. That's 3
developers, 3 testers, 3 doc people, and 3 users and a lot more fun.

When I had COBOL and C programmers it took 3 times the number of people 2-3
years to deliver less functionality. And by that time, the users changed
their minds about what they wanted. Another reason these projects are
usually late and over budget is that the users must be part of the process
to make it work. In a properly run project they participate in the project
management and help define the development methodology. In many
conventional projects they never show up. They just get fed up, withdraw
the funds, and kill over a third of the projects that are started before
they come to completion.

The record speaks for itself. Current conventional software project
management is a failed approach. I mean, how many times does it have to
break before we realize we need to do something different!

The Pittman paper below is a conservative attempt at change and should be
palatable to most organizations. It also won the IEEE award for best paper
so everyone should read it as part of ongoing education:

Pittman, Matthew (1993) Lessons Learned in Managing Object-Oriented
Development. IEEE Software, Jan 1993, pp. 43-53.

Usability studies, however, have convinced us that only one paper in the
literature describes the rapid application development environment achieved
with Object Studio (the combination of Enfin Smalltalk and Synchronicity
Business Object Modeling and Persistent Object Mapping). Read this next:

Takeuchi, Hirotaka and Nonaka, Ikujiro. The New Product Development Game.
Harvard Business Review, Jan/Feb 1986, pp. 137-146.

If you don't want to change your conventional development approach, a must
read is:

Yourdon, Ed. The Decline and Fall of the American Programmer. Yourdon
Press, 1993.

Jeff Sutherland
"C++ runs slightly faster than Smalltalk but a lot later!"
jsutherland@easel.com (via Galahad BIX blinker)

Group: comp.lang.smalltalk
From: goochb@swim5.eng.sematech.org William D. Gooch
Org: SEMATECH, Austin
Date: Thu, 9 Feb 1995 11:14:44 -0600
Subj: Re: OO Project Management
____________________________________________________________

On Wed, 8 Feb 1995, Jeff Sutherland wrote:

> >Development methodology? I thought we were discussing OO project
> >management tools and techniques. Project management and development
> >methodology are two very different things, and often handled by
> >different people within any given project, in my experience.
> >goochb@swin4.eng.sematech.org
>
> But this is precisely my point. The reason that the average project is
> 189% over budget, not to mention late, is that the project management and
> development process are closely intertwined in reality, and artificially
> separated in our organizations.

Agreed. That's why I prefer to do both.

>....
> The record speaks for itself. Current conventional software project
> management is a failed approach. I mean, how many times does it have to
> break before we realize we need to do something different!

Again, you overstate your case. Conventional project management tools
and techniques, when used well, can and do succeed. Basically, I think
the reasons for failure are more in the way the tools are used than in
the nature of the tools themselves. That doesn't mean there can't be
something better - I hope there is (and thanks for the references). It's
not that I wouldn't change to a different approach if I thought it was
better and had the choice; for now, however, I don't have that choice.

From: David Levy
Reply: dale@morgan.com
Date: Fri, 10 Feb 1995 17:14:18 -0500
Subj: Re: OO Project Management - comp.lang.smalltalk #18941
____________________________________________________________

On Feb 10, 1:37pm, jsutherland@BIX.com wrote:
> Subject: Re: OO Project Management - comp.lang.smalltalk #18941
> >Is there any more info regarding SCRUM that can be forwarded on to me?
> >
> >thanks,
> >dave levy
> >
> >Morgan Stanley
> >attn: David Levy
> >1 Pierrepont plaza 5th floor
> >Brooklyn, N.Y. 11201
> >
> >(718)754-5441
> >fax (718) 754-5205
>
> Nope. But I am working on a white paper. What specific questions do you
> need answered?
>
> Jeff Sutherland jsutherland@easel.com
> Easel Corp. (via Galahad bix blinker)
> 617-221-2424
>-- End of excerpt from jsutherland@BIX.com

What's SCRUM stand for?

To: dale
Reply: dale@morgan.com, jsutherland
Date: Sat, 11 Feb 95 15:24:20 EST
Subj: Re: OO Project Management - comp.lang.smalltalk #18941
____________________________________________________________

>What's SCRUM stand for?
>

SCRUM is a rugby term. I'm not a rugby player myself, but those who are
tell me it is when the entire team links arms, surrounds the ball, and as a
single unit, drives the ball towards the goal.

The Japanese authors of the Harvard Business Review paper I mentioned
applied the term SCRUM to the development process. They also mentioned a
variant called SUSHIMI where a the project is delivered in slices, just as
a Sushi chef slices the sushi. The Japanese tend to use this more
controlled variant.

Jeff Sutherland jsutherland@easel.com
Easel Corp. (via Galahad bix blinker)
617-221-2424

From: Peter Martiniello
Reply: peter@lochard.com.au
Date: Fri, 17 Feb 1995 13:59:26 +1100
Subj:
____________________________________________________________

Hi,

I read your artical on SCRUM programming with great interest. I would like
to get hold of the articales that you mentioned in your mail, if
possible.

I am also interested in find out what type of SW Engineering process
you go through in each iterartion. That is do you produce such
documents as SW requirements, design and test and if so what has been
you experiance in making sure that they kept upto date.

Regards
Peter Martiniello

Lochard Environment Systems
875 Glen Huntly Rd Caulfield Sth
Victoria Australia
PH: +61 3 532 9040
FAX: +61 3 532 8209

To: Patrick_D_Logan@ccm.jf.intel.com
Date: Wed, 22 Feb 1995 23:26:10
Subj: Re: Supporting evidence, Smalltalk and SCRUM
____________________________________________________________

Patrick, you're remarks are well taken. I have some data that might be useful. Comments are below ...

>
>Text item: Text_1
>
>In Comp.client-server I wrote:
>>I agree with this too, to a certain extent. A few of Jeff Sutherland's
>>posts have some statements that may have some facts to support them in
>>his experience, but they come across without the supporting evidence as
>>inflammatory and/or sales bunk.
>
>In Comp.client-server Jeff Sutherland wrote:
>>By "sales bunk" I assume you mean making claims that are not true. I'm
>>ready to deliver. Show me the project and I'll prove the point.
>
>No, I meant claims that without evidence to support them *sound* untrue.
>
>Two examples:
>
>(1) You made a claim about novice Smalltalk programmers outperforming
>COBOL programmers. Without a specific example, preferably several, this
>is difficult to evaluate and sounds like any number of claims made for
>any number of tools.

This morning, I briefed the IS management at Sprint on ENFIN Smalltalk and Synchronicity directions. I was surprised to find out that on their first project in 1993, a Sprint team learned ENFIN for the first time and delivered a production system in 8 weeks. That system is still a key system in production and is saving Sprint significant amounts of money in their business operations. I was not able to determine if the team was made up of COBOL programmers, but they definitely were not Smalltalk programmers.

In a recent evaluation, one of our prospects who was committed to Microfocus COBOL brought in ENFIN for one afternoon for evaluation. The COBOL programmers said they were able to do in one afternoon a prototype of their application that could not be done in a week with Microfocus COBOL even though they already new COBOL and had never seen Smalltalk before.

>I am a Smalltalk programmer, a former Lisp programmer, and unfortunately
>a C++ programmer. I know about productivity. I haven't used COBOL since
>I taught it as a TA in college 15 years ago, but I know enough. Even so,
>to believe your claim, I'd like to know something about the experience
>of the people you call "novice Smalltalk programmers" and something
>about the problem they are solving.

I think you need to experience the productivity of ENFIN Smalltalk and Synchronicity. It is significantly different than raw Smalltalk.

>(2) On another thread you talk about SCRUM you state:
>"Management is guaranteed a delivery date that meets product objectives
>- conventional project planning gives them a delivery date they cannot
>count on"
>
>This sounds to good to be true. There is more to this statement than
>what appears at first. For example, what are they guaranteed to receive?
>Is it guaranteed to be useful? Without ever, ever slipping the date? How
>early in the development process am I able to give my management a
>specific date? How large is the product?
>
>I am very interested in SCRUM because I like the ideas behind it, and
>the way they fit my development techniques as well as what I see happens
>in practice anyway. I believe very strongly in management of complexity
>and risk using scale, autonomy, and incremental development. But can I
>count on SCRUM to guarantee a delivery of very specific and large amount
>of functionality on some date very far in the future? I am not sure what
>you are claiming.
>
>BTW I read the Havard Bus. Journal article you cited. It was OK, but had
>a fair bit of flowery talk without specific definitions. For example...
>
>"Under the holistic or rugby approach, the phases overlap considerably,
>which enables the group to absorb the vibration or 'noise' generated
>throughout the development process. When a bottleneck appears, the level
>of noise obviously increases. But the process does not come to a sudden
>halt; the team manages to push itself forward."
>
>OK. I can *infer* what some of this means, but is this really a
>*meaningful* paragraph? I'd like to know more about what "the team
>manages to push forward" means; what are the "bottlenecks"; what is a
>"level of noise"; what is "absorbing the vibration".
>
>Anyway, thanks for pointing me to the paper. If you have other
>references or information about your own work, I'd appreciate knowing
>about it.
>
>Regards,
>Patrick Logan
>
The Japanese paper on SCRUM definitely needs interpretation to apply to the software environment.

What the Synchronicity team agrees to deliver is broadly characterized improvements to the tool, for example, they are current adding use cases and interaction diagrams to the tool. They develop a rough plan (as good as any usually done on projects) and commit to the date.

The team then uses the process (which I agree needs a lot more concrete definition which is why I need to write a White Paper on it) to drive to the date. The path to get to the result is discovered in real time. They have been successful enough in exceeded expectations of management, that senior management in the company has agreed to the "loose" control specified in the SCRUM paper.

Regards,

Jeff Sutherland jsutherland@easel.com
Easel Corp. (via Galahad bix blinker)
617-221-2424

To: kumamoto@San-Jose.ate.slb.com
Date: Thu, 23 Feb 1995 07:33:14
Subj: Re: SCRUM questions
____________________________________________________________

>
>I've read the two papers and various posts of yours, and I
>have some questions:
>
>> 4. Developers are guaranteed low administrative overhead
>
>It wasn't clear how this was to be acheived. What if the delivery date
>will slip? What and how things will be tracked to flag this? (E.g.,
>what if one person gets sick for a week? Or if one cannot get more
>resources early enough -- i.e. people with the right skills
>background?)

The objective of the process which was not met as satisfactorily as we would like during the last development period is for each developer to post via email projected completion dates and actual completion dates of each SyncStep (each small piece of work).

We then drew a graph with two curves, cumulative SyncSteps assigned and SyncSteps completed. At the beginning of the project SyncSteps assigned goes way up. Then SyncSteps completed starts to rise to meet the SyncSteps assigned line.

The project manager can look at these curves (which should be automatically created from email) and project into the future when the curves will meet (project completion). It the meeting point is beyond the projected date, action must be taken to bring it in. Resources must be reassigned, functionality must be curve, alternative architectural directions must be taken.
>
>One comment/question:
>
>I noticed that SCRUM sounds great for a system with "depth" (many
>layers of dependent functionalties), but what about a system with
>"width" (few layers of dependency, but many (largely) independent
>functionalities)? We have 1+ million lines of (almost all)
>uncommented C code with about 150 executables (some do have to work
>with each other, but mostly they are independent), but they all work
>around our chip tester. We cannot wait years for one team to come up
>with all the tools, yet I don't think it makes sense to have 10
>different project groups go and prototype on their own and each come
>up with one executable every few weeks (but since they have to used on
>one chip tester, all tools have to be consistent).
>
>I would think that an "architecture" team would come up with the
>overall plan or guide for the system and then each team would work off
>of this "master plan." (The teams would first continue to support the
>current system and learn programming language/environment before
>starting the new project.) Or was there something I missed about
>SCRUM?

This is our approach. There needs to be an overall architecture. However, within the overall architecture, there will be components that can be built by small teams of developers.

The goal is to specify the larger context so that small groups can work independently. The traditional curve that shows resource requirements increasing exponentially while lines of code increases linearly must be deal with. The exponential increase in resource is due to communications requirements (between people and between code). Object technology allows you to partition the system to minimize these communication requirements.

A partition of the system is a component with a clean API that integrates well with the rest of the system. The other parts of the system should only have to know the API (set of methods that form the protocol), the scenarios that the component is guaranteed to support, and the events that the component will support. The internal of the component should be a black box to the rest of the system.

A component is normally built with 1-3 people, never more than 6 or the exponential rise in resource requirements will get you. In a Smalltalk environment building a product, there seems to be a need for an equal number of developers, QA people, doc people, and users. So 3 developers are part of a team of 12.

The overall architecture needs to be controlled by a SCRUM of SCRUMs. The leaders of teams meet regularly to review the larger picture.

>Thanks for your time.
>
>Danny
>
>ITS9000 Software Enhancements
>Schlumberger Technologies, ATE
>1601 Technology Drive, San Jose, CA 95110, U.S.A.
>Phone: +1 408-437-5154 FAX: +1 408-437-5246
>Internet: kumamoto@San-Jose.ate.slb.com
>

Our developers have been successful with delivering product using these concepts, but not in implementing them to their satisfaction. At this moment, they are focused on how to guarantee improved quality in the code delivered in this rapid application development mode.

I am convinced that the quality is dependent on continuous automated regression testing and we are working on that.

Jeff Sutherland jsutherland@easel.com
Easel Corp. (via Galahad bix blinker)
617-221-2424

Group: comp.object
From: holder@alsys.com Robert L. Holder
Org: Thomson Software Products, San Diego, CA, USA
Date: Sat, 10 Jun 1995 07:35:18 GMT
Subj: Re: Future of Booch and OMT
____________________________________________________________

In <3r27cc$a4l@news.uni-paderborn.de> Adam Leventis writes:

>The details of the notation will be described in the TWO new books availa-
>ble mid-end of 1995. Why two books? Well, Booch and Rumbaugh actually
>agreed in a common set of symbols, but have a different idea of the OO-
>process. So the two books will use the same notation, but describe a different
>approach. They think they will agree on a common process in1996. This
>ity...

Why two books? More pontification and more bucks for the OO preachers.

>Booch likes to code. When he developed Rose (the Booch CASE-tool), he
>retired to Canada for a couple of month, and haked a first prototype.

So Booch "hacks" and does not follow his own methodology?

>That is how he thinks a project should start:
> * Code for a while a deliver something executable. Like that you get a
> feeling for the complexity and technical possibilities.

> * Afterwards find the use-cases of the system and expand each use-case
> with some scenarios.

> * Take a set of scenarios and implement these.

> * Check the results, and adjust the architecture. Implement more scenar-
> ios.

> * and so on...

>The shorter the time for a cycle, the better. He said that in his company they
>release each week an internal release. You see, the process how he describes
>it is somehow fuzzy. The rest of the day he told so called "war-stories". Suc-
>cess- and disaster-stories out of projects he worked in as a consultant. I call
>his OO-software process method UCS, because a gives no real guidelines.
>Have you not heard of this method? Well it is called Use of Common Sense
>(thanks for this idea Mike).

Well spoken. This is what it all seems to come down to anyway.
OO or SA/SD or "hacking" or ...

>version of Rose is easy to use, has a good C++ generator, but does not support
>the full booch notation and has a lot of bugs. If you would like to use the tool
>to generate code, you have to adopt the notation of the tool. This might work
>for about 50-100 classes.
>It would be great to have a tool that supports the full life-cycle and is easy
>to use. I didn't yet find such a tool. Today I would use document generation

If Rose has alot of bugs does that mean it was not developed using the
Booch method or OO methodology? Do the OO gurus not practice what
they preach?

Group: comp.lang.smalltalk
From: jsutherland Jeff Sutherland, Winchester, MA
Org: Galahad
Date: Fri, 07 Apr 1995 14:45:57
Subj: Re: Analysis, Testing time (was Re: Smalltalk/V latest release?)
____________________________________________________________

>It is my hope that writing small simulations/prototypes *early* in the
>analysis process will help to bridge that communication gap. In the
>context of something tangible (like a running program), I hope that the
>object diagram will "spring to life" for the domain experts, and I expect
>that the use-case diagrams will aquire new meaning for the software types.
>
>Hmmm... This has become a bit of a tangent to the original subject :-)
>I'd be interested in hearing others' experiences with using
>simulations/prototypes in this way, though (hence the cross-posting).
>billf@medicus.com

I've noticed, while consulting and working for several companies since 1986
on OO projects, that it is difficult to get the users to write down all the
use cases, but they are needed for a complete requirement. They are
guaranteed to be there before the analysis is complete for a delivered
system, but you may never get all of them out of the users until the end of
the project.

It has been a lot easier for users to look at static object diagrams of
their business model than to work with entity relationship diagrams. Users
are essential to building a good business object model.

Also, with the SCRUM methodology approach which has been discussed
previously in this newsgroup, the project is managed by seeing working
code, i.e. no project piece is considered really done until a demo of a
working system that incorporates it can be shown. Evolving production
prototypes are the system. When the prototype evolves far enough and works
well enough it is delivered to the users. In this way, the project team,
the users, and the management can clearly see when milestones have been
met, and refine (and adjust) delivery dates accordingly.

Jeff Sutherland
http://www.tiac.net/users/jsuth

"If it doesn't work, it's vaporware!"

Group: comp.lang.smalltalk
From: jsutherland Jeff Sutherland, Winchester, MA
Org: Galahad
Date: Fri, 07 Apr 1995 15:09:14
Subj: Re: Okay, what is this Synchronicity stuff?
____________________________________________________________

>I don't doubt that this actually happened or that your products are
>useful. I find the implicit claims a little misleading though. I
>would be very worried about anyone, doing anything when they don't
>understand at least some of the underpinnings. 100 class apps are
>nothing. Especially when they are "80% auto-gen'd". We've seen the
>sort of code gen'd by Synchronicity and it isn't all that "compact".
>BTW, if they didn't know anything about ST, who did the 20%? The
>folks at Easel in 3 hours? Wasn't a very big app.
>
>I don't mean to pick on this particular example or anything. I just
>find this sort of stuff adds significantly to the hype-factor
>surrounding OO and ST. The last thing we want to be encouraging is
>for the corporate financial officers to be running out and cutting
>teams in half, hiring people who haven't a clue about the environment
>in which they will be working and then assuming that Synchronicity
>will save the world. When it doesn't work it will be OO and ST that
>takes the fall, not the bean counters.
>
>JEff

One of my technical people at a previous company led a $30M project that
runs a $10B nuclear reprocessing plant with an application that took 30
people four or five years to build in C++ and it had about a 100 classes.
This does not count the classes for the technical underpinnings which were
largely class libraries being reused. So 100 classes can be a good sized
project and people who know what they are doing work to limit the
proliferation of classes.

Every system I have every heard of that is over 1000 classes has been a
maintenance nightmare. They should be partitioned into systems that
intercommunicate, each of less than 100 classes.

In the example quoted above, which was a quick prototype, the 20% of code
was written by the people who didn't know Smalltalk. I didn't say we
recommended this. In fact, we thought they had lost their minds when they
did this without learning Smalltalk, but our support team was, fortunately,
able to tweak their code in a few hours. This was a rather hair-raising
incident for all concerned because the customer was on a short fuse and
expected a prototype to work.

As far as cutting staff, take a look at the article by Grady Booch in the
latest issue of ROAD, the SIGS publication on OOAD. He cites an example
where he was brought onto a project that had several hundred people
assigned to it. He demanded that they cut the staff to 50 people maximum.
When they refused to do so, he walked away from the job and let them self
destruct. This was a C++ project. In Smalltalk you should demand that
they cut it way down below 50.

Jeff Sutherland
http://www.tiac.net/users/jsuth

"A good size Smalltalk SCRUM is 12 people (3 dev, 3 QA, 3 doc, 3 users).
If you need more people then the project (and application) should be
partitioned into loosely coupled multiple SCRUMs. This is also about the
same size as the C++ team that Coplien called the most productive C/C++
team in recorded history."

From: Kent Beck To: Jeff Sutherland
Reply: 70761.1216@compuserve.com
Date: Mon, 15 May 1995 18:01:15 -0400 (EDT)
Subj: HBR paper
____________________________________________________________

Is there a good place to get reprints of the SCRUM paper from HBR? I've written
patterns for something very similar and I want to make sure I steal as many
ideas as possible.

Kent

Group: comp.object
From: COATES@EUROPA.UMUC.EDU Ell
Org: umd uc
Date: 12 May 1995 02:58:01 GMT
Subj: Re: Where's the paradigms? (was: C++ <> OOP?)
____________________________________________________________

In <3ou3g6$j5i@news1.delphi.com> jsutherland@BIX.com writes:

>...
> You can't do good object design without OOAD because you
> need design reviews by other experts to help refine your design

I've had success designing my own programs, but for large, complex
projects such a review is either a part of the development process, or it
should be. Stroustrup recommends this in the design chapters of C++
Programming Language, even for smaller projects. Peer review. It's a
good thing to do.