RE: Hacko and process

[Chris <cud -at- telecable -dot- es>]

Er...  This isn't exactly about the HDMPEE12S (Hackos Doc Methodology 
Process Enumeration Enhancement Twelve Steps), but...

Way back when, I worked for a company that produced a well known (and 
still successful) doc publication product.  Since it was a pubs product, 
the pubs dept was considered a very important source of input, both in 
product design, and in establishing processes.  Yes, we had specific 
processes in place.  In order to incorporate Pubs (non-programmer) input 
in the product design, we needed a very special something sometimes 
referred to as SPECS.  And we got them.  Lo and behold, the dev process 
itself received quite a benefit from the spec process, and indeed 
developers spent a decent portion of their development time writing and 
reviewing specs.  

The pubs dept acted as user advocates and reviewed the specs for work 
flow, among other things.  Of course, we often met with answers like, 
"That can't be changed because of the architecture of the product." 
Fair enough.  But we did get in there and make a difference.   The 
process itself wasn't "written down", per se, but we had templates and 
review requirements set up, and that pretty well formalized the whole 
thing.  Oh yes, and we had a style guide, too.  That turned out to be a 
good thing, because we delivered on three major platforms (Mac, Win, 
Unix) at the same time, and in 5 (I think) languages all in the same 
month.  This also underlines the importance of a clear scheduling 
process, which I believe we had.

In return, we were expected to use the product when it went into Beta. 
A bit scary, but we put it through its real-world paces.

My point...  Process can sometimes "work", and the time spent on it can 
pay off.  In fact, the IEEE has demonstrated repeatedly that every hour 
spent on specs takes two hours off of development.  Programmers have a 
hard time believing that.  I have personally heard programmers, who took 
some course here and there, say things like, "They didn't let us start 
programming until the course was more than half over!  I was horrified 
that we spent so much time on the specs.  But it turned out that the 
programming was much easier, and we all finished our projects on time!"  

But I agree with anybody who calls out a loud and clear "IT DEPENDS". 
Work is fundamentally a social thing.  Your *first* requirement on any 
job is to understand the social situation and determine the best way to 
apply yourself.  By necessity that precludes a formula response.  (As to 
whether or not Hackos advocates a formula response, I am ignorant and 
have no opinion.)

cud

--
Chris Despopoulos, maker of CudSpan Freeware...
Plugins to Enhance FrameMaker & FrameMaker+SGML
http://www.telecable.es/personales/cud/
cud -at- telecable -dot- es



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Be a published author!  iUniverse gives you: a high-quality paperback, a
custom cover design, and distribution to 25,000 retailers.  And it's
affordable.  Join our almost 10,000 published authors today.
http://www.iuniverse.com/media/techwr

 Your monthly sponsorship message here reaches more than
 5000 technical writers, providing 2,500,000+ monthly impressions.
 Contact Eric (ejray -at- raycomm -dot- com) for details and availability.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -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.