Software maakt mensen krankzinnig

Niet in de zin van "elke dertig minuten je handen wassen zoals Howard Hughes", maar eerder in hoe de omstandigheden rondom software opmerkelijk effectief lijken in het ervoor zorgen dat anders normale mensen hun gevoel voor proportie verliezen.

Ik heb dit vaak genoeg vanuit verschillende hoeken zien gebeuren, waardoor ik niet denk dat het puur een persoonlijkheidsprobleem is. Software combineert snelheid, geld, complexiteit, abstractie en een bijna onbeperkte vrijheid om van gedachten te veranderen. Los van elkaar zijn die zaken perfect beheersbaar, maar combineer je ze, dan krijg je enkele zeer bizarre bijwerkingen.

De meeste software is, als je de branding en architectuurdiagrammen weghaalt, opmerkelijk saai. Een formulier hier, een API-endpoint daar, een snufje permissies, berekeningen, workflows en ergens een database. Misschien een wachtrij (queue) als je iets moet schalen (of als je avontuurlijk bent).

Maar, hoe hard het ook klinkt: de meeste software is nog steeds gewoon een opgepoetste spreadsheet.

De illusie van kosteloze wijzigingen

En toch kan het proces van het produceren van dit spul volwassen mensen veranderen in b-lijst Bond-schurken. Het project gaat nooit snel genoeg, het plan moet altijd flexibel zijn voor plotselinge wijzigingen, en elke nieuwe functie is dé functie die het verschil gaat maken (maar zeker niet die functie die tijdens de vorige sprint als dé functie werd bestempeld).

Er is altijd een nieuwe zorg over of het wel zal werken, of het zal schalen, of we wel snel genoeg gaan, of dat we misschien iets heel anders zouden moeten doen.

Het vreemde aan software is dat veel van deze ideeën technisch mogelijk zijn. Dat is juist onderdeel van het probleem: er is zeer weinig natuurlijke wrijving tussen een idee en de implementatie ervan. Als je een huis bouwt en iemand besluit halverwege de ruwbouw dat de keuken aan de andere kant van het gebouw moet komen, begrijpt iedereen onmiddellijk dat die beslissing een prijs heeft. Planken zijn gezaagd, leidingen zijn gelegd, en mensen moeten dingen die al vaststonden weer afbreken. De kosten zijn fysiek genoeg dat niemand kan doen alsof ze niet bestaan.

Bij software verbergen die kosten zich in de hoofden van mensen en in systemen die doorgaans al moeilijk te overzien zijn. De keuken verplaatsen in software lijkt misschien een "simpele fix". Het werk is nog steeds kostbaar, maar de werkelijke uitgaven hopen zich stilletjes op. Ergens tussen het wisselen van context, het risico op regressie en architecturale erosie vinden we verloren momentum, vergeten aannames en eindeloze vergaderingen om "op één lijn te komen".

Ongeacht de werkelijke complexiteit is het makkelijk om te doen alsof de wijziging gratis was, omdat er geen zichtbaar stof of puin is. Het probleem wordt verergerd door het feit dat het wijzigen van software inderdaad goedkoop kan zijn... soms.

Een nuttige aanpassing kan echt een uur duren, terwijl een ander, even simpel lijkend verzoek door een heel systeem kan rimpelen en storingen kan veroorzaken. Die ondoorzichtigheid creëert een gevaarlijke gewoonte waarbij elk "cool idee" dat "super snel" kan worden gerealiseerd, aan de roadmap wordt toegevoegd, vaak met grote urgentie.

Van "kunnen" naar "moeten"

Iemand heeft een idee in een vergadering en er is vaak zeer weinig weerstand tussen het idee en de realiteit. Kunnen we dit scherm anders laten werken? Kunnen we het businessmodel veranderen, een ander klantsegment aanboren, een andere workflow introduceren of ons eigen event-systeem bouwen?

Het antwoord is bijna altijd een variatie van: "Zeker, dat kunnen we."

Uiteindelijk wordt "kunnen" "zouden moeten", en "zouden moeten" wordt "waarom is het nog niet af?". Dit is waar software iets vreemds begint te doen met het menselijk brein. Alles wordt urgent omdat alles snel kan bewegen, en elke beslissing begint strategisch aan te voelen omdat de theoretische upside enorm kan zijn.

Elke technische keuze wordt ook ideologisch, omdat er tientallen plausibele manieren zijn om hetzelfde probleem op te lossen. Elke vertraging begint te lijken op een crisis, omdat ergens anders iemand anders (vermoedelijk) sneller gaat. De industrie heeft zeer weinig natuurlijke mechanismen die mensen vertellen wanneer het genoeg is.

De afwezigheid van "klaar"

Er bestaat geen echt duidelijke definitie van "klaar" in software. Een timmerman legt uiteindelijk de hamer neer omdat de kast er staat, maar software kan altijd worden verbeterd.

• De knop zou beter kunnen;
• de query zou sneller kunnen;
• de abstracties zouden cleaner kunnen;
• de onboarding zou meer mensen kunnen converteren;
• de infrastructuur zou verder kunnen schalen.

Het product zou kunnen uitbreiden naar een aangrenzende markt, de prijsstelling zou kunnen veranderen, of het hele bedrijf zou kunnen besluiten dat het een lucratievere richting heeft ontdekt. Het punt is: als je wilt, is er altijd een andere hendel binnen handbereik.

Ik denk dat dit een reden is waarom softwareorganisaties zo neurotisch worden: ze zijn omringd door hendels, en mensen die omringd zijn door hendels beginnen uiteindelijk aan die hendels te trekken. Soms doen ze dat omdat er echt iets mis is. Andere keren doen ze dat uit angst, omdat het bestuur groei wil, omdat een concurrent iets heeft gelanceerd, omdat de cijfers deze maand gelijk bleven, of omdat niemand weet wat anders te doen.

Een oprichter die elke paar dagen van richting verandert, wordt geromantiseerd als iemand die "reageert op de markt". Een manager die mensen constant onder druk zet om sneller te gaan, wordt gezien als "execution focused", terwijl een engineer die verschillende nieuwe infrastructuurcomponenten introduceert, geprezen kan worden om het nadenken over schaalbaarheid. Een productteam dat een werkende interface herbouwt omdat de conversie iets is gedaald, is aan het "itereren", en een bedrijf dat zijn oorspronkelijke identiteit opgeeft omdat een andere categorie plotseling modieus is, is aan het "pivoten".

Een deel van dit taalgebruik bestaat omdat de onderliggende motivatie legitiem is. Er zijn momenten waarop je snel moet bewegen, momenten waarop je moet pivoten en momenten waarop de architectuur echt moet veranderen. Wat software gevaarlijk maakt, is hoe makkelijk het is om het bestaan van een mogelijke actie te verwarren met de noodzaak om die actie daadwerkelijk uit te voeren.

De rol van geld en complexiteit

En alsof dit nog niet erg genoeg was, giet geld olie op het vuur. Er zijn zeer weinig industrieën waar een kleine groep mensen in een kamer kan zitten, een paar jaar kan typen (of tegenwoordig: agents kan aansturen), en plausibel iets kan produceren dat honderden miljoenen dollars waard is. Die mogelijkheid verandert het emotionele gewicht van wat traditioneel als alledaags werk wordt beschouwd.

Je kunt redelijke mensen een uur lang discussiëren over een knop zien, omdat ergens diep in het gesprek die knop is verbonden met een toekomstige stapel geld. Zodra dat gebeurt, wordt het normale gezonde verstand overboord gegooid. Het werk gaat niet meer over de vraag of de knop aan iets nuttigs is gekoppeld, maar draagt het gewicht van alles wat mensen hopen dat het bedrijf zou kunnen worden.

Complexiteit stroomt naar binnen om dat gat te vullen. Software is ongewoon goed in het ervoor zorgen dat complexiteit belangrijk aanvoelt, omdat gecompliceerde systemen gewone problemen serieuzer doen lijken. Een saaie applicatie die records in een database opslaat en mensen toestaat deze te bewerken, klinkt niet bijzonder indrukwekkend. Een gedistribueerd, event-driven platform met een service mesh en een real-time synchronisatielaag klinkt echter alsof je NORAD aan het bouwen bent.

Soms heb je dat gecompliceerde ding echt nodig. De meeste tijd waarschijnlijk niet. Maar gecompliceerde systemen bieden psychologische beloningen die simpele systemen niet bieden. Ze geven mensen dingen om te ontwerpen, over te debatteren, te bezitten, te optimaliseren, te herschrijven, in diagrammen te vatten, te benchmarken en over te praten.

Complexiteit creëert werk en werk creëert een aura van belangrijkheid. Belangrijkheid creëert status, en voor je het weet bestaat het systeem gedeeltelijk om de organisatie te ondersteunen die gedeeltelijk bestaat om het systeem te ondersteunen. Het geheel wordt zelfversterkend op een manier die verrassend moeilijk op te merken is van binnenuit.

De drang om de realiteit te "debuggen"

Ik vermoed dat er ook een diepere aantrekkingskracht onder alles dit ligt. Software geeft ons een ongebruikelijke hoeveelheid controle, omdat code een van de weinige plekken is waar je kunt beschrijven wat je wilt met voldoende precisie en een machine deze instructies betrouwbaar laat opvolgen. De rest van de realiteit is veel minder coöperatief.

De realiteit is rommelig en koppig, terwijl software ons de indruk geeft dat rommeligheid — technisch of conceptueel — een probleem is dat wacht om gedebugged te worden.

Dus beginnen we ook alles rondom de software te debuggen:

• De groei is traag, dus we veranderen de funnel;
• klanten zijn in de war, dus we herontwerpen het product;
• de ontwikkeling is traag, dus we veranderen het proces;
• het proces is traag, dus we veranderen de tools.

Het bedrijf heeft het moeilijk, dus reorganiseren we het, en als het nog steeds moeilijk heeft (en afhankelijk is van durfkapitaal), pivoten we misschien. Er is altijd een andere variabele om te manipuleren.

Uiteindelijk begint het bedrijf zelf als software te worden behandeld: permanent veranderbaar, permanent onvoltooid en permanent één refactor verwijderd van het correct werken. Dit is waar de waanzin echt toeslaat, omdat niemand iets met rust kan laten.

De kunst van het niets doen

Dingen met rust laten is een onderschatte engineering-vaardigheid. Er is een punt in je carrière waarop je begint te begrijpen dat een verrassend hoeveelheid goed werk voortkomt uit het weigeren om dingen aan te raken die hun werk al doen. De database hoeft niet altijd vervangen te worden, het framework is vaak prima en de onboarding heeft deze week geen nieuwe redesign nodig.

De architectuur hoeft geen miljard gebruikers te voorzien, en de roadmap hoeft niet te veranderen omdat iemand enthousiast werd van een tweet. Het product hoeft geen platform te worden, en het bedrijf hoeft niet elk kwartaal zijn identiteit te herontdekken. Soms moet iets gewoon daar staan en werken.

Klanten hebben vaak tijd nodig om een product te vinden, engineers hebben tijd nodig om een systeem te begrijpen en bedrijven hebben tijd nodig om bedrijven te worden. Niets hiervan klinkt bijzonder diepzinnig, maar de softwarecultuur is opmerkelijk vijandig tegenover geduld. Geduld ziet er verdacht veel uit als inactiviteit, en inactiviteit is moeilijk te rechtvaardigen in een industrie die geobsedeerd is door snelheid (velocity).

Dus creëren we activiteit in plaats daarvan. We releasen, itereren, optimaliseren, pivoten, herplatformen, heroverwegen en heruitvinden totdat het oorspronkelijke probleem nauwelijks nog zichtbaar is onder alles wat we erbovenop hebben gestapeld. Dan, een paar jaar later, stelt iemand zachtjes voor om het oorspronkelijke simpele ding opnieuw te bouwen (vaak wijzend naar hun eigen zelfvoldane wijsheid als het leidende licht dat dit inzicht mogelijk maakte).

Ik denk niet dat het antwoord is om langzaam te bewegen om het langzaam bewegen. Dat zou gewoon weer een andere ideologie zijn, en software heeft er al genoeg. Het antwoord is proportie.

Dit betekent begrijpen dat niet elk probleem existentieel is, niet elk idee op de roadmap thuishoort en niet elke abstractie het verdient om te bestaan. Het betekent accepteren dat niet elke vertraging interventie vereist, niet elke concurrent ertoe doet en niet elk stuk software een platform moet worden. Het betekent ook onthouden dat niet elk bedrijf naar wereldheerschappij hoeft te streven.

Ik herhaal: de meeste software is, ondanks alle versieringen, nog steeds een opgepoetste spreadsheet. Dat is niet bedoeld als belediging. Spreadsheets zijn nuttig en (daadwerkelijk) nuttige software is genoeg.

Maar misschien zouden we allemaal wat gezonder zijn als we ons herinneren wat we eigenlijk doen: tools bouwen om ons leven en het leven van anderen gemakkelijker te maken. Niet wegkwijnen in Margaritaville door te prutsen met dingen die geen geprutsel nodig hebben.