Slow Down Development, NO; Speed up Minds, YES

[Andrew Plato <intrepid_es -at- yahoo -dot- com>]

> Software will never improve - for us, writing about software - until the
> process is slowed down and the focus shifted to the product itself instead
> of time to market (and as Tog pointed out, half the product may be the
> documentation that accompanies the software/hardware).
> 
> One developer I worked with said, "GM doesn't turn out half a car then
> explains to the buyer, 'Oh, we'll give you the oil filter, other two tires
> and seats in the next release.'"

Software development is NOT comparable to the production of tangible, durable
goods like vehicles. Multitudes of MBA classes have tried to make comparisons
to software and traditional production methods. These comparisons always fail
because tangible, durable goods do not share the same function, penetration,
and use in the marketplace. 

Unlike a car, software is more valuable the cheaper, simpler, and more
ubiquitous it becomes. Most durable goods are more valuable when they are
complex and exclusive.  A Mercedes E430 is more valuable than a Chevy Impala
because an Impala uses simpler and more commonplace materials and designs 
(Okay, I have to admit some bias here. I just bought a Mercedes E430.)

Furthermore, software, especially the Internet, is a rapidly evolving, fluid
business environment. There is immense value in being first to market and
staking out a standard for evolving technologies and delivery mechanisms. 
Amazon.com can excel where etoys.com fails because Amazon has so much more
experience than etoys.com. 

I think this is one of the most common misunderstandings many people have about
the software industry. Speed to market IS more important than perfection. The
space shuttle may be a wonderful and very secure spaceship.  However, it does
not have to meet the rapidly changing environment of the Internet. Moreover, it
is not an entrepreneurial endeavor. NASA as well as many defense related
industries have the luxury and necessity to take things slow because lives are
on the line. Nobody has ever died because a credit card processing object on an
Apache web server failed to properly load. 

For suggested reading, check out Kevin Kelley's Rules of the New Economy. This
was an eye-opening book I read about 3 years ago. It shows how the traditional
"analyze every flippin' detail to death" engineering methods simply do not
work, nor are they ever preferable, in the new economy.

As tech writers, there is a powerful lesson here, one that has helped my
writing immensely. I realized that my documents are more useful when they are
written very quickly and very close to the end-point of a project.  Call it
"just in time? (JIT) documentation.  Yes, this makes for a few weeks of pure
hell and documents that have a few flaws. But the information is very fresh.
Also since it was written in a short amount of time, my tone and approach to
the information is usually more unified.  Time often has a profound effect on
expression.  The longer you chew over words and designs, the more likely you
are to dream up a reason why it needs to be completely re-done, thus wasting
time.  

I also don't have to worry about engineering changing the product on me (too
much) because I am jamming out the document so quickly and so close to FCS
(First Customer Ship) that they can't change it.

Now, I wouldn?t recommend this method to just anybody.  You have to know your
tech stuff very well and need to be able to rapidly express complex ideas 
Beginners and process freaks probably are not well suited to a JIT environment.


Unfortunately, many tech pubs groups work in traditional horrifically slow
methods where everything is checked and rechecked a bazillion times.  Yeah, the
docs may be grammatically perfect but more often than not, the information is
stale and outdated by the time it is done. All that time used up dreaming up
processes and checking to see if the tender needs of the users are met, is
wasted because the data (the raw technical information) is wrong, outdated, or
overly generalized.

Software and documentation development will improve when people learn to adapt
quickly and thrive in dynamic environments.  The future is fast and furious.
You can either join the race or rot on the sidelines. 

Andrew Plato
For a stiff giggle see http://members.home.com/aplato  
WARNING: This site may warp your fragile little mind. 


__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com