The software factory (was "Don't believe the hype?") (long)

[Steven Jong <SteveFJong -at- comcast -dot- net>]

I'm very interested with the "software factory" model (and, by 
extension, the "technical writing factory" model), and I would like to 
discuss that sub-thread of the "don't believe the hype" discussion.

John Posada quoted Vivel Paul, the Vice-Chairman of Wipro Ltd (an 
Indian outsourcing company with 1 billion dollars/26,000 employees) in 
eWEEK on the software development process (and, by extension, technical 
writing):

"If you look at the way we do software development, you find a very
structured, process way of software development. It is rigorous and
repeatable. It is much more of a factory environment."

John commented:

>> In technical writing, the type of documentation that we equate to
>> quality documentation isn't a done in a factory environment. It's
>> one-off. That's why Chuck's observation of "a section for each, a
>> chapter for each, a page per heading, basically, that it is done
>> according to a formula. In this way, they can split a 200 page 
document
>> among 200 writers and each writer creates a self-contained and 
discreet
>> deliverable. [I don't know where John stops quoting--sfj]

Bill Swallow added:

>> This shouldn't be a surprise to anyone. Run-of-the-mill tech writing 
is
>> easily outsourced, as is most programming, testing, and the like. 
We're
>> the factory workers of the 21st century; if you can build a process 
out of a
>> series of tasks and enforce standardization, you have yourself the 
means
>> of automating much of what you do and can outsource the rest wherever
>> you'd like.

Finally, Mike O. wrote:

>> The vision itself - the idea that software development can be
>> performed as factory work [-] is flawed.

>> On a previous gig I helped prepare the RFPs for a major development 
effort
>> to be outsourced, not to India, but to local US firms. I know for a 
fact
>> that the requirements and system design were very well spec'ed out. 
However,
>> as far as I know the system is still not deployed.

>> The problem with doing software development like factory work is 
that you
>> are unusually vulnerable to unanticipated events and difficulties. 
When they
>> inevitably arise, the assembly line stops, and does not have the 
flexibility
>> to keep moving. Of course, there are usually a few individuals who 
step
>> forward and resolve the problem, but by then it's too late -  you 
have
>> already lost time and efficiency, which was supposed to be the 
advantage of
>> the factory approach.

As a student of quality, I don't believe the vision is flawed; I 
believe it is fully applicable. I base this on the observation of 
Phillip Crosby, the quality expert, that every business manager he ever 
consulted with told him that quality principles, while they obviously 
apply everywhere else, didn't apply to their business, because they 
were unique. Hah! Crosby soon learned that in regard to quality, no one 
is unique. Consider, for example, Crosby's stages of enlightenment (and 
compare them to JoAnn Hackos's characteristic statements about levels 
of quality):

	Why do we have problems with quality?
	Do we have to have problems with quality?
	I know why we have problems with quality.
	I know why we don't have problems with quality!

I apply that to us. Further, having looked at the puzzle for some time 
now, I see how the parts fit together for us; if I can figure it out, I 
think it's true.

The history of industrialization is the story of the transformation of 
art into artisanry and then into mass production. If Tupperware needed 
each bowl made by hand, we'd all be working for Tupperware. The 
hand-carved bowl became the hand-thrown clay pot, and eventually the 
mass-produced, stamped plastic bowl. The hand-tooled rifle became the 
mass-produced, interchangeable-component gun. The hand-tuned sports car 
became the ubiquitous Toyota. The software product that required an 
on-site engineer to install, another to configure, and a third to 
support is becoming the shrink-wrapped commodity product. Well, the 
last is still happening, but there's a company in Redmond, Washington 
making a brave effort to commoditize software; I think they have a 
chance to survive, don't you? The characteristic of industrialization 
is that the item becomes first similar and then identical; the effort 
needed to create a unit decreases tremendously; and then the output 
volume increases tremendously. The volume increases because the output 
becomes identical. The value becomes consistency, not individuality.

Are we really unique? We like to think of ourselves as Artists, or at 
least artists, turning out individual, unique, "artistic" works, which 
can only be judged as art is judged--on individual merit. When I come 
home and work on my novel, I think that's still a reasonable standard. 
However, when I go to work, I think it's not. I'm a judge at the 
International Technical Publications Competition this weekend. Do I 
think we can look at the enormous range of documents (from one page to 
3,000!) and render a coherent judgment? Yes, we can.

I think the trend is precisely toward the factory-worker model. We are 
workers--or at best, artisans--turning out large quantities of products 
that are in significant ways similar, and which can be, and are, judged 
one against another. When you write one book, you won't feel that way. 
Try writing 100, or even 10, and your perspective changes.

From the perspective of the CEO--and I think down to the perspective of 
the department manager--a doc group is supposed to run as a factory, 
turning out manuals, help files, CDs, or whatever in a repeatable, 
predictable, efficient manner. At some level, creating a user's guide 
for Product X is the same as for Product Y. Yes, I know the two won't 
be word-for-word identical. But they'll be more alike than you think, 
particularly from the standpoint of process. Getting a project 
documented, a help file reviewed and approved, a book to print should 
be an everyday occurrence, not a life-or-death struggle. I'm painfully 
aware that at many times and in many places, it IS a life or death 
struggle; but I think that reflects inefficiency, not inevitability. It 
doesn't have to be that way, and it isn't that way everywhere.

I also know this is not the world view of many of us. That conflict 
plays out in this forum daily, along the lines of doing a "good job" 
versus finishing "on time," or even "knocking out content" versus "font 
fondling." There were holdouts against industrialization, too: the 
Luddites, the saboteurs, Ted Kaczynski. I offer no value judgment on 
industrialization; I just note the reality of its dominance. That's not 
the side I want to come down on! I prefer to be among those who figure 
out how to produce effective information products consistently, 
efficiently, and repeatably. If you can do that, you have a competitive 
edge. Good luck!


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP IS THE INDUSTRY STANDARD IN HELP AUTHORING 
New RoboHelp X5 includes all new features such as, 
content management, multi-author support, distributed
workforce support, XML and PDF support, and much more!

Purchase new Macromedia RoboHelp X5 by March 31st and receive a 
$100 mail-in rebate. http://www.ehelp.com/techwr-l

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.