FWD: Re: Thoughts on working WITH developers...

[Anonymous User <anonfwd -at- RAYCOMM -dot- COM>]

Name withheld upon request. Please reply on list.

*************************************************

> If I'm understanding this correctly, your developer modified
> the interface at the last minute, then (the unnamed someone
> referred to above) assigned responsibility for missed deadlines
> to you? Really?

I can't count the number of times developers who really, really ought to know
better have pulled a stunt like that. In a couple of cases, almost EXACTLY like
that.

> You desperately needed management support, a clear
> documentation development process, or both. That simply
> shouldn't happen.

And in an ideal world it doesn't. However, for those of us who are working in
the real world, it really does happen. And far too often.

> For those who are or might be in this situation...
> When you agree to deadlines for documentation
> deliverables, you need to specify the schedule with
> respect to specific milestones in the product development
> schedule. <snipped example>

Senior writers know enough to write a good project plan with dates that have a
lot of contingencies and slip factors built in.  They also know enough to keep
telling management (or whoever) that documentation MUST lag changes to the
interface, or to basic functionality.  However, they unfortunately also know
that there are far more cases of developers skating in at the last minute with
changes to code that can't be reflected in the documentation for lack of time,
and then winding up having to defend the documentation not reflecting the
released software.  It happens almost everywhere, in large and small companies
alike, in my (rather considerable) experience.

> If your management etc. tells you that you have to deliver
> documentation products on or before the day that the code freezes
> or product ships, you need to have them sign off (literally
> or figuratively) on what WILL NOT be done. That is,
> "boss, I'll be happy to deliver the docs on the day that the
> code freezes...would you rather have inaccurate screenshots,
> inaccurate processes and descriptions, or what? I'll fill in
> the rest in photocopied release notes as soon as possible."

One of the most-often quoted maxims covering this is the old "Quick, accurate,
or cheap. Pick two."  Some managers understand that you really CAN'T have all
three, and that you truly are sacrificing one in order to get the other two.
However in my experience many managers (and most developers) truly think that
you're just kidding, and expect writers to deliver highly accurate
documentation, within budget, despite the last-minute changes.

<withhold my name, please>


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=