RE: Hacko and process

Subject: RE: Hacko and process
From: Chris <cud -at- telecable -dot- es>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 21 Dec 2001 10:03:31 +0100

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


Chris Despopoulos, maker of CudSpan Freeware...
Plugins to Enhance FrameMaker & FrameMaker+SGML
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.

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 for more resources and info.

Previous by Author: Re: Adobe Framemaker Practical Uses
Next by Author: Re: techwr-l digest: December 21, 2001
Previous by Thread: Re: Hackos and process
Next by Thread: Opinions on Camtasia from TechSmith

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

Sponsored Ads