Re: Parallels Between Software Development and Writing Processes

Subject: Re: Parallels Between Software Development and Writing Processes
From: "Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>
Date: Thu, 19 Jan 1995 09:53:57 -0600

George Hayhoe writes:

*****************************
Dave Taylor aptly observed that there are definite parallels between
the software development and writing processes. I have noticed the
similarities as well, particularly the reluctance of both developers
and writers to do the up-front work which makes delivery of the final
product so much easier and typically improves the product as well.
*****************************

I've noticed it here, too. Our group (Data Administration) is charged
with managing, organizing and maintaining the "common" corporate data.
This involves, among other things, getting application development teams
to model their data in a rigorous way before they begin coding, and make
sure their models and data are coordinated with other models and data.
Most teams are not terribly excited about this process (although some
really complex projects have actively sought our help).

*****************************
On and off for the past ten years, I've been helping software
developers at my company formulate their software development
methodology. It is a model of what such a document should be but is
more often ignored than observed. Why? Because it stresses the need
to engineer software rather than simply write code. The preferred
approach here--as elsewhere, I suspect--is too often the same as in
the old joke about the project manager whose first words after
receiving a request for a new application are "Smith, you go find out
what the users want; Jones, you start coding NOW!"
******************************

I think it's because writers like to write and programmers like to program,
and meetings (where definitions are distilled and plans are made) are
boring. Add to this a trends in corporate management that stress
"initiative," "action," "getting the job done," and "not being
bureaucratic," and you can see why people resist the planning steps.

Until software shops define the "product" as, not just "a hunk of
executable code" but "executable code that meets user needs, coordinates
with other data, and has training, documentation and other support in
place" we'll continue to have this problem.

The Air Force went through a transformation something like this in the late
50's and early 60's when it went from a "weapons" concept to a "weapons
system" concept for aircraft development. Prior to that time, programs
focused on the aircraft--airframe, engine, performance, etc. The result
was often delivery of great planes for which little or no planning had been
done in terms of training, spare part acquisition and so forth. This was OK
when aircraft used more common parts and where easier to figure out, but as
systems became more complex, months or years could pass between delivery
and effective use.

A weapons system concept views everything--crew training, spare parts,
consumables, maintenance facilities, maintenance plans and training, etc.
as parts of an integrated whole that must be brought together at the right
time. Obviously, the first thing that happens is that nominal project
costs rise, timelines stretch, and complexity balloons, because our
project not only deals with all the performance, cost and
manufacturability issues we where dealing with before, but all the other
stuff as well. It takes a fair amount of discipline to realize that all
this other stuff was always there, it just wasn't being dealt with, and
that time and costs are actually lower with better coordination.

(Note: I'm over-simplyfying to make a point; the need to coordinate the
parts of a project became apparent over time, and did not magically change
at one point when the system concept was adopted, but you get my drift.)

Anyway, software faces a similar hurdle. Where once we could slap
together a system in the garage or the corporate basement, task complexity
now demands better coordination, better management, and including lots of
people outside the traditional applications group. This makes the project
leader's job harder, bigger, and less fun. Is it any wonder they resist?

Skoal,

Doug "Praise not the day until evening has
ENGSTROMDD -at- phibred -dot- com come; a woman until she is burnt; a
a sword until it has been tried; a
maiden until she is married; ice
until it has been crossed; beer until
it has been drunk."

--Viking Proverb

***********************************************************************
The preceding opinions and positions are mine alone, and are only
coincidentally related to those of Pioneer Hi-Bred International, Inc.
***********************************************************************


Previous by Author: Populate as a verb for "to fill in"
Next by Author: Re: Can Online Documentation be Used to Increase the Usability of Nuts-and-Bolts HARDware Documentation?
Previous by Thread: Re: Parallels Between Software Development and Writing Processes
Next by Thread: POSITION AVAILABLE


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads