radical revamping of techpubs

[Flato, Gillian]

...or similar biggies realize that time-to-market is everything, 

Time-to-market is not everything if you sacrifice quality. If you're first on the market but your product is crap, the fact that you were first on the market is irrelevant. 

I know a CEO who got fired because all he cared about is being first on the market but his products were crap and failed often. Other company's that were slower to market but turned out quality products, stole marketshare from that company. The company almost went under until the board of Directors wisely fired him and put a new CEO at the helm.


-Gillian


-----Original Message-----
From: framers-bounces+gflato=nanometrics.com at lists.frameusers.com [mailto:framers-bounces+gflato=nanometrics.com at lists.frameusers.com] On Behalf Of Technical Writer
Sent: Friday, October 19, 2007 12:35 AM
To: framers at lists.frameusers.com
Subject: radical revamping of techpubs


The "external documentation" recommended for XP and agile development is fundamentally different than the documentation model used in old-style waterfall design. Because the application itself is built in an iterative process, rather than being carved in stone, reacting to feedback from the client, documentation before the last minute is pointless. The reason should be obvious; the application being documented in the early stages bears little resemblance to the application delivered.
 
That is not incompetence on the part of the people footing the bill, nor chicanery on the part of the developer. It is directly related to the reason why online help files are viewed so dimly by the average user; the user doesn't know what to ask to get the answer they need. Similarly, the client may think he, she, or they want ab and d, when what they really need is wx and a little y. Until they see a prototype of ab and d, they may not honestly realize that ab and d is not what they need.
 
There are some developers who attach themselves to large corporations, turn out bloated monstrosities that do very little, and insist that everything be cut-and-dried and filed in triplicate before the first line of code is written. That presupposes that the client knows up front exactly what the final deliverable should be. That is almost never the case. Change is what XP does really well, and in that change, it is pointless to document the app at each iteration, then toss all the carefully crafted prose because it doesn't describe reality now, and only describes what reality used to be.
 
In 2007, software developers other than Microsoft, Oracle, or similar biggies realize that time-to-market is everything, and first mover advantage goes to the swift. Lean management and agile development are attempts to gain a competitive advantage or a bit more market share. There is little point in obsessing over whether or not the end user recognizes symmetry or consistent voice in the documentation when your competitor is outflanking and outrunning you by hiring double your developer staff in Bangalore.
 
There is room for the old-style, Java Dilbert developers, and for those who document their doings. However, a lot of orgs are realizing that the first step in software development is a workable prototype and a good, solid proof-of-concept. Beyond that, they are also realizing that having a competent business analyst watching over the development process is a major advantage; especially if the BA has enough business sense to know when to pull the plug, send the developers and contractors home, and declare the mess as over.
Case in point; Inkos. They were trying to implement SAP ERP software, and were $25 million into it before a new IT manager pulled the plug and declared it "inappropriate for Inkos." Along with the documentation that was supposed to tell the IT staff how to use the spiffy new apps.
 
In short, the pie-in-the-sky is often in the eyes of the client declaring "requirements," when they don't know yet exactly what they want. They know generally enough to welcome XP, and a quickie prototype that enables them to understand exactly what they really want and need. Building software is not like building a bridge or skyscraper, and the simplistic similes to building a house without a detailed blueprint are misleading. 
 
When you build a house, you are not usually in a race with the contractor down the road to complete and get on the market first or wind up with a major piece of nothing. You can always sell the house at a discount, and recover all or most of your investment. Clients for a software application dragged out over years of development time might find that its value decreases at a faster rate than it is being developed, and by the time it is delivered, it is outmoded, outdated, and pretty much useless. Whether it is well-documented or not is irrelevant.
_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook - together at last.  Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033_______________________________________________


You are currently subscribed to Framers as gflato at nanometrics.com.

Send list messages to framers at lists.frameusers.com.

To unsubscribe send a blank email to 
framers-unsubscribe at lists.frameusers.com
or visit http://lists.frameusers.com/mailman/options/framers/gflato%40nanometrics.com

Send administrative questions to listadmin at frameusers.com. Visit
http://www.frameusers.com/ for more resources and info.