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

Reply via email to