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

Subject: The software factory (was "Don't believe the hype?") (long)
From: Steven Jong <SteveFJong -at- comcast -dot- net>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 10 Mar 2004 08:23:33 -0500


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.



Previous by Author: RE: Don't believe the offshore hype?
Next by Author: Re: Don't believe the offshore hype?
Previous by Thread: RE: Alternative to Word
Next by Thread: Re: The software factory (was "Don't believe the hype?") (long)


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

Sponsored Ads


Sponsored Ads