Re: Parallels Between Software Development and Writing Processes

["Doug, Data Librarian at Ext 4225" <engstromdd -at- PHIBRED -dot- COM>]

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.
***********************************************************************