RE: question on speedy collection of engr info

Subject: RE: question on speedy collection of engr info
From: "Scott Wilborne" <wilbornes -at- vtls -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 6 Sep 2001 15:39:15 -0400


Your problem speaks to the need for a stronger design process. If the
customer is going to use these commands, it seems like there should be a
list of them in a design document before the coding begins. Unfortunately
this is not the way reality always works. In lieu of a good design document
to work from, I would pester the engineer until he realizes it would be
easier to keep me updated on the commands that make it into a release than
have me standing in his cube asking questions every 30 minutes. This really
works! Be a bastard if you have to.

As to your suggestions . . .

>* trying to get the engineer to add a short message to his CVS check-ins,
>and setting up an auto email to me on his check-ins

I think communication of this sort can be very useful. And if it is set up
as an automatic process as opposed to a "please do this if you have time"
sort of thing, you can be reasonably assured that you're getting all the

>* meeting with the engineer more often (difficult, because he's generally
>out of the office and kinda flaky about making meetings anyway)

Bug him until he develops a tic everytime you come within 100 feet

>* breaking up the toolkit guide into portions and emailing the engineer
>what i have in bite-size chunks, hoping he'll review it and send me

If the developer doesn't take time to give you the information you need to
write the document, I would not count on him taking the time to do an
adequate review of the document.

>* doing the above, but using the bugdb instead of an email

>* trying to get QA person to warn me a couple days before he plans to test
>the new commands so I can pester the engr for exact usage before QA tests

How does the QA person know the commands to test? Whatever method QA is
using seems like the best route.

>* trying to get some manager types to realize that a ton of tiny point
>releases aren't as helpful as they might seem

I would think point releases are better suited for bug fixes than new
features. Although the release schedule might be the cause of your problem,
I wouldn't put too much money on it changing.

>ARG! :(

Good luck!



A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe.

+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: +++

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.

question on speedy collection of engr info: From: julie brodeur/mccready

Previous by Author: RE: Word question: table misbehaving
Next by Author: RE: Intranet Search tools
Previous by Thread: Re: question on speedy collection of engr info
Next by Thread: Re: question on speedy collection of engr info

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

Sponsored Ads