Agile Stonehenge

OLYMPUS DIGITAL CAMERA
Photo by garethwiscombe

Voormalig Astronomer Royal Sir Fred Hoyle heeft ooit een boekje geschreven over Stonehenge. Hij vroeg zich af waar de grote stenen van Stonehenge ooit voor gediend hebben. We weten dat de kleinere stenen die wat verder verwijderd staan van de grote stenen in het midden, een zonnewijzer waren waarmee de druïden konden voorspellen wanneer de dagen weer gingen lengen en het voorjaar dus weer in aantocht was. Zijn verklaring voor de grote stenen in de kring is de volgende.

De oude druïden hadden ontdekt dat op de korste dag, de zon altijd op hetzelfde punt aan de horizon onderging. Door dat punt te markeren, en in de winter de ondergang van de zon in de gaten te houden, konden ze de kortste dag precies voorspellen. Dat was belangrijk voor de priesters, want dan konden ze het volk melden “ook dit jaar zal de winter weer plaats maken voor het voorjaar!”. Ze markeerden het punt aan de horizon met twee enorme stenen, als een soort wijzer. Die stenen moesten groot zijn opdat de koeien of de najaarsstormen ze niet verschoven. Die priesters werden in de loop der eeuwen best wel handig in het voorspellen van de midwinter zonnewende. In de theorie van Hoyle gingen ze de zonnewende naspelen met kleine steentjes, en door de dagen te tellen konden ze na verloop van tijd de winter-zonnewende voorspellen zonder naar de grote stenen te kijken.

Eeuwen gingen voorbij, misschien wel een millennium. Toen ging er iets mis met het model van de priesters, de aard-as wentelt immers een beetje, de berekeningen klopten niet meer, en het volk raakte in panier omdat de priesters niet meer goed in staat waren te voorspellen dat er ook dit jaar na de winter weer een voorjaar zou volgen. De kennis van de grote stenen bij het punt aan de horizon was in die eeuwen natuurlijk verloren gegaan. Wat nu? Er was wel de overlevering, van de oude priesters die de goden gunstig stemden om het voorjaar te laten terugkeren. Iemand opperde “het was iets met hele grote stenen”. En dus werden grote stenen gehaald uit Wales, veel groter dan de oorspronkelijke stenen want als je te weinig kennis heb compenseer je dat door de stenen groter te maken. Natuurlijk hebben die nieuwe stenen niet geholpen om de goden gunstig te stemmen, of misschien ook wel, het voorjaar kwam immers ieder jaar gewoon weer terug.

Of Hoyle gelijk heeft, ik weet het niet, de archeologen die meer verstand hebben van de oude tijden hebben heel andere ideeën over Stonehenge dan de Astronomer Royal, maar het is een mooi verhaal.

Ik denk wel eens aan Fred Hoyle als ik in den Scrum meeting zit, of in een “daily standup”. Iemand wilde de performance van software ontwikkelteams verbeteren, herinnerde zich de briljante high performance teams waarin hij of zij ooit had gewerkt, herinnerde zich de koffie die ze in de ochtend samen dronken, staande bij de koffiemachine, en dacht toen “het was iets met ‘s ochtends in een kringetje staan”. Daarbij over het hoofd ziende dat dat kringetje ‘s ochtends een gevolg was van de werkwijze van het team, een symptoom, en niet een oorzaak. Een high performance software team doet het zo goed omdat de leden elkaar perfect aanvoelen, steeds overleggen, steeds samen aan code werken, ook als het uitkomt dagenlang alleen aan code werken, omdat ze elkaar vertrouwen en tegelijk elkaar op de vingers kijken. Ze reviewen elkaars code, ze doen suggesties, ze leren van elkaar, ze delegeren aan elkaar, en aan het eind van de dag hebben ze een berg software gemaakt van hoge kwaliteit waar ze zichzelf allemaal in herkennen. ‘s Morgens in een kringetje bij elkaar staan gaat vanzelf, omdat er goede koffie is, omdat je elkaar al zeker 12 uur niet hebt gezien, omdat je wilt vertellen wat je gisteravond hebt gedaan, en o ja, omdat je een collega wilt vragen vandaag even met je mee te kijken naar een nieuw stukje software dat je gaat maken. Of omdat je wilt aankondigen dat je vandaag wilt laten zien wat je de afgelopen twee weken hebt gemaakt.

Een “sprint” is ook zoiets. Als je een lijst met features hebt die gemaakt moeten worden (een “backlog”) dan ligt het voor de hand om steeds als je iets af hebt, een nieuw item van de lijst te nemen en daarmee aan de slag te gaan. Het ligt ook zeer voor de hand om periodiek een oplevering van je product te doen. Vroeger deden we dat door periodiek te zeggen “wat nu af is, zit in de komende release”. Wat er dan in de release zat op 18 februari, nou, dat was wat er op 18 februari toevallig af was. Hetzelfde voor 23 juli. En natuurlijk zei je dan “oh, wacht, ik maak dat nog even af, dan kan het nog net mee met de komende release”. En dan werkte je wat avonden door. En of je nou om de drie maanden of om de twee weken een nieuwe release had, altijd zat er in de release wat er op dat moment toevallig af was.

De eerste release duurt natuurlijk langer. Als je een systeem bouwt en je gaat daar een jaar over doen, dan kun je natuurlijk niet na twee weken een eerste werkende versie hebben, net zo min als dat je een huis bouwt en twee weken na het begin van de bouw kun je al in een stukje ervan wonen, of je bouwt een auto en na montage van het eerste wiel kun je al een proefritje maken. Maar iemand zegt dan “het was iets met periodieke releases” en dan richt je je project in met releases om de twee weken en je eist dat na iedere sprint er een werkend product is. Waardoor alle inspanning in de eerste twee weken erop gericht is om in twee weken “iets werkends” op te leveren en niet, zoals zou moeten, erop gericht is om aan het eind van het gehele project het beste product op te leveren.

Ik heb in de loop der jaren in heel wat Scrum teams meegedaan, en ik heb het idee dat Scrum van het middel het doel is geworden. Dat bij managers het idee heeft postgevat dat als we nou maar iedere ochtend even in een kringetje staan en om de week met genummerde kaartjes over tafel gooien en genoeg gele briefjes op een whiteboard hangen of genoeg subtasks in Jira heen en weer schuiven, dat we dan een high performance team zijn en dat we dan efficiënt en effectief werken.

Ik zou zeggen, laten we ons nou ‘s wat minder laten leiden door de boekjes en de theorie en wat meer kijken naar het resultaat van wat we doen.

Het einde van XS4ALL

 XS4ALL ontstond in 1993 vanuit Hacktic, het hackers blad van Rop Gongrijp en anderen. Op de HEU conferentie, Hacking at the End of the Universe, waren de ideeën ontstaan om De Digitale Stad op te richten, XS4ALL deed daarin mee en XS4ALL groeide begin 1994 snel mee met DDS. Waar je in januari ’94 nog abonnee werd bij Hacktic, de provider werd al snel onder een aparte naam afgesplitst: XS4ALL.nl. Het bleef een hackers-vrienden-groepje, met mensen die gemeen hadden dat ze weinig of geen ervaring hadden met “echte bedrijven”. Dat werkte wonderlijk goed, de service van Xs4all was prima, de chaos was groot, en alles werkte perfect. Felipe Rodriguez was vanaf het begin de directeur, en als ondernemer was hij ook in staat de aanschaf van servers te financieren. Xs4all had immers heel snel heel veel servers nodig. Dat waren toen geen eenvoudig linux intel machines, maar Sun servers, voor iets van een ton per stuk.

Voor de klanten van het eerste uur was support eenvoudig. Je mailde naar Jan-Pieter of je sprak Cor aan op IRC, en je probleem werd opgelost waar je bij zat. Thuiswerken was voor personeel eenvoudig: ze kregen een huurlijn waardoor ze permanent online waren thuis – wat in die tijd verre van gebruikelijk was. Voor het meldpunt had ik ook zo’n Xs4all huurlijn: de KPN monteurs keken me spottend aan, hoe ik nu een 1200 bps modem kon willen als er ook al 56k modems waren. Ik heb vriendelijk geglimlacht. Je kon via zo’n “1200bps lijn” ook snelle modems aansluiten, en later zelfs baseband modems, met megabits/sec. Maar dat wisten ze bij KPN toen natuurlijk niet.

Het was allemaal heel mooi, iedereen was blij, maar met een groepje vrienden een steeds groter bedrijf runnen met steeds meer klanten, veel meer medewerkers, en steeds meer concurrentie, ging een beetje knellen. Ik begrijp dat de oprichters hun bedrijf in dat stadium verkocht hebben. Felipe vond het moeilijk, Ik denk de anderen ook, eigenlijk. Dat is waarom ze bedongen hebben dat XS4ALL onder eigen naam als zelfstandig bedrijf mocht blijven bestaan, met super dienstverlening en met behoud van het sponsoren van diverse maatschappelijke doelen. Er was veel kritiek, met name vanuit de mensen van het eerste uur, die riepen “hoe kun je dat nou doen” en anderen die kwaadaardig zeiden “ze gaan voor het grote geld”. Ik weet zeker dat XS4ALL het zonder de overname heel moeilijk gekregen zou hebben. Het was de goede keuze, in 1998.

Ik ben altijd klant gebleven, eerst met een inbel verbinding, een poosje met een huurlijn,  later met adsl. Maar in de loop van de tijd heb ik ook diensten elders ondergebracht. De hosting bleek bij een ander toch meer dan de helft goedkoper, zeker als je ruimte in een 19″ rack huurde, en het DNS beheer bij XS4ALL was dan in 1994 het beste wat je kon krijgen, nu gaat dat via dnsmadeeasy.com veel handiger. Voor domeinen had je in 1994 weinig keuze, maar vijf jaar later was XS4ALL wel erg duur, en kon je per domein €50 per jaar besparen bij een domeinprovider. Een shell acount bij xs4all was heel handig, maar dat heb ik nu zelf op mijn servers in de cloud. Als KPN het merk XS4ALL nu opheft, is dat een mooie aanleiding om symbolisch ook de laatste dienst die ik afneem, de adsl, na precies 25 jaar ook elders onder te brengen.

Waarom zijn er geen groene sterren?

Sterren zijn er in alle kleuren. Alle? Nee. Er zijn blauwe, gele, oranje, rode en bruine sterren, maar geen groene. Hoe kan dat?

Een ster zendt licht uit. De kleur van dat licht hangt af van de temperatuur van de ster, net als dat de kleur van gloeiend ijzer afhangt van de temperatuur. Als je ijzer een beetje verwarmt dan begint het infrarood straling uit te zenden. Dat is licht dat je niet ziet maar wel voelt, als warmte. Stook je het ijzer iets warmer, dan zie je het als je goed kijkt donkerrood stralen. Dan is het wel te warm om beet te pakken. Als je het nog warmer stookt dan wordt het rood, oranje, geel, en dan wit. En maak je het super heet, echt super heet, dan gaat het zelfs blauwig wit licht uitstralen. Dan is het wel allang vloeibaar. Maar net als een ster, gloeiend heet ijzer is nooit groen.

De zon is geel. Dat wil zeggen, gelig wit. De temperatuur van het deel van de zon waar het licht vandaan komt (het “oppervlak”) is 6000 graden. 6000 Kelvin, dat is bij deze hoge temperatuur vergelijkbaar met Celsius. Een klein rood dwergsterretje heeft een termperatur van rond 3500 Kelvin. Is het sterretje nog kleiner, dan is het nog “koeler”, voor zover je 3000 graden “koel” kunt noemen. Een klein sterretje is niet zo heet omdat het na de geboorte als grote gaswolk wel door de zwaartekracht samentrekt en opwarmt en tenslotte misschien kernfusie gaat doen, maar te weinig om echt uit de band te spatten, kwa temperatuur. Een heel zware ster stort zodanig in dat de temperatuur al snel oploopt zodaat kernfusie optreedt, en dat gaat zo heftig dat de temperatuur kan oplopen tot 20.000K.

Hieronder een plaatje van het door een ster uitgezonden licht voor verschillende temperaturen, als functie van de kleur. Ik heb het overgenomen van “Bad Astronomy”.

blackbody

Je ziet dat een ster met een temperatuur van 4500 Kelvin het meeste licht uitzendt in het rode licht. Ook geel, en wat groen en zelfs blauw, maar meest rood. Je oog ziet dat als rood. Aan de andere kant, een ster van 7500 Kelvin geeft het meest blauw licht. Indigo eigenlijk, het donkerder blauw. Ook ultraviolet en geel en wat rood, maar het meest blauw, en die ster interpreteert je oog als blauw. En bij 6000 Kelvin zien we.. wacht.. bij 6000K is de piek in het groen. En toch is de zon (6000K) geel, niet groen. Hoe kan dat?

Kleur is niet een fysieke eigenschap van licht, het is een artefact, iets kunstmatigs. Licht heeft een golflengte, en die kan iedere waarde hebben tussen 350nm en 750nm voor zichtbaar licht. Kleur wordt bepaald in ons oog. We zien drie primaire kleuren (rood, geel – of geelgroen – en blauw) omdat ons oog drie soorten kleurdetectortjes heeft: voor rood, geel en blauw. Zien we geel licht en rood licht, dan zegt ons oog “dat is oranje”. Zien we geel licht en blauw licht, dan maken we daar “groen” van. Deze kleurdetectortjes, de “kegeltjes” in het netvlies van ons oog, zien wel kleuren maar ze onderscheiden niet zo goed lichtsterkte. Voor lichtsterkte hebben we andere detectortjes (de “staafjes”) die veel lichtgevoeliger zijn maar die alleen zwart-wit zien. Dat merk je als het donker is en je ziet nog maar weinig: wat je ziet heeft haast geen kleur of helemaal geen kleur. Je kegeltjes zien niks meer, je staafjes zien nog wat van de wereld, in zwart-wit.

Terug naar de groene sterren. Bij hete sterren overheerst het blauw genoeg om ze blauw te laten lijken, bij “koele” sterren is er geen blauw en lijken ze rood of oranje. Een ster van 6000K zendt het meeste licht uit in het groen. Maar je kegeltjes zien genoeg rood en  blauw dat groene sterren niet groen zijn maar geel. Geen groene sterren dus.

Ik kan me overigens voorstellen dat er wel mensen zijn die groene sterren zien. Mensen die kleurenblind zijn, en die b.v. geen blauw zien, zouden hete sterren groen moeten zien. Maar omdat ze kleurenblind zijn, kunnen ze dat niet zo benoemen. Voor hun is immers groen en blauw hetzelfde.

We kunnen al die kleuren bij ons in de buurt zien, over een poosje. Als de zon nog een paar miljard jaar schijnt, dan stopt ‘ie met kernfusie omdat de waterstof op is, en dan gaat ‘ie de energie om te schijnen halen uit ineenstorting, waarbij de buitenlagen expanderen en koeler worden. De zon wordt dan een rode reus. Niet goed voor ons, want die rode reus is dan zo groot dat de aarde binnenin de zon haar rondjes gaat draaien. Is die fase voorbij, dan blijft uiteindelijk van de zon nog een heet ineengestort dwergsterretje over, wit, of misschien wat blauwig. Wij maken dat niet mee want als de aarde door de buitenlagen van de zon gaat vliegen dan hebben we hier op aarde beslist andere problemen dan global warming.

 

Waarom een senior programmeur simpele code schrijft

In mijn allereerste baan, al wel een poosje geleden, was ik programmeur. Junior programmeur zelfs, met de inkt van mijn doctoraal diploma nog nat. Ik mocht gelijk beginnen met wat nieuwe code, en ik deed mijn best. Aan het eind van de dag keek de team leider ernaar, en hij fronste. Hij zei “dat heb je wel mooi gemaakt, heel compact. Maar ik weet niet of alle externe programmeurs die hier het onderhoud doen, er heel blij mee zijn. Die zijn niet allemaal even goed opgeleid”. Dit was in de tijd dat een academische opleiding voor een programmeur nog niet de norm was. “Ik wil je vragen om het wat minder compact te maken, wat meer verboos, wat meer regels, zodat iedereen het snel begrijpt”. Ik deed wat ‘ie had gevraagd, en ik heb bij dat bedrijf, een kleine bank, nog heel veel code gemaakt.

Pas veel later begreep ik de kloe van het verhaal. Veel later, toen ik veel code had gezien die door anderen was gemaakt, goede en minder goede code, code van beginners en code van ervaren programmeurs, begon ik te zien dat die team leider wel een punt had.

Code (source code, software) is niet moeilijk te lezen, als je de taal kent. Een heel programma, of een heel systeem, doet wel een beroep op je hersencelletjes om het allemaal in één beeld te bevatten. Dat is waarom een programmeur die in een flow zit niet om zes uur naar huis gaat: het is zonde om het werk niet af te maken als de hersencelletjes het hele model van de software net mooi hebben opgeslagen. De volgende ochtend kost het weer tijd om de flow op gang te krijgen en het model weer uit te beelden in je hoofd.

Code is niet moeilijk te lezen, als ze mooi is opgeschreven, als ze zo is opgeschreven dat je er snel doorheen leest. Vaak betekent dat dat het visueel goed gestructureerd is, met genoeg open ruimte. Maar soms zijn er een paar regels waar een programmeur heeft gedacht “waarom 20 regels schrijven als het ook in één kan?” Die ene regel is dan wel heel vernuftig, maar je moet er wel een paar keer naar kijken en even nadenken voordat je ziet wat er gebeurt. Dat verstoort je leestempo. En waarom zou je code zo compact mogelijk maken? Niet voor de computer, die vertaalt je code, of ze nu compact is of ellenlang uitgesponnen, tot precies dezelfde instructies. Denk aan de handleiding van de magnetron. Je kunt die samenvatten in tien regels, of je kunt er een mooi handzaam boekje van maken. Als je snel iets wilt opwarmen, dan pak je dat boekje, en ga je niet een uur zitten puzzelen op die tien regels. Terwijl die tien regels ongetwijfeld veel “knapper” zijn.

Afgelopen jaar heb ik een project gedaan waarin ik code heb gezien van veel verschillende applicaties, gemaakt door verschillende mensen, verschillende bedrijven. Dan valt op dat je code die is geschreven volgens algemene standaarden veel sneller doorhebt. Het valt ook op dat je code die iets meer breedsprakig is, sneller leest en sneller doorhebt. Ik zeg “iets meer”, je kunt ook overdrijven. Je moet de juiste balans vinden tussen lekker compact en toch snel te lezen.

Inmiddels ben ik zo ver dat ik code meestal maar simpel opschrijf. Ik gebruik Lambda expressies omdat ze handig zijn, maar waar ze verwarrend zouden zijn, schrijf ik alles wel gewoon uit. Ik gebruik de Java stream API omdat die efficient en mooi is, maar er zijn gevallen dat de code er wat onnodig onoverzichtelijk van wordt, dan doe ik het anders. Ik schrijf code met in mijn achterhoofd “over twee jaar kijkt een nieuw iemand naar deze code, met de opdracht binnen een uur een bug te fixen”.

Ik heb soms het idee dat jonge slimme programmeurs helemaal tot het gaatje gaan in het schrijven van ultra-compacte code omdat ze denken dat ze iets te bewijzen hebben. “Ik ben goed in mijn vak als ik de laatste snufjes demonstreer en laat zien dat ik ook de laatste paar letters in mijn code kan wegwerken”. Zoals ik in mijn eerste baan dacht dat ik iets te bewijzen had, tegenover de oude rotten in mijn team. Ik zou zeggen, probeer je liever te bewijzen tegenover de mensen die na jou komen, die jouw code gaan onderhouden.

Ik probeer simpele code te schrijven. Code waarvan ik hoop dat een ander, misschien over vele jaren, in één oogopslag ziet wat het doet. Omdat ik ook vaak die “ander” ben geweest die heeft zitten puzzelen om onnavolgbaar complexe code te analyseren die uiteindelijk iets heel eenvoudigs bleek te doen.

Christine verdwaalt in De Digitale Stad

DDS2

 

Op 15 januari 1994 las ik in de Volkskrant een artikeltje van ene Francisco van Jole. Het ging over een experiment in Amsterdam, iets met internet en de gemeente Amsterdam en De Balie. Ook iets met hackers. “De Digitale Stad” heette het. Er stond een telefoonnummer bij. Ik werd nieuwsgierig en ik belde met het modem dat aan mijn laptop zat. In gesprek. Nog een keer in gesprek. Maar na een keer of vijf kreeg ik verbinding. Het geruis en gepiep dat ik kende van het inbellen op bulletin boards en op de modems van de UvA waarlangs ik normaal toegang tot internet had. Toen het lawaai stopte, verscheen er een schermpje. Ik denk dat er een schermpje kwam waarmee ik een account kon aanmaken, maar ik weet dat niet meer. Ik kwam uiteindelijk op een scherm met 10 opties (het screenshot is van later, ik kan het originele niet meer vinden). Ik zat een poosje te kijken. Ik klikte op “Een Plein”. Mijn leven is nooit meer hetzelfde geweest.

“Het Plein” was een soort chatbox. Een soort Twitter, maar dan heel anders. Teksten kwamen in rap tempo voorbij, blijkbaar ingetypt door mensen die net als ik het telefoonnummer in de krant hadden gebeld met hun modem. Ik typte “hallo”. Het spervuur van tekstjes van anderen ging gewoon door. Ik typte nogmaals “hallo”. Onmiddellijk kwam er een antwoord: “dat zei je net ook al”. Hmm. Apart. Ik deed ctrl-X en kwam weer in het menu. Nu dan maar “Het Postkantoor” proberen. Daarmee kwam ik in Elm, een email programma dat ik kende van Unix systemen. In de Inbox stond een welkomst berichtje van De Digitale Stad. Ik meen dat het was ondertekend door Marleen Stikker, maar dat weet ik niet meer, het is 25 jaar geleden en de tijd is sinds die zaterdagmiddag zo vreselijk snel gegaan. Ik stuurde een mailtje naar David, een AI wetenschapper aan GMU in de VS, de enige van wie ik zo snel het email adres kon bedenken. Dan maar “De Kiosk”. In de Kiosk kwam ik terecht bij artikelen van het NRC en van de Automatiseringsgids. Handig om die zo via je laptop te kunnen lezen. Dan “Openbaar Forum”. Een klein menu met titels als “dds.technopolis” en “dds.dds”, en “dds.misc”. Usenet was dat, een forum-iets dat op Unix systemen werd/wordt gebruikt als discussieforum, vergelijkbaar met de web forums van vandaag, maar dan heel anders. Usenet Groups is tegenwoordig ook toegankelijk als “Google Groups”.

In “dds.technopolis” las ik een stukje van prof. Egbert Dommering over internet en juridische aspecten en zo. Een nogal theoretisch stukje. Ik geloof niet dat er reacties onder stonden. O ja, eentje, van Marianne van den Boomen, die de moderator was van deze groep. De bedoeling was te bediscussiëren wat de invloed van het internet zou gaan zijn op de democratie, op onze samenleving, op alles. Ik postte dus maar een reactie, met de strekking “denk je dat het nuttig is op usenet zo’n enorm lang stuk te posten?”

Terug naar “Het Plein” dus. Weer “hallo”, weer “dat had je al gezegd”. Maar nu meer reacties, en binnen vijf minuten was ik in een geanimeerd gesprek gewikkeld met figuren als “MrJoost” en “MrFanatic”, en een Renate, en heel veel anderen. Na een kwartiertje of zo werd de chat ruw afgebroken, mijn verbinding werd verbroken. Terug inbellen was lastig, pas na 20 keer bellen was ik weer ingelogd. Navraag op het plein leerde me dat De Digitale Stad iedereen die inbelt er na een half uur uit gooide, om andere mensen ook een kans te geven mee te doen. Er waren veel meer inbellers dan modems. Ik heb heel wat keren opnieuw ingelogd die avond, en toen het tegen drieën wat rustiger werd, zette ik mijn laptop uit. Om een uur of twee had ik van Jole’s stukje gelezen, en nu 13 uur later was ik perplex. Wat is dit allemaal? Maar ook vastbesloten: hier wil ik meer van weten.

Ik wist ook wat meer, intussen. Op het plein hoorde ik dat op Salto TV een live uitzending was over De Digitale Stad. Ik zette dat aan, en ik hoorde Diana Ozon praten met vaag uitziende figuren achter computers, in De Balie, over DDS. Er verschenen tekstjes onderin beeld, die van Het Plein bleken te komen. Als ik wat intypte op Het Plein, verscheen dat soms in beeld, en dan praatte Ozon daarover met de vage jongelui in De Balie. Maar op Het Plein (dat IRC was, Internet Relay Chat, dat bestaat nog steeds) werd over Ozon gepraat, en over De Balie. Het was het eerste multi-mediale gesprek dat ik heb meegemaakt: een gesprek dat simultaan via internet en TV verloopt. Heel bijzonder. Later nooit meer zo gezien.

‘s Zondags besloot ik dat al dat opnieuw inbellen maar zonde van de tijd was, en ik meldde me aan bij hacktic.nl. Dat had men mij op IRC aangeraden, neem een account bij Hacktic dan blijf je gewoon ingelogd. De kosten konden het niet zijn, het kostte 5 gulden per uur. Pas later realiseerde ik me dat als je vier uur per avond bent ingelogd en het kost 5 gulden per uur, dat je dan aan het eind van de maand een flinke rekening krijgt. Die maanden heb ik Hacktic flink gesponsord.

Twee weken later was er een bijeenkomst van De Digitale Stad in De Balie. Daar ontmoette ik de mensen die ik kende van het plein en het forum. Marleen Stikker, die vanuit De Balie één van de initiatiefneemsters was van DDS. Felipe Rodriguez, die vanuit Hacktic de technische kennis en infrastructuur leverde. Joost Flint, die de hele zaterdag heen en weer fietste tussen de drukkerij en boekhandel Scheltema om nieuwe boekjes te brengen, de “handleiding Digitale Stad”. Ze vlogen bij Scheltema sneller de deur uit dan Flint ze kon aanslepen, ehm, aanfietsen.

Ik ontmoette ook Marianne van den Boomen, de moderator van dds.technopolis, de discussie over “internet en politiek en samenleving”. Ze zei “je bent in het echt heel anders, online ben je zo’n opgewonden standje”. Ik hoor het haar nog zeggen. Op het eerste gezicht ging DDS over techniek. Over computers, modems, servers, unix, van alles. Met name Marleen en Marianne legden echter een heel ander accent. DDS was geen techniek. Het was een community. Een gemeenschap die online ontmoet, discussieert, doet, van alles. Een beetje zoals “The Well”, waarover Howard Rheingold een boek had geschreven, “The Virtual Community”. DDS wás een virtual community. Het was een stad zonder fysieke grenzen, zonder locatie, zonder beperkingen. Marleen vertelde over Donna Haraway en haar Cyborg Manifesto. Bedenk wel, dit was 1994.

Het belangrijkste dat ik heb geleerd van Marianne en Marleen is dat internet, en online communities, en “online” in het algemeen, wordt bepaald door metaforen. De Digitale Stad maakte met de stadsmetafoor van een computernetwerk een bloeiende gemeenschap. De Digitale Metro was een bouwwerk onder de bodem van De Digitale Stad, het was ook een moo waar honderden enthousiastelingen bouwden aan hun eigen digitale structuren. En bouwden aan vriendschappen en relaties tussen mensen. Het Plein was een ontmoetingsplek waar mensen elkaar via modem-piepjes ontmoetten, maar dat niet alleen: al snel gingen we samen regelmatig pannekoeken eten, steeds in een andere stad in Nederland. MrJoost bleek ondanks zijn vervaarlijke naam een heel vriendelijke jongeman. MrFanatic bleek een beetje verlegen.

De Digitale Stad heeft langer bestaan dan de tien weken die oorspronkelijk gepland waren. Maar toch ook niet heel lang: na een paar jaar ging iedereen weer z’n eigen weg, nu met alle bagage die DDS ons gegeven had. Marianne ging verder met de metaforen, uiteindelijk is ze in 2014 gepromoveerd aan de RUU op een proefschrift over online metaforen: Transcoding the digital : how metaphors matter in new media. Inmiddels was ze heel ernstig ziek geworden, en niet lang na haar promotie is ze veel te jong overleden. Ze leeft voort, niet alleen in de boeken die ze heeft geschreven, maar ook in wat ze voor het internet heeft betekend: het internet is geen techniek, geen technologie, geen netwerk, geen computer. Het is een metafoor van onze samenleving.