Een tweet het gevra waarom uitteken “dae kan neem”. Span styf vas, ek gaan jou vertel ongelooflik die storie van hoe dit gedoen word in Enterprise Development™...
Daar is een bank. Jy het waarskynlik daarvan gehoor, en as jy in die Verenigde Koninkryk woon, is daar 'n 10% kans dat dit jou bank. Ek het daar gewerk as 'n "konsultant" vir 'n uitstekende salaris.
Die bank stuur bemarkingsbriewe uit. Daar is 'n klein "uitteken"-skakel in die voetskrif van elke e-pos. Mense klik soms op hierdie skakels.
Deur op 'n skakel te klik, laat een prehistoriese webbediener draai iewers in die bank. Eerlik, dit het my drie weke geneem net om hom te vind.
Hierdie diens stuur 'n e-pos na jou interne inkassie elke keer as 'n skakel geklik word. Dit gebeur 'n paar honderd keer per dag.
Voorheen is dié briewe aan ’n spesifieke werknemer gestuur, maar vyf jaar gelede is hy weg.
Nou word die brief aan die verspreidingsgroep gestuur. Hulle kon nie die ontvanger se adres verander nie, want dit was hardkodeer, en hulle kon nie die bronkode van die diens kry nie. Die diens is in Java 6 geskryf.
Briewe in die posgroep word nagegaan deur twee werknemers van die bank se buitelandse sentrum in Hyderabad (in Indië). Hulle werk hard en voltooi hul take ontsagwekkende, maar verdomp, hierdie werk is ondraaglik.
Ek het met hulle gekommunikeer via videokonferensie en hulle het al die tekens van onderneming-posttraumatiese sindroom gehad. Hulle het hierdie nonsens beveg oor die jare en gedurende hierdie tyd niks het nie verander nie.
Wanneer 'n brief aankom, moet hulle 'n SQL-skrif uitvoer wat bepaal of die adres wat uitgeteken word aan die bankkliënt behoort (dan is die protokol een) of nie (dan 'n ander).
As die ontvanger 'n kliënt is, moet hulle nog 'n SQL-skrip laat loop wat die kliëntrekord in die pre-ETL-omgewing opdateer. Alle veranderinge word om 16:00 Londense tyd deur 'n aparte span in Skotland hersien. As die veranderinge verifikasie slaag, sal dit op die regte databasis toegepas word op 'n ander dag om 16:00.
As die ontvanger nie 'n kliënt is nie, voeg hulle dit by 'n Excel-sigblad en stuur dit aan die bemarkingspan in Swindon voordat hulle huis toe gaan.
Die bemarkingspan, met behulp van teeblare en ander okkultiese praktyke, bepaal of die kliënt “potensieel betekenisvol” is (waarvoor, volgens interne regulasies, “tot 48 uur”). As dit nie is nie, word die adres by 'n ander tabel gevoeg en teruggestuur na Indië om 'n ander SQL-navraag uit te voer.
As bemarking 'n kliënt as "betekenisvol" geïdentifiseer het, word hulle handmatig 'n brief gestuur soos "Is jy seker jy wil regtig uitteken?" Dit lyk of dit outomaties gegenereer word, maar in werklikheid is dit nie.
As hulle “ja” antwoord (aanvanklik was dit nodig om “JA” in hoofletters te skryf), dan stuur die span van Swindon hulle na Indië derde tabel en daar word die volgende skrif plegtig uitgevoer.
As ek reg onthou, neem dit gemiddeld vier werksdae. Gemiddeld teken ongeveer 700 mense per dag uit, waarvan 70% "potensieel betekenisvol" is.
Terloops, hierdie twee Indiërs het na ons ontwikkelingspan oorgeplaas en PM's geword vir die stelsel wat al hierdie nonsens vervang het. Hulle was die vriendelikste, mees deernisvolle en hardwerkende mense met wie ek die plesier gehad het om saam te werk. Dit was aan hulle te danke dat hierdie nagmerrie-korporatiewe proses al die jare so “glad” gewerk het. Later het hulle na Engeland verhuis en een van hulle bestuur nou 'n departement met 40+ werknemers.
Vertaler se nota: uil op KDPV - .
Bron: will.com