Die onsigbare magte wat jou kode beïnvloed

Deur Stephan Swart, adviesraadslid van die Solidariteit IT-netwerk

Stel jou voor, ʼn bedrywige hospitaalsaal waar verpleegsters vinnig en doelgerig beweeg, medisyne noukeurig nagaan, pasiëntkaarte bywerk en prosedures perfek uitvoer. Vir die toevallige waarnemer lyk alles ordelik en doeltreffend. Tog lê daar onder hierdie georkestreerde chaos en choreografie ʼn onsigbare spanning en ʼn diepgewortelde emosionele verdediging.

Isabel Menzies Lyth: Sosiale verdedigings in verpleging

In 1959 met ʼn baanbrekerstudie het die psigoanalis Isabel Menzies Lyth iets diepgaande onthul. Weens daaglikse konfrontasie met siekte, lyding en dood, het verpleegsters onbewustelik ingewikkelde roetines ontwikkel—nie hoofsaaklik om pasiëntsorg te verbeter nie, maar om hulself emosioneel te beskerm. Hulle het pasiënte ontpersoonlik en sielkundige hindernisse geskep deur byvoorbeeld na ʼn pasiënt te verwys as “die lewer in bed 10” eerder as om die pasiënt op sy of haar naam te noem. Hulle het rolle gefragmenteer in herhalende take, byvoorbeeld een verpleegster wat herhaaldelik bloeddruk van verskeie pasiënte neem eerder as om een pasiënt volledig te versorg. Hulle het buitensporige “rituele” rondom alledaagse take geskep wat enige emosionele verbintenis met pasiënte of kreatiewe denke voorkom het. Hierdie was nie net persoonlike hanteringsmeganismes nie, maar sosiale verdedigings (“social defenses”), diep ingebed in organisatoriese kultuur.

Hierdie verdedigings het egter uiteindelik negatief teruggekap. Verpleegsters het emosioneel onbetrokke geraak, die moraal het versleg, personeelomset het toegeneem en ironies genoeg het pasiëntsorg daaronder gely. Erger nog, pogings om die situasie te verbeter het misluk—nie weens ʼn gebrek aan voorneme nie, maar omdat die strukture wat bedoel was om te beskerm, te rigied geword het om te verander.

Alistair Bain: Stelseldomeinverdediging (‘System Domain Defenses’)

Om voort te bou op Menzies se bevindinge, het Alistair Bain die konsep van “system domain defenses” bekendgestel. Bain het aangevoer dat volhoubare verandering in ʼn organisasie byna onmoontlik is as soortgelyke organisasies of industrieë onveranderd bly. Hierdie domeinvlakverdedigings versterk kollektiewe angs, en dwing organisasies om terug te keer na vorige toestande, tensy daar breër verandering binne hul gemeenskappe of industrieë plaasvind. 

As ʼn fraksionele hooftegnologiebeampte en konsultant bestudeer ek hierdie onsigbare dinamika al vier jaar lank, en het ek besef hoe soortgelyke onbewuste verdediging sagtewarespanne en -praktyke vandag subtiel, maar kragtig vorm. Neem byvoorbeeld die angs wat tans die tegnologie-industrie aangryp weens die vinnige vooruitgang van KI en onsekerheid oor werksekuriteit. Sulke angste aktiveer soortgelyke “system domain defenses” wat manifesteer deur gedeelde rituele, gevestigde prosesse en weerstandige argitekture.

Herkenning van versteekte sosiale verdedigings in sagteware

Sagterwarespanne, net soos verpleegsters, ontwikkel verborge roetines om druk te hanteer soos streng sperdatums, verantwoordelikheidsvrese en aflewerings van hoë-belang. Kom ons kyk na scenario’s wat hierdie onbewuste verdediging illustreer:

CAB-vergaderings en sleutelrolle as sosiale verdedigings

Een van die mees frustrerende vergaderings wat ek beleef het, is die CAB-vergadering (‘Change Advisory Board’). Aanvanklik lyk CAB- of ARB (‘Architecture Review Board’)-vergaderings logies en voordelig—kundiges kom bymekaar om besluite te beoordeel, risiko’s te bestuur en chaotiese prosesse te formaliseer. Baie organisasies sien hierdie forums as simbole van volwassenheid. Tog gaan hierdie strukture soms meer oor die bestuur van angs as oor effektiewe besluitneming.

Die kompleksiteit en spoed van moderne tegnologiese werk beteken geen enkele komitee kan alle veranderlikes beheer nie. Werklike besluitneming gebeur dikwels lank voor die formele hersiening. Tog duur hierdie vergaderings voort omdat hulle veiligheid bied.

Vir leierskap bied CAB’s en ARB’s gerusstelling: “Ons het dit nagegaan.” “Die proses is gevolg.” Vir ontwikkelaars en projekleiers is daar die gerief: “Hulle het dit afgeteken.” Hierdie vergaderings word plekhouers vir kollektiewe ongemak wat almal toelaat om verantwoordelikheid te eis sonder om werklik betrokke te raak by onsekerhede of teenstrydighede.

“Enterprise Architects” en “Release Managers”

Sekere rolle soos ʼn “Enterprise Architect” of “Release Manager” funksioneer soortgelyk. Hulle dra simboliese gewig as handhawers van samehang en standaarde. Hoewel opreg en vaardig, kan hierdie rolle weerligafleiers word vir angs oor fragmentasie en onvoorspelbaarheid. Deur die “las van duidelikheid” aan een rol toe te ken, onteien die res van die stelsel gedeelde verantwoordelikheid. 

• • As iets verkeerd loop, is dit die argitek se skuld.
• • As ʼn vrystelling misluk, het die “Release Manager” iets gemis.
• • As ʼn verandering produksie verbreek, was die CAB verantwoordelik.

Almal voel verantwoordelik, maar vreemd genoeg ook onbetrokke. Die onbedoelde gevolg is dat hierdie strukture die stelsel se vermoë om te leer, aan te pas en kollektief te dink, verswak.

Burokrasie as emosionele verdediging

Stel jou voor ʼn ontwikkelaar met ʼn goeie idee. In plaas daarvan om dit te bou, jaag hulle toestemming na, wag vir goedkeurings en beweeg deur huiwerige departemente. Dit voel soos burokrasie, maar dis nog ʼn sosiale verdediging—departemente beskerm hulleself teen moontlike blaam, verlies aan beheer of vrees vir blootstelling. Hulle vertraag prosesse, versoek meer dokumentasie, nie noodwendig omdat dit nodig is nie, maar omdat dit veiliger voel. Die onbedoelde gevolg: samewerking neem af, vertroue verflou en belowende idees word begrawe. Die organisasiesisteem prioritiseer stilweg veiligheid bo vooruitgang.

Digitale transformasie en bestuur van angs

Terwyl ek aan ʼn digitale transformasieprogram binne ʼn groot internasionale organisasie gewerk het, het ek gesien hoe leierskap, na implementering van Agile, DevOps en Design Thinking, meer matrikse en voldoeningseise begin versoek het. Aanvanklik was hierdie versoeke sinvol en het dit sigbaarheid en beheer gebied. Tog het hierdie vereistes oor die tyd heen vooruitgang vertraag. Die dieper besef: hierdie vereistes het nie oor die bestuur van werk gegaan nie, maar eerder oor die bestuur van angs. Organisasieverandering wek ongemak—risiko, relevansie, verlies aan beheer, vrees aan blootstelling. Leierskap het onbewustelik gesteun op rasionele en meetbare hulpmiddels wat ʼn gevoel van beheer geskep het, sonder om werklike kompleksiteit aan te spreek. Nog ʼn sosiale verdediging. Die onbedoelde gevolge:

• • Mense het gevoel hulle word gemikrobestuur of wantrou.
• • Innovasie het vertraag, met ʼn oormatige fokus op verslagdoening.
• • Werklike gesprekke oor kultuur, vertroue en samewerking is opsy geskuif.
• • Die organisasie het ʼn muur van spreiblaaie gebou teen emosionele realiteite.

Conway se Wet en argitektoniese spieëling

Melvin Conway het verduidelik: “Organisations that design systems […] produce designs mirroring their communication structures.” Conway se Wet verduidelik waarom enige sagtewarestelsel onvermydelik die kommunikasiestruktuur van die organisasie wat dit bou, weerspieël. Werklike voorbeelde sluit in:

1. 1. Unix Operating System – Bekend vir sy skoon, modulêre ontwerp wat sy verspreide spanstruktuur weerspieël. Unix is ontwikkel deur klein, los-verbonde groepe wat afstandswerk gedoen het of duidelike grense gehandhaaf het. Kommunikasie was beperk, wat gelei het tot sagteware wat gebou is sonder “tight coupling”, wat elke gereedskap toegelaat het om onafhanklik te funksioneer.
2. 2. Amazon se Microservices – Amazon organiseer lukrake klein, outonome “two-pizza teams”, elkeen verantwoordelik vir ʼn diens “end-to-end”. Hierdie outonomie vertaal direk in Amazon se argitektuur: ʼn wye netwerk van onafhanklike mikrodienste wat via API’s kommunikeer.
3. 3. Klein span met ʼn Monolith – ʼn “Monolithic architecture” pas by klein “start-ups” waar voortdurende kommunikasie maklik is. Soos spanne groei en verspreid raak, ontstaan kommunikasiehindernisse, wat veroorsaak dat monolitiese stelsels onder druk kom en koördinasieprobleme ontwikkel. Kommunikasie vorm sagteware, maar oor tyd verhard sagteware-argitektuur en begin kommunikasie terug vorm. Die argitektuur wat ons vandag skep, bepaal die spanne en strukture wat ons môre kan handhaaf. Hierdie beperkings kan organisatoriese rigiditeit versterk, en ʼn bose siklus skep tensy dit bewustelik aangespreek word.

Tegnologiese skuld en organisatoriese angs

Kom ons oorweeg nog ʼn voorbeeld: tegnologiese skuld (“technical debt”). Tegnologiese skuld bou dikwels stilweg op wanneer onuitgesproke angste prioriteite vorm. Ek het eens met ʼn kliënt gewerk waar hierdie opbou gewoonlik begin het met ʼn sperdatum. Toe ons dieper ondersoek ingestel het, was die rede agter die sperdatum vaag, maar die emosies daar rondom was intens en eg. Almal het druk ervaar om die datum te haal. Ontwikkelaars sou stilweg noem dat hulle kortpaaie neem. Bestuurders het stilweg ander kant toe gekyk. Almal het geweet daar sal ʼn prys betaal word, maar die angs om die sperdatum te mis, of om gesien te word as die persoon wat die vertraging veroorsaak het, was te swaar om te dra. Daarom het almal stilweg saamgewerk en die “technical debt” het opgehoop sonder om ooit die koste daarvan te noem.

Hierdie kultuur verseker stadiger aflewering. Selfs ervare ontwikkelaars vind dit makliker om te onttrek eerder as om terug te druk teen die stelsel. Die argitektuur wat hieruit ontstaan, word ʼn gevreesde “ball of mud”. Geen konsekwente patrone, besigheidslogika wat deurmekaar raak met die gebruikerskoppelvlak (‘front-end’), en soms praat die “front-end” direk met die databasis. Die stelsel lyk soos iets wat deur amateurs saamgestel is.

Dié siklus herhaal homself oor en oor in organisasies. Hierdie gedrag word versterk deurdat universiteite selde kernpraktyke soos eenheidtoetsing (“unit testing”), die bestuur van “technical debt” of deurlopende integrasie leer.

Praktiese aksies

So, waar laat dit ons dan? Ten spyte van hoe diepgewortel hierdie patrone mag voel, is ware transformasie moontlik. Maar dit gaan nie oor vinnige oplossings of “silver-bullet frameworks” nie. Dit gaan oor die stadiger, meer dapper werk om te konfronteer wat dikwels versteek bly – veral ons angste en die gedrag deur die stelsel heen wat dit beskerm.

Hier is hoe dit in die praktyk kan lyk:

• • Praat oor dít wat niemand bespreek nie
  Breek die stilte oor dinge soos “technical debt”, uitbranding of onrealistiese sperdatums. Hierdie gesprekke kan aanvanklik ongemaklik voel, maar hulle werp lig op die emosionele onderstrominge wat ons besluite vorm. En met lig kom die moontlikheid van verandering.
• • Deel stories met ander in die veld
  Jy is nie alleen nie. Baie ander navigeer dieselfde spanninge. Om met vakgenote te verbind en te deel wat gewerk het (en wat nie), bou kollektiewe krag. Dit begin om die greep van verouderde norme los te maak en versprei gesonder patrone oor spanne, afdelings en selfs industrieë.
• • Hou aan leer; hou aan onderrig
  Praktyke soos eenheidtoetsing, “refactoring” en bestuur van “technical debt” is nie net tegniese vaardighede nie. Dit is dade van sorg. Hulle daag die stelsel se neiging tot korttermynfokus en ineenstorting uit. Hoe meer ons hierdie gewoontes integreer, hoe beter rus ons spanne toe om weerstand te bied teen die druk om hoeke af te sny net om te oorleef.

Net deur hierdie teks te lees, nuuskierig te bly en op jou eie ervaring te reflekteer, is jy reeds deel van die skuif na ʼn beter toekoms. Jy help om dit te benoem wat dikwels naamloos bly.

En ja, hierdie werk is moeilik. Dit is makliker om saam te speel. Maar die alternatief is meer stilte, meer vermorste potensiaal, en meer stelsels wat onder hul eie gewig ineenstort.

Hou dus aan as jy kan. Hou aan opmerk. Hou aan praat as jy die ruimte het om dit te doen selfs al is dit ongemaklik. Want elke keer wat jy dit doen, kap jy aan ʼn patroon wat bloot sê: “Dis hoe dit is.”

En stadigaan, mag die stelsel begin onthou dat dit anders kan wees.

---

Bronne:

• • Menzies Lyth, I. (1960). A case-study in the functioning of social systems as a defence against anxiety. Human Relations, 13(2), 95–121.
• • Bain, A. (1998). Social defenses against organizational learning. Human Relations, 51(3), 413–429.
• • Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

---

Stephan Swart is ʼn fraksionele hooftegnologiebeampte (“Fractional CTO”) en tegniese leierskapsafrigter met jare se ervaring in sagtewareontwikkeling, “agile”-spanbou en organisatoriese groei. Hy help spanne en besighede om tegnologie slim te gebruik, leierskap te versterk en volhoubare, selforganiserende spanstrukture te vestig. Sy kundigheid strek oor verskeie platforms en programmeertale, en sy fokus is altyd op mense, potensiaal en praktiese resultate.