Subj : Re: Project Meetings
To   : poindexter FORTRAN
From : Commodore Clifford
Date : Fri Dec 22 2023 12:40:16

On 21 Dec 23  16:06:00 poindexter FORTRAN wrote...

PF> -=> Commodore Clifford wrote to Nightfox <=- 
PF> 
PF>  CC> My favorites are the ones where we have a four hour meeting to
PF>  CC> discuss an incident, listening to someone prattle on about how
PF>  CC> they want to be "fair to the devs"... in the meantime, the
PF>  CC> problem isn't even with our code, but with another system
PF>  CC> entirely and once the correct people figured it out, I doubt it
PF>  CC> even took that long to fix it. 
PF> 
PF>  I remember a prticularly spicy post-issue meeting after my company's
PF>  web site was down for an extended period. teams were trying to find
PF> the  root cause, our DB said it wasn't the DB, and when he was
PF> questioned  further, he quit, because he wouldn't work somewhere
PF> where his  expertise was questioned.
PF> 
PF>  If memory serves, it was the DB.

To which Commodore Clifford replies...

In my case, we have the opposite problem.  We have our huge meetings when
something goes wrong and they always blame us and want us to "own" the
problem because it's on the website where you see the error.

The problem is, it's rarely really our problem when it's something big...
it's usually one of the hundreds of service endpoints we have to interact
with.  One of those fails, we have an error message displayed. But it's
not our code that is in error.  Sometimes, we can do a fix faster (this
is usually the case when someone makes a change to a service without
actually testing it or notifying all consumers of the service) but they
still try to "blame" us.

It's getting old.

--- RATSoft/FIDO v09.14.95 [JetMail 1.01]
 * Origin: STar Fleet HQ - Real Atari! bbs.sfhqbbs.org:5983 (21:3/171.0)

.