# Software Development is a Negotiation

Software development, like all research, is
impossible to plan from start to finish.
Successful project management must reconcile
the desires of software users with the
constraints of software development.

Re-engineering books suggest that all
companies have "core competencies."
Organizations excel at certain skills for
historical or accidental reasons.  Projects
that rely on these competencies give the
organization an advantage that others cannot
easily match.  (Unfortunately, the idea
became an excuse for eliminating skills.)

Software development is optimum when a single
individual can master all necessary business
and development skills.  Much innovative
software gets written this way, often
secretly.  The motto is "understand the
issues and do the right thing."
Communication is not an obstacle.

Sometimes two individuals split roles.  One
advocates features for customers and the
other advocates simplifications in the
software, perhaps changing the way customers
work.  The two argue constantly, but the
result is very satisfying.  The dialectic
creates a product superior to what either
could have designed alone.

Project management becomes necessary when a
larger team must distribute skills.  Too
often project management prevents the
necessary dialog.

A top-down management will specify features
desired by customers, estimate resources
required for each feature, then distribute
tasks to developers within an overall
schedule.  This arrangement is suboptimum.
Developers are not involved, or they are
involved and committed to a specification
before they understand the implementation.
Lower-priority features remain, even if they
prove to be more difficult than acceptable
alternatives.  Developers with special
expertise lose opportunities for
simplifications or innovations.

Development schedules with time lines and
critical paths help manage foreseeable
scenarios.  When used well, development
schedules distribute the load between
developers.  Schedules can help manage
resources and expectations, but with
limitations.  Schedules omit uncertainties of
research and design.  A schedule assumes that
the implementation is well understood.  Even
if time estimates include probabilistic
errors, these estimates allow only for
foreseeable scenarios.

A development schedule is useful only for the
immediate future.  Software components will
be built in a certain order, with increasing
uncertainty.  The first component to be
built, in the first month of the project, may
be understood with ninety percent certainty
by developers.  The actual construction of
that component will expose the ten-percent
ambiguity in the specification.  This
uncertainty propagates to the next set of
components to be written, with a
proportionally weaker understanding of the
design.  Six months later, the original
development plan may be entirely
inappropriate.  Early designs appear naive,
and new opportunities appear.

All development plans thus become "spirals,"
whether acknowledged or not.  If plans
prevent adjustments between user features and
software components, then the project becomes
more inefficient than necessary.

Feature lists must not be confused with a
design.  Only constant discussion within the
team can produce a design.  Project plans
invariably list features in their order of
importance to users.  Feature lists attempt
to balance the complexity of the product with
the available resources and schedule -- but
they cannot.

Too much of the underlying infrastructure of
software is invisible to users, and to
project managers.  A developer creates
software components in order to implement
desired features.  Development times can be
estimated and adjusted for components but not
for features.  A schedule is accelerated by
simplifying or discarding components, not
features.  Only constant renegotiation can
simplify development and remove the fewest
important features.  Lost features can be
compensated with unforeseen improvements.
Only when the product is finished can the
design be complete.

Bill Harlan, Oct. 1998