Wednesday, April 12, 2006

Like Talking to a Wall

When we publish Technical Alerts, it's not because someone has a writing bug. The process of getting one published is pretty complex and follows this path:
  1. Someone sees a need for a TA and either writes a draft (or "draught" for you UKians) or asks someone else to do so
  2. Draft sent to area members for assistance/suggestions
  3. Completed draft sent to other area person (often me) for clean-up
  4. Document submitted
  5. Request sent to an area expert for approval
  6. If approved, documentation department checks for conformity
  7. Questions directed back to area expert
  8. Once everything is resolved, the Technical Alert is published
This can be an infuriating process when we have a hot issue with P1 or P0 priority (i.e., warn people not to do something recommended by Microsoft lest their entire system stop working) but most of us work well together and I've written TAs which were published within 6 hours of my writing the initial draft.

Such is the case with a TA concerning Microsoft's patch 912812, something wholly unnecessary which breaks ActiveX functionality to comply with the order after MS lost the Eolas case (quite possibly on purpose). If you install this, our application will throw up a dozen confirmation boxes on each instance for each user. We're not the only company affected by this, but we're big enough (or our "partnership" agreement with MS is strong enough) that we helped in getting MS to release patch 917425 which repairs the functionality broken by the recommended patch.

We had that TA written and published inside three days back in February when the initial developer version of the IE update was released.

I wasn't surprised when I saw a ticket today called "TA #nnnn" since the damned patch was released yesterday. After almost six years here, I shouldn't have been surprised by the full explanation of the problem.


Customer: We have to apply 912812. When's your patch going to be ready?
Me: We're working on it. No ETA.
Customer: In the meantime [sic] a workaround is required.
Me: Apply MS patch 917425 like the 912812 documentation tells you to do.
Customer: We don't want to.
Me: Too bad.
Customer: We want a solution.
Me: That is the solution! It's Microsoft's solution. They even say so.
Customer: No, we want you to provide a solution today!
Me: Our solution is to use Microsoft's solution.
Customer: But we don't want to apply another Microsoft patch.
Me: You don't want to apply a MS-provided patch which would cost each user five minutes without affecting any other user, but you do want to apply our patch (which we haven't finished writing and testing), the installation of which would take your system down for all users a few hours if you do everything correctly.
Customer: Yes!

My cubicle neighbour Frankie is a nice enough guy, especially when I start his day off right with a few pictures of unclad wimmenfolk, but even that kindness I show only goes so far. He finds the the noise caused by increasing the my-head-shaped-dent in my desk excessive and he complained to management. No more nekkid pix for him this week.

Root Cause:3-3rd party (MS-OS)
But you know damned well that the response from this guy richly deserved a 17.

2 Comments:

Anonymous Željko Gazdag pulled out a crayon and scribbled:

I'm expiriencing the same problem as youe with 912812 since last week. For me, there was not a problem to tell u customer to install a temporary path 917425.

What's more concerning me are this:

1. 917425 is temporary solution, valid only until June

2. Official proposed solution by Microsoft (using innerHTML to insert an OBJECT tag) doesnt work if there is 'script debugging' enabled in browser

3. Some Objects I'm using in my application dont have an visual component (RDS controls etc...), so user can click on what to activate them ???

4. Microsoft had told in white papers that an active-x web browser control is not affected by this update. This morning I have tryed to wrote an little browser using this control. Same shit happend :(

So, what to do now ?

Should I for example call all dealers in Daimler Chrsler network using my application to configure and sale the cars, sorry guys, no more, ask microsoft...

Shit

Have you mybe tryed some other solution to solve this ?

Even if the solution is not to install 912812 I'm sure this shit will be integrated part of IE7 and windows vista

21 April, 2006 13:20  
Blogger ReallyEvilCanine pulled out a crayon and scribbled:

Željko,

1) As far as I understand it, the patch itself isn't temporary. That is, it doesn't expire, but it's only available for 60 days. Good luck trying to find this patch in June.

2) As I understand it, dynamic VB or JS calls should be able to pull objects in without that additional confirmation step.

3) Don't ask me. I've pissed off some people at Microsoft with this blog already, and that unintentionally. Deep down, they understand what I'm saying but you don't want to bite the hand that feeds you and also from their perspectives, MS at least try to do some interesting and innovative things. The I18N people are absolutely killer.

4) Maybe yo00u misunderstood. Anything directly activated is screwed by the update. I just finished tomorrow's blogg (Thursday) and mention it.

Vista: Hah! Wait until the release, which right now looks to be little more than XP with additional activation and a prettier interface.

I managed to HARD-crash IE7 today. All I did was log into a full version of our app. OK, I admit it didn't crash right away. First I couldn't load anythign. Then after whitelisting our domain and setting a lot of security and zone settings to "please bone me up the ass and forget the lube", it finally started to work and pulled down our components. Then it crashed, taking all bits and instances of the browser with it.

I love and hate my job.

27 April, 2006 02:02  

Post a Comment

Links to this post:

Create a Link

<< Home

In compliance with $MegaCorp's general policies as well as my desire to
continue living under a roof and not the sky or a bus shelter, I add this:

DISCLAIMER:
The views expressed on this blog are my own and
do not necessarily reflect the views of $MegaCorp, even if every
single one of my cow-orkers who has discovered this blog agrees with me
and would also like to see the implementation of Root Cause: 17-Fuckwit.