RE: Ever wonder why techwhirler lives seem so crazy? (a long rant)

[Emily Berk <emily -at- armadillosoft -dot- com>]

The following is a long but heartfelt answer to a thread that seems to have snipped ... 

When I was a freelance software developer, before the heydays and during the heydays, I knew that I would never be unemployed in the few months leading up to major holidays -- mid-November through New Years', Memorial Day, July 4, mid-August through Labor Day -- I was almost always frantically busy.  And well paid.

Why?  Because software was always scheduled for release on the day before a holiday.  Did they REALLY think that their customers would be sitting at their desks bright and early on Dec. 26 ready to install new operating systems???  Probably not.   My theory is that the managers wanted to be able to put down their whips and go skiing/golfing/sailing on the day before the holiday or the Friday before the long weekend ...

In my (LONG) experience, 100% of the technical projects scheduled in this way were nowhere near completion by deadline.  

A few weeks before the deadline, everyone started panicking and the frantic throwing of people and resources and pizza dinners at the problem began.  

I would then be hired to join the melee' and did my best and earned good dough.  

But there are only so many hours in a day and so, and so, sometime very uncomfortably close to deadline day, late on the actual deadline day if the managers were particularly sadistic, the schedule would slip.  

So, as a programmer, I learned not to take deadlines too much to heart.  But the unrealistic deadlines, lack of sleep and good food, the haranguing of the managers took their tolls on everyone.  Chaos (and worse) was inevitable and infectious.

As a software project manager, I took these experiences into consideration and tended to make fairly accurate predictions of when things could actually be completed.  Which meant that I lost out on many contracts because I refused to assume that what would take two or three months could be done in the few weeks that others promised.  (They never delivered.  Or, at least, they did not deliver what was originally promised.  I check up on these things.)

So now I'm a technical writer whose philosopher is: "Hold the pickles, hold the lettuce; special orders don't upset us..."???  As a documentation writer, I NEVER get upset by changes in feature set, changes in schedule, changes in UI, changes in documentation requirements, changes in company name, changes in product name, changes in version number, changes in copyright, changes in the weather.  I get paid by the hour.  I get paid to document changes.  

Change is not a problem.  Change is life.  Life is change.  I live in Chaos but MY life need not be chaotic.

It is my belief that the software really does have to come first and that there's no point in releasing it until the engineers are ready and there's no way to complete the documentation until the engineers or QA, at least, have had enough sleep to review the documentation with at least one eye open.

So, when it's two weeks AFTER the completed manuals were due, and I've heroically managed to write 75% or 80% or 90% of the documentation without any significant assistance from engineering and they slip code freeze to the day before the release is supposed to be complete, I am fine with it IF THEY ARE GRACIOUS ENOUGH TO:

1.  Give me at least an inkling of what's going to have to change and where I can get information about it;  (I don't need to be told explicitly.  I'm happy just sitting in on the regularly scheduled engineering meetings, or getting the published and regularly updated and useful status reports ...)

2.  At least ask me for an estimate of how long I think completing the documentation will take.  (If I've been sitting in on those engineering meetings, I usually have a start on nearly everything that will change and have let them know what my issues will probably be.)

But, what seems to be happening lately, or maybe it's that the particular organization I was with is way into finger-pointing, is that:

Feature freeze slips 
(and is occasionally abolished.  You are told that you WILL NOT KNOW WHAT THE SOFTWARE WILL DO UNTIL IT'S DONE, or maybe later); 

     Code freeze slips; 

            BUT 

            the delivery date for the documentation slips NOT AT ALL.  

And if I timidly venture that I will need some short but finite amount of time AFTER code freeze to get the almost-completed documentation synchronized with the just-realized Reality (i.e., take the new screen shots, document changes to the GUI, document the additional features, remove mention of the features not included, document the fixes necessary to make certain features work), 

   The VP of Engineering will then turn on me in regal finger-pointing splendor and unleash "How dare YOU delay OUR project?  Our team has worked its fingers to the bone to get us where we are today and YOU have the nerve to tell ME that it's going to take you TWO HOURS to complete all 17 manuals?  Why didn't you warn me earlier?"  

Course I originally had two MONTHS scheduled to complete the documentation after code freeze.  But now 2 hrs. is way too long to wait.  Geez.  Doesn't anyone know how to interpret/use a PERT chart anymore?  Isn't that why the VP of Engineering makes those Big Bucks???

So, anyway.  I'm looking for my magic wand and I'm developing my time machine and my cloak of invisibility.  And if I ever lay hands on any one of these things, I will use it and my life will be one of order and perfection.

Until then, it's not just that my life SEEMS so crazy.  It is.  On the other hand, my attitude needs no adjusting, thanks.

--Emily, feeling like Cinderella today.  Guess Erika's hit one of my nerves...

On Thu, 11 Apr 2002 08:59:48 +0300, Erika Yanovich <ERIKA_y -at- Rad -dot- co -dot- il> wrote:
>Geoff, Andrew, Bruce and all,
>A question comes to mind when following this thread. Do you think we should
>not plan at all beacuse X% of our projects end up in chaos? My opinion is
>that we should, it gives a framework to our actions. Most problems occur
>when people have rigid attitudes i.e., they try to apply processes in
>chaotic environments or act loose in steady ones. For me, the name of the
>game is flexibility: ability to adapt your attitude to each situation. To do
>that, one has to first undertsand the  environment and then be able to
>change his/her attitude, without worrying that this looks like inconsistency
>to others.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~                            Emily Berk                                 ~
On the web at www.armadillosoft.com *** Armadillo Associates, Inc.      ~ 
~             Project management, developer relations and               ~
extremely-technical technical documentation that developers find useful.~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr

Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

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