Robert van Loghem en Jamie Craane over Mobile Development

Nou, welkom allemaal weer bij een nieuwe aflevering van CodeKlets. We zitten alweer in aflevering 13, Lucky 13, en dit keer in real life. Dat is toch wel bijzonder en vandaag ook bij Southwest Test Services in Rotterdam. En ik ben vandaag jullie host Kishen, maar gelukkig hoef ik deze aflevering niet alleen te doen. Ik heb twee hele leuke gasten uitgenodigd, Robert van Lochem en Jamie Krane, de amazing duo in mobile development. Maar wel op anderhalve meter afstand van elkaar. Ja, ja, ja, zeker absoluut. Ja, dat moet niet te zeggen inderdaad, we zijn wel heel voorzichtig in deze ruimte. Precies, precies. Ja, je weet maar nooit. Dus we hebben al in Niels nog niet de corona-app gecheckt, hè? Nee, dat hebben we niet gedaan. Nee, nee. Nee, goed geluk heb ik ook niet zo'n scannen. Dus wat dat betreft vertrouw ik jullie wel. Wij jullie ook. Ja, oké, mooi, mooi, mooi. Ja, zoals je hoort, ja, ik ben helaas vandaag in mijn uppie. Was de bedoeling dat ik met Bernard samen zou gaan opnemen voor CodeKlets. Maar ja, helaas, hij vertelde me gisteren dat hij een niet zo'n mooie stem heeft op dit moment. Dus helaas, ja, dat zou niet ten goede zijn van de opname. Dus doe ik het vandaag even alleen. En ja, ik ben natuurlijk hartstikke blij dat Robert en Jamie vandaag ons gaan verblijden met het onderwerp mobile development. Ik zal Robert even kort even aankondigen. Nou, Robert van Lochem, die programmeert al sinds zijn dertiende in Turbo Pascal. Ik hoop dat hij daar iets meer over mag vertellen, want ik ben het allemaal weer begrepen. Pointers en dat soort dingen en vroeger mouse drivers gemaakt en zo voor de pc. Oh, nice. Nou, toch wel nieuwsgierig, maar goed, dat komen we straks op terug. En na tien jaar backend ontwikkeling in Java en wat Scarlet hebben gedaan, is hij in 2010 gaan beginnen met ontwikkeling in Objective-C, IOS apps voor NS bouwen en een klein beetje ProRail. Ja, want dat hoort bij elkaar, toch? Of ook weer niet, he? Ja, een beetje logistiek. Logistiek, precies, ja. En nu zit hij voornamelijk in Kotlin en Swift in de front-end en ook in de backend. En ook in de backend en ook nog steeds een beetje Java. Ondertussen naast NS en ProRail ook Eneco en ANWB. Dus het zijn vooral de grote, bekende Nederlandse mooie merken waar we gewoon hele coole dingen voor doen. Nice. Ja, daar gaan we vast wel meer over willen. Daar willen we echt van alles over weten. Dus er komen vast wel wat vragen richting jullie daarover. Even kijken. Nou, en we hebben ook nog een tweede gast, natuurlijk, wat ik al zei, Jamie Kranen. En nou is het altijd bij mij de vraag, spreek ik het nou crane uit of is het nou kranen? Het is kranen. Je spreekt het goed uit. Oké. Maar je bent eigenlijk een producer in disguise, he? Ja, klopt. Ik heb in het verleden heel veel dance music gemaakt. Helaas ontbreekt me de tijd tegenwoordig aan, maar het is nog steeds een hobby van mij. Ja, cool, want volgens mij is dan jouw artiestennaam ook crane. Maar dan Jamie Crane dan? Ja, klopt, klopt. Dus dat is mij altijd blijven hangen. Ook in de tijd dat we samenwerken. We hebben in het verleden ook heel veel LP's op plaat uitgebracht. Die waarvan een aantal je nog op YouTube kan vinden. Dus dat is wel super super gaaf. Super gaaf. Ja, maar goed, ja, Jamie heeft inderdaad ook nog een andere hobby. Dat is een full stack software ontwikkelaar met een passie voor Kotlin en Kotlin Multiplatform. En hij heeft onder andere aan de wieg gestaan bij de NS rondom de reisplanner Android app en de Kotlin Multiplatform app van Enneco. Dus ja, wat Robert zegt, genoeg interessante, leuke bedrijven waar jullie gewerkt hebben. En we zijn natuurlijk super nieuwsgierig naar jullie ervaring. Ja, het leuke is dat we eigenlijk al die dingen die Robert ook heeft gezegd, dat we dat samen hebben gedaan. Al acht jaar lang. Dus we werken al acht jaar lang in iOS en Android developers samen en back-end natuurlijk. En back-end, ja, volgens mij. Ja, dat is ook precies waar. Ja, dat is ook de reden waarom ik jullie de amazing duo in mobile development heb genoemd, want dat viel me een beetje op in jullie. Ja, op LinkedIn te kijken van goh, hey, die zitten toch wel vaak samen. Dus dat is wel leuk, hè? Maar we wonen niet samen. Nee, dat niet. Nee, zo ver is het nog niet. Nog. Oeh, nog niet. Ja, dit kan nog komen, natuurlijk. Oké, nou goed, vlucht naar de volgende VR-plak, dat is goed, ja. Nou ja, zoals jullie, ja, misschien ook wij de vorige afleveringen wel schoot hebben, is ja, we zijn altijd nieuwsgierig naar onze gasten en de eerste ervaringen met de computer of coding in general. Dus laten we eens even beginnen bij Jamie misschien. Wat was jouw eerste programmeer ervaring? En kun je daar iets meer over vertellen? Ja, daar kan ik zeker wel wat meer over vertellen. Dat begon eigenlijk al op jonge leeftijd. Ja, de jeugd tegenwoordig groeit op met mobiele telefoons en allerlei digitale apparaten. Dat was toen totaal nog niet. Dus mijn eerste pc ervaring, zo gezegd, was toen ik een jaar of 12 was. We hadden toen een pc thuis met basic erop. En dat was ook mijn eerste programmeer ervaring. En het eerste wat je doet is text adventures gaan maken van ga naar links en wat zie je dan? En dan koop je boeken en dan ga je games maken door die boeken die code uit die boeken te schrijven. En op een gegeven moment leer je en leer je. En dan vind je dat toch heel leuk om te doen. En zo is dat een beetje ontstaan en dat is er altijd ingebleven. En vanuit die hoek ben ik er ook ingerold, zeg maar. Oké, dus dat was eigenlijk game development, als ik het goed begrijp. Ja, in het begin echt game development en daarna. Ja, dan werd het serieuzer. Opleiding gedaan natuurlijk aan de HTS in Den Bosch toen nog. Ja, en zo is dat ontstaan. Maar echt op jonge leeftijd al mee bezig geweest. Ja, en kan je nog iets herinneren, weet je, gewoon een heel belangrijk leermoment vanuit jou. Weet je altijd experimenteren met programmeren en coderen? Wat je misschien nu nog steeds in je DNA, zeg maar, zit. Ja, goede vraag. Het is uiteindelijk altijd een beetje puzzelen coderen. Je maakt iets, maar je loopt toch soms wel eens tegen problemen aan, waarbij je oplossingen moet zoeken in creatieve hoeken. En dat was toen al en dat is nog steeds. En dat vind ik het leuke eraan. Echt een uitdaging en uiteindelijk weer voldoening. Als je datgene hebt gemaakt, wat je voor ogen had, dat het ook echt zo werkt. En zeker nu als miljoenen mensen van je product gebruikmaken. Dat is super gaaf. Ja, en ja, misschien zei je het in het begin ook al, maar even voor mij welke ontwikkeltaal was dat ook weer waar je het over had net? Vroeger bedoel je? Ja, in Basic. In Basic was het, oh ja. Pascal, wat Robert nu ook heeft gedaan. Een Delphi visual designer had je destijds om Windows applicaties te maken, maar daar is het een beetje mee begonnen. Ja, ik kan me ook nog herinneren dat ik ook, ja, maar dat was dan meer op school. We waren ook een game aan het bouwen. Dat was een soort van, hoe heet dat nou? Space Invaders. Ja, dat je dan objecten moest kapot schieten en zo. Leuk. Ja, dat was wel heel bijzonder. Dat was een hele bijzondere ervaring. Games zijn natuurlijk heel erg tastbaar. Dat is veelal de eerste dingen waar je mee in aanraking komt. Je ziet iets op een scherm beschijnen. En dat, ja, dat is leuk. Ja, precies. Wat mij nu even te binnen schiet, is iets wat ik dan van geleerd heb, is dat, ja, noem het maar even object georienteerd programmeren, maar in ieder geval met objecten omgaan. Dat je een object hebt, zoals inderdaad zo'n alien die je moet raken en die dan attributen heeft en dan weet je wel wat die dan kan en wat die niet kan. Dat je daar dan encapsulatie omheen, weet je wel, maakt en dat soort dingen. En in het begin deed je dat misschien onbewust. En uiteindelijk leer je bewust dat soort dingen. Dus dan zie je heel veel dingen zijn herkenbaar. Nou, jullie moeten er eigenlijk bij zitten. En dan ben ik wel blij dat ik nu in real life aan het opnemen ben. Maar Robert, die begint nu een dikke feestpalm. Ja, precies zo. Maar object georienteerd programmeren. Volgens mij, ik was vroeger altijd bezig met procedurale, de ene functie, de andere functie en globale dingen en zo. Vroeger was het wel heel erg, want mijn pa en ma hadden nooit zoveel geld. Dus wij hadden geen pc. Mijn oom, daarentegen, was hoofd van de IT-afdeling van een middelbare school. Dus die had allemaal computers thuis staan. Dus ik begon inderdaad gewoon, zeg maar, ieder weekend daar hem toe te gaan en dan gewoon lekker GW Basic spelletjes spelen. En op een gegeven moment dacht ik al, zeg maar, het lijkt me wel leuk om die dingetjes een beetje aan elkaar te knopen. Dus een soort menuetje gemaakt en zo. Nou, en toen begon het. En toen dacht ik van, nou, het is wel heel stoer om dat soort dingen te maken. En ik weet nog wel dat we op een gegeven moment hadden we een beetje geld gespaard, Pama, en had ik bij een ander vriendje, had ik een spelletje gespeeld, Scorched Earth. Ik weet niet of jullie dat kennen. Dat was echt, dat was, zeg maar, een soort landschap. En er stonden allemaal verschillende tankjes op en iedere speler had een eigen tankje. En dan kon je, zeg maar, elkaar, het is Worms, zeg maar, maar dan een tankje. Dat is het leukste, dat was de Nuke natuurlijk. Precies, de funky Nuke en dat soort dingen. Maar dat was met een VGA scherm. Maar wij hadden geen VGA, wij hadden CGA, een CGA scherm. Dus ik wilde dat spel spelen, dus dat heb ik gedaan. Ik heb dat spel gewoon nagemaakt in Turbo Pascal. En daar was ik super trots op, dat ik inderdaad een funky bomb kon maken en dat, zeg maar, met een 3D-landschap kon renderen en zo. En dat was echt super cool om te doen. En het tof is gewoon dat je gewoon dat samenspeelt met andere mensen en uitprobeert. En ook, ik had een vriendje met wie ik dat programmeerde en zo. En toen dacht ik van, dit is gewoon zo gaaf om te doen. Je kan er echt uren plezier mee hebben. Je kan precies maken hoe je het zelf wil allemaal. Daar is het eigenlijk allemaal mee begonnen. Ja, oh, tof. Maar was dat dan ook je eerste ervaring rondom programmeren? Ja, ja. Oh, oké, cool. Dan ben je wel gelijk in het diepe gegooid dan, hè? Ja, ik vind het gewoon prachtig, zeg maar, als je iets wil, om daar gewoon in het diepe te duiken en dat gewoon helemaal uit te zoeken, om te zorgen dat het gewoon, zeg maar, werkelijkheid wordt en aan andere mensen te laten zien en te ervaren. En ja, het is gewoon prachtig om te doen. Dat vind ik het mooie aan programmeren. Je maakt er van niets, maak je iets en je laat het zien. Je ziet gewoon de reacties op het gezicht van mensen. En je krijgt de feedback erop en je past wat dingetjes aan. Dat blijft gewoon altijd prachtig, zeg maar. En ik doe het ook al vanaf mijn dertiende ongeveer. Dat is al behoorlijk lang helaas. Dus ik voel me echt wel vet oud. Maar goed, het is gewoon prachtig om dat te doen. Het blijft toch een bepaalde manier van voldoening geven. Steeds iets maken wat tastbaar is en wat anderen iets mee kunnen doen. Ja, dus ja, dat is op zich wel interessant, want ik heb ook wel eens gesprekken met developers over van wat vind je nou belangrijker, koden of het doel om te koden? Hoe zouden jullie het beantwoorden? Volgens mij hadden we een tijdje geleden met het huidige team waar we nu zitten, hadden we daar een natere gesprek over. En waar ik toen aan dacht is van kijk, zeg maar iets maken voor andere mensen is het mooiste. En vaak is het zo dat als je dat niet op tijd doet, want er is maar een beperkte hoeveel het geld en tijd beschikbaar, dan houdt het op een gegeven moment op. Alleen, je moet er geen rotzootje van maken, want anders schiet je zeg maar in je eigen voet. Anders kan je nooit zeg maar dat langdurig voortzetten. Dus het is altijd een balans tussen zeg maar die kwaliteit, tijd en geld, het is een beetje standaard, ouderwetse driehoek en zo. Maar je moet het altijd in ogen schouw nemen van wat is haalbaar en hoe ver kan ik gaan in het ene of het andere. En nogmaals, ik heb echt vroeger toen ik net begon met programmeren, ik weet nog wel, ik was aan een of andere programmetje aan het werken, het kies-en-klik menu. Daar kon ik allemaal verschillende DOS programma's mee opstarten. Ik had er zo'n puinzooi van gemaakt dat ik over een gegeven moment niet meer mijn eigen code snapte. En toen dacht ik echt zo, oké, dit moet gewoon anders. Dus weet je, je leert gewoon wel van, oké, tot hoe ver kan je gaan? Wanneer snap ik het en wanneer moet ik het aanpassen en zo. Maar je wilt toch altijd wel een bepaalde voortgang wil je erin hebben. Ja, ja, klopt. Dat is ook een beetje ervaring natuurlijk, he. En op een gegeven moment kom je op een punt dat dat wellicht altijd zo is. En dan is het tijd om wat dingen anders te doen. Ja, klopt. Elke context is net even anders, he. Dus de ene die heeft inderdaad een oneindig budget om toffe dingen te doen in code. De andere natuurlijk niet. En dan, ja, dan ga je keuzes maken. Klopt. Ja, de ene is dan misschien wat rigoureuzer dan de ander. En ja, op zich, in jullie antwoorden hoorde ik wel toch, als ik het goed heb gehoord, dat het meeste genieten is de reactie van die gebruiker. Klopt, klopt. Dat geeft ze echt de voldoening. Ja, ja, oké. En ik denk, zeg maar, toen wij allebei voor de NS werkten, ik ging dagelijks met de trein naar Utrecht Centraal, want daar zit NS hoofdkantoor. Het is zo gaaf om de NS reisplanner in handen te zien van mensen die vervolgens een reis plannen of bijvoorbeeld een treinrader bekijken of de delays zien ofzo. Denk je van, oh, daar heb ik al gewerkt, weet je, dat is mijn scherm. Daar heb ik, oh, en ik weet waar de bugs zitten of ik weet waar dit nog zit. Oh, dat weet ik ook nog niet helemaal lekker. Maar ze komen er toch wel uit en je ziet gewoon dat ze het gebruiken en snel opstarten en weer weg gaan. En dat vind ik ook het mooie van mobiele ontwikkeling, want het is, zeg maar, je kan het aan iedereen uitleggen. Ik kan het aan, ik bedoel, niet alleen mijn moeder en vader, zeg maar, op verjaardagsfeestjes die we de laatste tijd niet zo heel veel mee hebben onder vanwege corona enzo. Maar je kan altijd heel makkelijk binnen drie seconden kan je uitleggen ongeveer wat je doet. Ik maak apps voor iOS en ik maak ook de achterkant een beetje en zeg ze, oh, wat heb je nou gemaakt nou? Heb je de reispunten? Ja, die heb ik wel. Ik bedoel, oh, dat is graag. Nee, dat is super cool om gewoon, zeg maar, dat te doen. Dat is ook heel erg tastbaar. Iedereen heeft een mobiele telefoon bij tegenwoordig, dus iedereen weet waar je het over hebt. Kunnen jullie misschien ook iets vertellen over jullie huidige projecten, want jullie zijn de Amazing Duo op dit moment. Ja, welk project zitten jullie nu en kunnen jullie iets meer over vertellen? Ja, zeker. We zitten nu bij de ANWB allebei en we werken aan de onderweg app. De onderweg app is natuurlijk een van de vlaggenschip apps van de ANWB. En wat we concreet dit jaar hebben gedaan is het tanken en laden. Waar zijn laadpalen nou beschikbaar, waar zijn tankstations beschikbaar? Om dat op een betere manier inzichtelijk te maken in de app. En ook dat je in realtime beschikbaarheid krijgt te zien van waar is nou een specifieke laadpal, is die nou beschikbaar of niet. Dus als je je reis gaat voortzetten met je elektrische auto, dan kun je ook zien is die laadpal beschikbaar of niet. Dus daar zijn we voornamelijk mee bezig geweest. Plus we werken nog aan hele nieuwe, coole features. Daar mogen we helaas nu nog niet heel veel over zeggen, maar dat gaat er wel aankomen. Spannend, joh. En hoe lang zitten jullie er al, Robert? We zitten er sinds februari ongeveer. Dus inderdaad wat Jamie zegt, die laadpalen, het is echt zo dat op het moment dat je bijvoorbeeld een stekker in een stekker ergens insteekt, dat je gewoon echt in de app, gewoon realtime, zeg maar het bolletje van groen naar rood ziet veranderen, gewoon zeg maar zo realtime. En we hebben daarvan niet alleen de iOS en Android voorkant gemaakt, maar ook de backend. Dus bijvoorbeeld een polling mechanisme die netjes gewoon iedere twintig seconde poldt. Sorry, het zijn geen websockets. Dat zou nog mooier zijn, maar goed, dat komt nog wel. Maar het toffe is, we krijgen wel zeg maar netjes via Patch Request via een derde partij, ik heb er niks aan gegeven, zeg maar welke palen gewoon onbeschikbaar zijn of ineens in gebruiken of iets dergelijks. Dus het is best wel best wel realtime. Draait allemaal op AWS en Kubernetes omgeving. Dus daar houden wij ons eigenlijk allemaal mee bezig. Anderen wat we dit jaar nog gereleased hebben is zeg maar dat je je Wegenwacht pechmeldingen kan inschieten. Dus op het moment dat jij aan de kant van de weg staat en je hebt pech, dan kan je netjes via de onderwegheb, kan je aangeven wat er aan de hand is. We gebruiken natuurlijk netjes gps locatie. Als je ingelogd bent, dan weten we precies wie jij bent. En zo wordt er uiteindelijk een Wegenwacht autootje naar je toegestuurd. Echt waar joh, dus zover gaat het, dat jullie echt, noemen we het maar even de connectie van de klant, dus de ANWB en de klanten van ANWB, zeg maar, kunnen maken. Oké, dat is wel interessant zeg. En ja, zou je ook iets kunnen vertellen over hoe groot jullie team nu op de moment is? Ja ja, ik schat dat we met 15 personen nu in het team zitten van de onderweg app. Er zitten een stuk of vier Android developers, waarvan een aantal full stack. Vier iOS developers als ik het goed heb, twee dedicated back-end developers. We hebben nog een Scrum Master, een design rol. Dus het is een redelijk groot team. Er zit best wel veel functionaliteit in de onderweg app, bijvoorbeeld ook een parkeren stuk, waarmee je kan zien welke parkeerplaatsen beschikbaar zijn en dat je ook echt een plek kan reserveren. Dus verschillende des werk aan verschillende onderdelen in de app, zeg maar. Oké, en hoe bevalt dat? Want er zijn toch twee verschillende technologieën. Hoe valt dat samen en hoe is de ervaring dan tussen de developers? Qua iOS en Android, ja, op zich gaat dat goed, want we hebben redelijk veel contact met elkaar, ook als een team, gezamenlijk Scrum team, gezamenlijke stand-up, dus we weten redelijk goed van elkaar waar we allemaal mee bezig zijn. Oké. Het feit blijft natuurlijk, omdat je Android en iOS native doet, dat je twee keer dezelfde dingen aan het bouwen bent. Oké, ja, ja, dat was ook een beetje waar ik nieuwsgierig naar was, van hoe jullie daar dan mee omgaan. En zijn het dan ook twee echt aparte teams of doe jullie dat samen? Nee, het is één team eigenlijk. Wat we proberen is dat bijvoorbeeld één platform iets vooruitwerkt, de eerste implementatie maakt. Daarmee loop je al tegen wat problemen op aan en moet je ze oplossen en dat de tweede team, of de tweede team, zeg maar dat andere platform er een beetje schuin achterloopt, zodat je niet nog eens een keer dezelfde problemen tegelijkertijd hoeft op te lossen. En daarmee behaal je best wel wat winst eigenlijk. Daarnaast proberen we in mindere, meerdere maten proberen ook zeg maar bepaalde manieren in de code, zeg maar qua architectuur proberen we ook op de zelfde manier op te lossen door dezelfde patronen te gebruiken ongeveer. Bijvoorbeeld Android gebruikt Compose, in iOS gebruiken we SwiftUI en ViewModels en zo. Dus het ziet er allemaal wel een beetje ongeveer hetzelfde uit. En ik denk dat dat juist goed is, want op zich misschien is de interactie net een klein beetje anders en zijn de UI componenten net een beetje anders. Maar de business logica is hetzelfde, je backends zijn hetzelfde. Het hoort eigenlijk op dezelfde manier te reageren, vanuit functioneel gezien eigenlijk. Dus ja, daar zit best wel wat kruisbestuiving tussen. Klopt. En uiteindelijk, functionaliteit moet in beide apps terechtkomen. Dus je hebt ook continu met elkaar te maken. Ja, nee, oké. Dus als ik het goed heb begrepen, jullie team samenstelling is wel zodanig ingericht dat of teams, want ik hoorde net twee teams. Om m'n weg heb ik dus één team, maar wel dedicated Android en iOS developers, maar wel in één gezamenlijk. Oké, dus dus je zei dat er een team is, dat is wel gaaf. En zien jullie dan ook dat Android developers ook een beetje iOS programmeren, andersom? Ja, en vice versa. Dus bijvoorbeeld, we hebben een ander teamlid, Sam, hebben we erin zitten, die af en toe gewoon Android bijspringt. Om bepaalde dingen gewoon op te pakken of zo, en dat kan ook gewoon prima. En ja, datzelfde doen we ook bijvoorbeeld, zeg maar, een aantal iOS'ers kan ook gewoon prima kort in. Dus wij kunnen ook gewoon prima in die code kijken of dingetjes aanpassen. Of ja, dat is helemaal geen probleem. Ja, dat zou ik ook misschien strakjes ook hebben. Nog een onderwerp staan, daar zou ik ook willen inzoomen. Ook voor degenen die daar misschien nog niet echt mee bezig zijn. We zien even kort introduceren. Oké, cool. En ja, en hoe gaat het bij de ANWB rondom remote werken en zo? Werken jullie over het algemeen remote of zit jullie nogal regelmatig op kantoor? Nee, we werken grotendeels remote. Sterker nog, toen wij voor de ANWB zijn begonnen 1 februari, zijn we niet één keer naar kantoor geweest en hebben we alles eigenlijk remote gedaan. Tot aan een maandje geleden, waar we hebben besloten om toch één keer in de twee weken naar kantoor te komen of met z'n allen bij elkaar te zitten, wel op veilige afstand uiteraard. Maar grotendeels wordt alles remote gedaan. Dus development is daar ook op ingericht met de juiste communicatiemiddelen. Iedereen weet elkaar te vinden. Proactief is ook belangrijk, denk ik. Dagelijks doen we een informele coffee stand-up zodat we elkaar toch allemaal zien en een beetje informeel met elkaar over dingen kunnen praten. Maar ja, grotendeels is het remote. Ja, waar ik ook wel nieuwsgierig naar ben is de development manier van werken. Kunnen jullie daar iets over vertellen? Tegenwoordig hebben we natuurlijk allerlei way of workings in teams. Hebben jullie misschien er eentje, misschien ook wel willen delen met de rest van de wereld? Ja, zeker, zeker. De manier van werken was redelijk vast toen we bij ANWB kwamen. Ze werken op een scrub manier met twee wekelijkse sprints, waarbij er aan het begin van de sprint bepaald wordt wat er aan werk verzet gaat worden in de sprint. Op dit moment neigt het weer een beetje meer naar kanban, omdat vooraf in de sprint twee weken is best wel lang, vind ik, om te bepalen wat ga je nou in twee weken doen. Dus het idee is ontstaan om vooraf te kijken, oké, wie pakt welke story op, maar we gaan geen extra werk in de sprint zetten. Is die story klaar? Dan gaan we kijken wat heeft dan de hoogste prioriteit en pakken we dat op. Dus dat is net iets meer kanban dan echt, het zijn nog wel twee wekelijkse sprints, maar iets flexibeler. Zitten ze bij ANWB echt op de deadlines en dat soort dingen, of valt het wel mee? Er ligt eraan wat voor functionaliteit het is. Als je zorgt dat je niet iedere keer dezelfde demo laat zien, zie ik je goed. Oh nice, ja, dat is wel een hele goede graadmetering. How to kill your software project, show the same demo twice. Nee, inderdaad, dat wil je zeker niet. Oké, zijn er ook product developers in the teams aanwezig, of zijn jullie helemaal autonoom? We zijn redelijk autonoom, maar er zit wel een product owner op die bepaalt uiteindelijk wat er aan functionaliteit inkomt en wat voor werk er gedaan moet worden, maar wel veel input vanuit het team zelf ook. Ja, zeker. En het andere gave is wel dat we merken dat de developers, een aantal, je pakt een lead voor een bepaald onderwerp en je spreekt met de business, dus de product owner en de lead, spreekt met de business en dan weet je heel goed, zeg maar, wat wil de business, waar gaan we naartoe, wat is de visie allemaal, maar ook nog eens een keer, hoe zit het technisch in elkaar, hoe moeilijk is iets, wat is zeg maar een beetje de low hanging fruit ergens, kunnen we creatieve oplossingen hebben en dat is best wel waardevol, denk ik, wat we nu geïntroduceerd hebben bij de ANWB en wat wel goed werkt. Dus en daarmee kan je best wel zeggen van nou, weet je, dit is mogelijk of dit is heel erg lastig of en dan kan je heel snel inschatten en heel snel stories maken en heel snel opleveren, zeg maar, waar die business en die klant uiteindelijk, zeg maar, behoefte aan heeft. Ja, het voordeel daarvan is dat men ook een bepaalde manier van verantwoordelijkheid gaat krijgen voor het werk wat gedaan wordt. En ik denk dat dat heel belangrijk is om, als je iets oppakt van, waarom doe ik nou iets en wat maakt die klant nou blij? Ja, want het is niet alleen maar een story op de backlog, maar het is, weet je, ik wil graag meer dat als iemand bijvoorbeeld pech helpt, heeft, dat hij bijvoorbeeld, en hij is nog geen lid, dat hij zich makkelijk kan aanmelden. Weet je, dat is een nieuw lid voor de ANWB, super waardevol eigenlijk. En als je dat gewoon kan pushen of als je die functietijd mogelijk maakt, dat is natuurlijk super gaaf om dat op te gaan zetten eigenlijk. Ja, ja, dus het keert weer terug waar we het in het begin over hadden, weer die empathie voor die gebruiker. Ja, dus dat moet er wel in zitten, denk ik, ook voor degenen die dan ook die requirements gaat opstellen. Ja, dat is wel tof dat jullie daar ook aandacht aan besteden, want je hoort het ook wel eens anders. Zeker, zeker. Kunnen jullie ook iets meer vertellen over de, ja, de stack die jullie nu gebruiken? Natuurlijk is het iOS en Android, maar onderliggend, van waar bouwen jullie in en welke tools, of misschien ook wel frameworks gebruiken jullie? Ja, als ik even voor Android praat, vanuit mijn achtergrond bouwen we een native app natuurlijk. Tools die wij gebruiken zijn Android Studio op dit moment, voor backend IntelliJ. Een architectuur die we in de Android app hanteren is echt een MVI, MVVM-architectuur. Maar ANWB heeft natuurlijk een app met een lange lifecycle van jaren aan ontwikkeling, dus je ziet daar een verscheidenheid aan, aan patterns in terugkomen. En dat zal ook voorlopig zo blijven. En dat is ook prima, omdat alles evolueert mee natuurlijk, maar dat wil niet zeggen dat je al het oude meteen moet omschrijven, elke keer naar iets nieuws, want als je dat gaat doen, dan krijg je op een gegeven moment niks meer gedaan. Dus daar is een stukje commonsense ook aanwezig. Maar nieuwe dingen, allemaal volgens nieuwe patronen. Alles in Kotlin ook. En qua backend doen we veel met Spring Boot op het Kubernetes platform op AWS. En welke database systemen gebruik je? Het zijn verschillende. De search, hebben we bijvoorbeeld Elastic Search voor, voor bepaalde realtime systemen, DynamoDB. Het ligt een beetje aan de use case en de functionaliteit. Oh ja, ja, ja. Dus de response die jullie misschien verwachten, dat soort dingen. Ja. Oké. En heel veel integratie met externe systemen, waar data vandaan komt. Zoals bijvoorbeeld de oplaadpalen, de tankstations, de parkeerplaatsen, et cetera. En ik neem aan dat jullie ook allerlei services bouwen. Werken jullie ook met, ja dan ga ik weer zo'n buzzword gebruiken, maar werken jullie ook met microservices en dat soort zaken? Met dit gedachte goed, laat ik het zo maar even zeggen. Ja, een voorbeeld is bijvoorbeeld de service die de realtime, die realtime de beschikbaarheid van de laadpalen oplevert. Dat is een specifieke service die specifiek voor dat doel is gebouwd. Oké. En hoe doen jullie dat met AWS? Zijn daar ook bepaalde frameworks die jullie zouden aanraden of tools? Nou, eigenlijk wat we doen is, vooral Swift, dat is prima. Ook daar zie je weer, het is een app die een lange lifecycle heeft. Die heeft verschillende patronen, Viper heeft het erin zitten. Maar nu gebruiken we vooral SwiftUI en MVVM. Het lijkt enorm veel op Android met de Compose. Dus dat is goed, want dan kan je gewoon een leentje buur doen eigenlijk. Ja, we hebben netjes GitLab met een CI-CD straat. Op het moment dat je een branch aanmaakt met een pull request, dan wordt het automatisch gebouwd, getest, et cetera. Zodra die gemerchd wordt naar developer, omdat we Gitflow gebruiken, wordt er een testversie neergezet. Dus je kan het ook gelijk op je device zetten of testers kunnen op een device zetten om het te testen. Dus het is volledig geautomatiseerd. Er zit nog een stukje SwiftLint tussen om te checken inderdaad of je wel voldoet aan de coding, guidelines en dat soort dingen. Ook al zou ik eigenlijk eerder willen zeggen, gooi er alsjeblieft een script overheen die het automatisch goed zegt, want dan hoef ik er niet over na te denken, dat soort dingen. Maar goed, het is allemaal prima. Het is best wel goed geautomatiseerd en het is gewoon erg fijn. Je noemt net Gitflow, waar valt welke... Ja, want ik werk toevallig bij de NS nu op dit moment en daar gebruiken ze over het algemeen veel Jenkins en Azure DevOps. Waar valt Gitflow in? Ja, we gebruiken GitLab als... Dus ANWB heeft een self-hosted GitLab omgeving die in principe CI-CD pipelines aftrapt. Daar hebben ze ergens geloof ik een M1 Mac Mini staan die zeg maar de beeldserver is. Ja, die M1's die zijn best wel snel trouwens, spot for Dory. Dus we zijn ook, we hebben ook onze creditcard getrokken voor de nieuwe Mac Pro's of Macbook Pro's. Maar goed, dat komt straks wel. Ja, dat snap ik. Ja, oké, oké, inderdaad, Gitflow is dus van GitLab, ja. Maar het is inderdaad voor iOS ontwikkeling is het best wel belangrijk gewoon dat je een goede beeldstraat, goede pipelines klaar hebt staan zodat je niet zelf hoeft te bouwen. Want ik heb nog steeds wel af en toe projecten dat je denkt van oké, dan moet het naar de App Store versterven of dan moet een testversie. En vervolgens is dan een ontwikkelaar bezig om op zijn laptop netjes vanuit Xcode een archive en een upload te doen en dingetjes, weet je, dat soort dingen kan je tegenwoordig allemaal zo goed automatiseren. Dat hoef je echt niet meer over na te denken. Ja, want dat is een noob question vanuit mijn kant. Heb je nog steeds de App Store nodig in de middel of kan je dingen ook al zelf, weet je wel, gewoon provider, zeg maar. Nee, nee, je hebt de App Store nog steeds nodig. Je ont komt er gewoon niet aan. Nee, kijk, en dat is natuurlijk een beetje het lastige aan iOS ontwikkeling. En ik ben een groot fan van continuous integration, want hoe eerder jij feedback hebt over hetgene wat je hebt gemaakt, is het beter. Dus de beste feedback is bijvoorbeeld de compiler, want je drukt op compile en je krijgt gelijk een error tussen die en je kan het fixen. Zeg maar, web heeft natuurlijk iets prachtigs. Als je dat allemaal strak hebt ingericht, dat als je een change maakt en dat gaat door al je testen heen en staat het in principe binnen no time, op productie staat het gewoon te draaien. Dat zou ik heel graag willen voor iOS, maar het zit er gewoon niet in, want we hebben het gewoon te maken met een App Store, waarin je moet submitten en moet wachten op een review tijd. Nou valt die review tijd tegenwoordig wel mee, want vaak is het een half dag, paar uur. Dus het is best wel snel, maar nog steeds zit daar gewoon een soort disconnect tussen dat je niet gewoon direct iets op productie neer kan zetten of dat als iets kapot is, dat je binnen 30 minuten kan fixen of binnen 20 minuten kan fixen. En dat is wel jammer. Maar misschien gaat het ooit nog eens een keer veranderen als Apple dat toe gaat staan. En natuurlijk heb je ook natuurlijk het probleem dat je hebt een device en die updates, die worden niet per direct opgehaald. Er gaat altijd, de app moet automatisch geïnstalleerd worden of sommige mensen hebben dat uitstaan. Dus daar heb je ook altijd mee te maken. Dus je moet altijd wel iets voorzichtiger zijn. Maar... Is dat bij Android dan ook op die manier via de Google App Store of? Ja, dat is wel vergelijkbaar. Volgens mij heeft iOS wel andere review normen dan Android. Maar tegenwoordig is Google er ook strakker in geworden over wat wel en niet zomaar kan en mag. Dus wat dat betreft is dat redelijk vergelijkbaar. Met Android kun je natuurlijk wel site-loaden. Maar met consumenten apps die wij maken gebeurt dat eigenlijk niet echt. Die worden netjes gepubliceerd in de App Store en men kan die downloaden en installeren. Ja. Hoe gaan jullie dan op met al die user interface testen? Want ja, op een gegeven moment, wat ik wel mooi vind aan jullie verhaal, jullie vinden dat de gebruiker moet gewoon centraal staan in alle development. Maar dan op een gegeven moment moet je ook als gebruiker dingen gaan testen. Hoe gaan jullie daar op dit moment mee om? En dan specifiek bij de ANWB? Ja, ja, dus bij jullie huidige project inderdaad. Ja, we zijn op een aantal levels. Zijn er testen die we doen in de basis de unit testen van de apps, waarbij we kleine stukjes functionaliteit geautomatiseerd testen. Daarbovenop de integratie testen, ook binnen de app, maar ook binnen de backends die we maken. Dat ook echt kijken of of een HTTP call het juiste antwoord geeft. En de app doet wat hij moet doen. We hebben beperkte UI testen, geautomatiseerd dan. Dat toch blijkt in het verleden nog steeds dat dat toch best wel een behoorlijke kluiven is om die te onderhouden. Dus we hebben ook gebruikers die de app testen en we testen ook zelf de app vanuit de UI en we kunnen releases gefaseerd doen, zodat we met een beperkt aantal gebruikers een release al kunnen kunnen testen. Oh, nice. Dus jullie ook weer hier terugkomend is dat jullie de gebruiker weer centraal zetten. Dus die hebben jullie dan ook centraal in je software development lifecycle waarschijnlijk, dus dat jullie een soort van noem het maar even een fase introduceren waar select gebruikers het alvast kunnen uitproberen. Ja, dat is afhankelijk van de functionele wijziging natuurlijk. Een bug fix release is wellicht voor iedereen meteen beschikbaar. Is de wijziging wat groter? Dan zit er ook soms een echte UI en een interaction test aan vast om te kijken hoe bepaalde functie tijd ervaren wordt. Ja, en wilde jij nog wat toevoegen? Ja, ja, ik zat te denken van kijk, we hebben inderdaad beperkte UI testen zoals Jayme al zei, van het kost best wel wat tijd aan onderhoud om dat allemaal goed te krijgen. En ik denk dat het vaak een keuze is van als je heel snel wil gaan, dan kan je minder dit soort testen doen. Ik denk wel bijvoorbeeld dat grote clubs die heel veel waarde hechten aan bepaalde kwaliteits eisen zoals een ING en zo, weet je Rabobank, dat moet gewoon goed zijn. Want als je geld overmaakt ofzo, je wil gewoon zeker dat dat niet fout gaat. Maar voor andere dingen is het risico misschien wat meer toelapbaar. Dus hoe beperk je dan de risico? En inderdaad op het moment dat je vaker makkelijker bug fixes kan doen als dingen mini risico veel zijn. We hebben bijvoorbeeld ook dingen als feature toggles. Dus naast een gefaseerde roll-out kan je ook gewoon zeggen het gaat compleet mis. We zetten gewoon de feature gewoon compleet uit als er iets nieuws is. En daarmee probeer je eigenlijk gewoon toch wel een beetje die snelheid erin te houden. En als er iets niet goed is, gewoon aan te passen. En dat kan best wel niet goed zijn, kan niet een tekstje zijn ofzo. Maar soms kan het ook wel zijn dat gewoon een scherm grondig aangepakt wordt omdat gewoon iets niet werkt. En ja, zeg maar dat soort wijzigingen, als je dan ook nog een behoorlijk veel UI-tests er tegenover hebt zitten, dat kan best wel een kostbare zaak worden. Dus vaak kiezen we er wel voor om dat niet 100 procent te doen, moet ik eerlijk zeggen, maar meer voor die snelheid en voor die snelle fixes in productie te gaan. Ja, en de vraag is ook een beetje, wat test je? Als je je code op een nette manier opzet, dan test je op de laag net onder de UI eigenlijk al de meeste functionaliteit. Misschien alleen de button-click dan nog niet, maar de logica die eronder zit, dat is allemaal getest. Ja, ja, wat ik ook wel mooi vind aan jullie verhaal is dat jullie ook toch na hebben gedacht over de architectuur. Dus jullie doen multi-platform soort van bouwen. Dus daar moet ook een gedegen architectuur achter zitten, zodat je inderdaad de business logica mooi isoleert van de logica in de UI en dat soort zaken meer. En dan geeft dat natuurlijk ook meer perspectief om zaken anders te testen dan traditioneel, zeg maar. Dus dat je alles met de UI wil. Dus dat geeft inderdaad zeker mogelijkheden. Ja, en doordat op die manier het doen, ben je uiteindelijk ook weer sneller omdat je, doordat je de bijna 90 procent wel natuurlijk automatiseerd kan testen, heb je ook meteen feedback als er dingen stuk gaan. Ja. Meteen tijdens het ontwikkelen al. Ja, iets wat me ook net te binnen schoot, je had het net over verschillende backend services, die moeten natuurlijk ook met elkaar communiceren en zo. Doen jullie ook aan consumer contract driven testing? Bij de ANWB wordt dat nog niet echt gedaan. Daar zit wel natuurlijk, wij zijn heel scherp op, wat voor wijsigingen kun je nou wel of niet doen in de backend, omdat je eigenlijk geen controle hebt over welke gebruiken nou welke versie van de app geïnstalleerd heeft. Dus backend services zijn gevergineerd en er zijn een aantal simpele regels waarbij dingen toevoegen aan een contract dat mag, dingen verwijderen of hernoemen. Ja, dan moet je al gauw denken aan versionering of iets om dat tegen te gaan. Maar gebruiken jullie dan ook technologie, of nou, technologie frameworks als packed, weet je wel, om dat dus te blijven controleren of misschien vinden jullie het wel helemaal niet nodig? Ja, de microservices die we maken, die hebben wel een snapshot, zeg maar, van het respons wat een bepaalde versie heeft, waar tegen getest kan worden. En als dat afwijkt, dan krijg je daar ook een testfout op. Ja, en dan moet je dus bewust gaan nadenken over datgene wat je verandert aan je respons. Ja, precies. Maar dan gebruik je geen frameworks als packed voor. Nee, nee, snap ik, ja. Het idee is wel een vergelijking. Hetzelfde, ja, klopt. We hebben het wel gedaan bij voorgaande klanten, dat we wel, zeg maar, vooral third-party services waar we weinig controle over hebben. Dus, want wij maken ook zelf onze eigen backends, vooral bij de NS hebben we dat erg veel gedaan. Maar er waren een aantal third-party diensten waar we geen controle over hadden, waar we toch wel gewoon, zeg maar, checkscriptjes hadden om te checken van, één, doet hij het wel? En twee, wat is er gebeurd, zeg maar? Dat soort dingen zijn best wel essentieel, zodat je gewoon snel kan inspringen, in plaats van dat je in reviews in je app store of een Google Play had lezen, van deze functionaliteit binnen jullie app, doet het niet meer, pot voor dory. Dus je moet dat soort dingen wel goed in de gaten houden. Ja, klopt. Ja, een leuk iets is altijd, als je gebruikers eerder weten dat er iets met je app aan de hand bent, dan jijzelf, dan is er ergens nog iets te verbeteren. Ja, absoluut. Ja, en één van de, ik denk ook wel dat het belangrijk is, dat we ook weer bij de NS geleerd is, dat we eigenlijk overal wel onze eigen proxie of aggregated service tussen zetten. Want op het moment dat een third party of een API waar wij geen controle over hebben, iets verandert, dat we nog dingen kunnen fixen zonder dat onze gebruikers er last van hebben. Want je kan inderdaad niet iedereen dwingen om per direct een nieuwe versie neer te zetten. Dus dat is toch wel een les die we in het verleden hebben geleerd. Je wil altijd zeg maar, de laag tussen je app en je back-end, daar wil je toch wel bijna absoluut controle over hebben. Wil je gewoon stabiele app ervaring hebben. Ja, klopt. Ja, precies, want dat is wel een, kijk, ik kom heel erg uit die web, weet je wel. Ik heb vaak met web applicaties te maken, gewoon heel erg. Ik heb heel weinig met mobile apps te maken, maar dat is gewoon een hele andere manier van denken over hoe je software moet uitrollen. Want inderdaad, wat je zegt, op een gegeven moment kan je inderdaad mensen gewoon niet dwingen, van, joh, je moet over. Want ook met die oude versie, of meuken wilde ik bijna zeggen. Moet het blijven, moet het blijven. Moet het gewoon blijven werken. Ja, precies, dat is het. Ja, en dan zijn er wel mechanismes te verzinnen dat je een gebruiker een notificatie kan sturen of een melding in de app, maar dan nog, mag je er niet van uitgaan dat je altijd alle gebruikers op een bepaalde versie zitten. Ja, jullie zijn al acht jaar samen, toch? Toch, zeiden jullie net, hè? Vanaf 2013 ontwikkelen wij samen, inderdaad. Ja, ja. Hebben jullie misschien wel ergens een gouden tip om dat goed te doen, zeg maar? Om acht jaar samen te kunnen werken? Ja, dat sowieso. Hoe hou je het vol? Laten we daar eens mee beginnen. Hoe hou je het vol? Vooral leuke en uitdagende dingen blijven doen, denk ik. En mekaar scherp houden en van elkaar leren. En ja, ik denk dat dat wel een belangrijke is. En het moet ook klikken, natuurlijk. Vooral ook openstaan, zeg maar, voor andermans ideeën, weet je? Je bent er om te leren. En op het moment dat je van elkaar kan leren, dat is gewoon goud waard, eigenlijk. Ja, klopt. Je kan niet alles zelf weten of doen. Nee, de kracht van het samenwerken, dat is groter dan het individief, denk ik. En dat is misschien ook wel het mooie, omdat je toch wel twee soorten verschillende technologie hebt. Ook al lijkt het enorm veel om elkaar, krijg je toch wel nieuwe inzichten over hoe jij het gedaan hebt. Weet je, je doet het toch een beetje in een andere taal, of net een andere manier. Maar je leert er echt enorm veel van elkaar. En je ziet ook wel bijvoorbeeld dat, volgens mij, Android begon eerst, geloof ik, met Compose, een beetje achter, of tenminste, Jamie is begonnen met Flutter, bijvoorbeeld, van Google. En de manier waarop, Apple begon later met SwiftUI, toen kwam Compose ongeveer, en dan leer je toch wel, ze vonden het toch wel zo heel gaaf, de manier waarop schermen werden opgebouwd en zo. Het is een hele andere manier van werken, en dat beginnen we een beetje hierover te nemen. En we hebben ook een tijdje met Rx dingen gaan, reactive programmeren. Ja, het is gewoon super gaaf om dat te ontdekken, en dat in verschillende technologieën, zeg maar, allemaal een beetje op dezelfde manier, uiteindelijk toe te passen. Ja. Oké, en stel dat een van jullie zoiets had van, nou, ik ben er klaar mee, ga je dan ook gelijk weg? Gaat de ander dan gelijk weg? Dat weten we nog niet. Hebben we nog nooit meegemaakt? Dat moeten we nog ervaren. Oh, dat moeten we nog ervaren, oké, oké, kom, kom, kom. Ja, ik ben helemaal nieuw. Nee, we hebben eigenlijk altijd wel in de luxe positie gezeten dat we alle projecten eigenlijk wel samen zijn begonnen, en ook afgeronden, zeg ik. Oké, nice, ja, ja, dat is wel mooi. En dan eigenlijk, als we compleet willen zijn, ook met nog drie anderen, zeg maar. Ja. Het is een team van vijf in totaal. Ja, oké. Ja, zeg maar, het team van vijf bestaat uit een designer, UX-designer, maar die ook, zeg maar, heel sterk is in visie. Android, ook een goede full-stack-ontwikkelaar. We hebben nog een iOS-dame erbij, die ook Android kan. Ook nog eens een keer back-end kan. Ja, en de grap is eigenlijk dat je dan... Dus je bent eigenlijk een team of five. Ja, we zijn een team of five en we kunnen gewoon, zeg maar, makaars code leren. We zijn af en toe wel eens boos op elkaar geweest. We hebben het uitgesproken, weet je. We hebben alle ellen wel een keertje gehad, dus we kennen elkaar hartstikke goed. Ik wil bijna zeggen, we zijn misschien een beetje familie of zoiets. Ja, ja, ja, dat voelt het wel even wel. Zoiets, maar het fijn is, maar natuurlijk ook het lastige, als andere mensen erbij komen, is dat natuurlijk, wij hebben aan een halve woord genoeg, dan weten we ongeveer wat we bedoelen en waar we naartoe gaan. We weten wat we van elkaar verwachten. We weten hoe ver we kunnen gaan of niet. En dat is als buitenstaande, is dat natuurlijk misschien af en toe een beetje lastig. En daar moeten wij zelf ook erg op letten. Ja, dat komt voorzellig. Dat we andere mensen opstaan en meenemen en... Ja, precies, want kijk, de organisatie is natuurlijk groter dan jullie. Klopt, klopt. Dus dan moeten jullie dan ook wel een beetje rengaan en gewoon dat je de rest natuurlijk met je mee... Want je laat natuurlijk wat achter op een gegeven moment. Ja, en dat is ook het doel die samenwerken in de overdracht. Oh ja, maar wel leuk om te horen trouwens, dat jullie dan zo als familie, zeg maar, tussen kotjes, dan ook bij verschillende grote organisaties jullie dingen kunnen doen en blijkbaar ook succesvol. Nou goed, ik had blijkbaar de vraagstellingen een klein beetje anders kunnen stellen, want mijn vraag ging eigenlijk meer over, want ik vond het wel interessant wat je net zei, over Dus dat je die gebruikers die die nieuwe update niet naar binnen willen halen, want dat kan ook, dat ik het gewoon echt niet wil bijvoorbeeld, hoe je die dan zeg maar in de gaten houdt, want ik kan me voorstellen dat dat ook wel een complexe situatie veroorzaakt in jullie architectuur, in de manier waarop jullie moeten testen, et cetera. Hoe gaan jullie daarmee om? Is dat gewoon zo simpel als... Natuurlijk, we hebben gewoon twee verschillende versies, dus twee verschillende manieren van bouwen. Kunnen jullie daar iets over vertellen? Ja, zeker. Daar zijn verschillende strategieën ook in te bedenken. Als we bij de Nederlandse spoorweg kijken, hadden we daar verschillende strategieën. Daar was het bijvoorbeeld zo dat een bepaald stukje functionaliteit, daar konden we een check op zetten vanuit de backend die dan aangeeft, je moet je appen updaten, anders werkt dit stukje niet meer. Dat is een mogelijkheid om het te forceren, maar als dat niet aanwezig is, dan moet je er eigenlijk vanuit gaan dat je oude apps moet blijven ondersteunen, want anders kan het ook weer een negatieve review natuurlijk in de store tot gevolg hebben. Maar op een gegeven moment moet je ook kijken naar hoeveel gebruikers zitten nog op een bepaalde Android of iOS versie, dan besluit je om een bepaalde versie wellicht niet meer te ondersteunen. Ja, en dat is aan jezelf om te bepalen wat is acceptabel. Ja, want ja, dan kom ik toch even terug op het test. Jullie zitten altijd in de podcast host die het meeste gaat over testen. Maar ik ben al nieuwsgierig van hoe doe je het dan bij de ANWB nu met al die verschillende Android versies? Hebben jullie daar ook al een strategie over? Ja, wat we voornamelijk proberen is het aantal versies te limiteren. Een voorbeeld is dat we iOS 12 en 13 aan het droppen zijn. Want we weten dat mensen die daar op zitten, kunnen upgraden naar de nieuwe versies 14 en 15. Dus we kijken echt naar het percentage inderdaad van hoeveel mensen heeft nog iOS 13. Oh, dat is nog maar 3 procent ofzo. Kunnen mensen zelf zeg maar een nieuwe versie van Apple iOS installeren? Ja, oké, dan kunnen we tegen zeggen als ze graag onze app willen gebruiken, dat ze moeten upgraden eigenlijk. Wat natuurlijk ook wel beter is vanuit de security oogpunt, maar dat terzijde. Maar goed, we hebben nu alvorens netjes een antwoord dat mensen nog steeds spullable kunnen blijven gebruiken. Oké, dat klinkt ook wel eens een goede aanpak, want dat lijkt me echt een hell als je... Het is niet alleen de verschillende versies, maar ook de verschillende devices ook nog eens een keer, verschillende screen resoluties. Gelukkig qua CPU-architectuur, ik weet nog wel dat ik op een gegeven moment ergens een bug had, per ongeluk omdat ik een te groot nummer in een instopte op een 32-bit ARM-CPU. En er werd afgekapt en ik snapte er helemaal niks van, want op mijn telefoon het wel deed, maar op een iPhone 5 deed hij het niet. En ik snapte er echt niks van, weet je, dat soort dingen. iPhone 5 ook, hè? Als je dat soort dingen achter je kan laten, dat soort dingen is heel fijn. Want je hebt zoveel verschillende devices heb je allemaal nodig, waarin het allemaal getest wordt. Dus hoe minder hoe beter. Je moet altijd vooruitkijken. Je kan nooit alles blijven ondersteunen. Want het is zo'n constellatie van verschillende dingen, en dat heb je natuurlijk op web ook wel een beetje geklopt. Zeker, ja. Want waar ik dan over het algemeen te mee te maken heb, is ook inderdaad die verschillende machines, maar ook verschillende browsers en versies. Versies wat minder, hoor. Meestal doen we de laatste versies. Maar ook daar dan, dan maken we toch wel gebruik van clouddiensten. Doen jullie dat ook? Dus een browsers stack of andere, weet je wel, andere verschillende providers die in de cloud die mobile devices aanbieden? Bij NECOD doen we dat volgens mij wel. Bij ANWB dacht ik dat er ook eens gekeken naar browsers stack, maar dat doen wij nog niks actiefs mee op dit moment. Oké, nou ja, dat kan, hè. Blijkbaar is dat nog goed genoeg om het niet te gebruiken dan, toch? Want ja, dan hebben jullie blijkbaar toch iets goed neergezet, waar niet heel veel klachten... Ja, dat is het. Dat is altijd zeg maar de afweging, van hoeveel klachten kunnen we het oplossen nog steeds met onze unit-testen, integratietesten, een soort snapshot-testen, inderdaad, UI-testen. En op het moment dat de spuigaten uit beginnen te lopen, of dat het te erg hoort, of dat we bepaalde dingen gewoon misschien iets te vaak kapot gaan, dan gaan we gewoon kijken hoe we dat gewoon kunnen oplossen. En ik denk dat het ook op zich wel een gezonde manier is van hoe je omgaat met testen, want sommige dingen zijn heel evident. Die zijn misschien te simpel. Dat zeg ik als ontwikkelaar. Super link, natuurlijk. Ja, ja, ja. Maar vaak als ontwikkelaar denk ik van oh, dat is wel best wel complex, dus daar ga ik gewoon net zoveel testen voor schrijven, want dat kan makkelijk kapot gaan, of het is niet heel duidelijk hoe het in je status als iemand anders hier aan gaat zitten, dan kan het omvallen. Maar ik weet ook wel, zeg maar, in mijn vorige projecten dat twee of drie keer dat iets stuk was gegaan, denk ik van nou, dit moeten we gewoon goed gaan testen. En iedere keer dat we een nieuwe versie maken en in de App Store zetten, moet het gewoon netjes groen door die test heen komen. Want ik wil niet weer een hotfix uit gaan brengen of iets dergelijks. Nee, tuurlijk niet. Ja, ik denk dat dat niemand zou willen wensen. Oké, nou, het lijkt me ook wel een leuk bruggetje wat we nu kunnen maken. We hadden het net eventjes over van, ja, hoe zorgen we nou voor dat al die verschillende mobile devices, zeg maar, blijven werken met de features die jullie bouwen? Nou, hebben jullie zelf al verteld dat jullie Native en Kotlin gebruiken om multi-platform voor iOS en Android te bouwen? Klopt. Hebben jullie, ja, wat zijn nou de voordelen als je op die manier gaat werken? Bij de ANWB gebruiken we deze technologie nog niet. Bij NECO hebben we deze wel toegepast. Dat komt eigenlijk uit als we een stapje teruggaan in de tijd, waar wij aan de basis hebben gestaan van de NS Reisplanner. Dat zijn natuurlijk ook twee Native apps, iOS en Android. Maar het nadeel blijft natuurlijk maken van twee apps dat je dingen twee keer doet. Je bent twee keer je code aan het schrijven, je moet twee keer testen, je introduceert in twee platformen, kun je issues introduceren, et cetera. Dus we zijn eigenlijk een beetje aan het nadenken gegaan. Want de voordelen van Native zijn natuurlijk heel veel. Hoe kunnen we dat nou op een andere manier een betere manier doen? In die tijd is ook Kotlin multi-platform ontstaan, een technologie gemaakt door JetBrains, waarbij je toch Native kan ontwikkelen, maar toch ook code kan delen over beide platformen heen. En sterker nog niet alleen iOS of Android, maar ook het web, back-end en ook desktop Native apps. Bij NS zijn we daar al een beetje mee aan het experimenteren geweest. Het was nog net te vroeg om daarmee aan de slag te gaan. Dus drie jaar geleden hebben we aan de basis gestaan van de nieuwe NECO-app die nu in de store staat. En daar hebben we wel de keuze gemaakt om het met de Kotlin multi-platform mobile te doen, waarbij we eigenlijk business logica code kunnen delen over twee platformen heen. En voor diegene die Kotlin nog niet kennen, zou een van jullie misschien kunnen uitleggen waar het vandaan komt en wat het is? Kotlin is een taal die in 2011, als ik het goed heb, versie 1 is uitgekomen, ontwikkeld door JetBrains als alternatief voor Java, als een eenvoudigere language. Null safety, concise, met functionele aspecten erin. Het heeft eigenlijk echt een enorme vlucht genomen toen Google aankondigde Kotlin wordt de first class language voor Android in plaats van Java. En daarna is het echt in vorenvlucht gegaan. En waarom denk je dat Google zoiets heeft besloten? Hebben die al zo diep het onderzoek? Nee, niet zo diep onderzocht, maar waarschijnlijk ook omdat de taal een hoop voordelen biedt ten opzichte van Java. Ik weet uit de rapport van Google dat het aantal questions door gebruik te maken van Kotlin sterk verminderd wordt in Android apps en dat kunnen ze analyseren natuurlijk in de Play Store in Crashlydics. Maar dat zagen wij zelf ook en dan voornamelijk het aantal nulpointer exceptions wat drastisch minder is, omdat Kotlin een nul safe language is. Dat wil niet zeggen dat je het niet kan krijgen, maar het is een stuk minder dan op Java. Is het niet omdat ook Oracle en Google op een gegeven moment een juridische strijd om Java waren begonnen in Android? Dat zou kunnen, dat zou kunnen, ja. Maar goed, daarnaast, ik bedoel, ik vind Kotlin echt veel betere taal dan Java, ook al heb ik zelf een tientallen jaren ervaring in Java. En zou je daar een voorbeeld in kunnen geven of wat je er beter aan vindt ten opzichte van Java? Goed, vanuit iOS doe ik al best wel lang Swift en eigenlijk bijvoorbeeld die nul safe, die type inference, dat soort dingen, dat heeft Kotlin ook allemaal. Dus voor mij was het gewoon een soort van warm bad waar ik in terecht kwam eigenlijk. Van oh, Kotlin heeft dat ook, alleen de syntax is net even anders en het heeft bepaalde dingetjes werken net even anders. En er zijn een paar prachtige cheat sheets, voorals je als iOS ontwikkelaar Swift Kotlin ineens wilt doen, dan kan je zeggen van nou, ik wil dit doen, ik wil een lijst aanmaken, hoe maak je een lijst in Kotlin aan, of hoe verander je je werk, data classes of iets dergelijks. Het voelt gewoon, zeg maar, modern, nou, dat niet alleen, maar het voelt ook gewoon, zeg maar, ongeveer hetzelfde. Dus, zeg maar, wat je in Swift kan doen, kan je ook in Kotlin doen en ongeveer vice versa. Klopt, klopt. En het lijkt wel, af en toe doe ik nog wel eens dingen in Java hoor, dat, dat ben je toch, ja, Kotlin voelt, alsof het een minder cognitieve overhead heeft dan Java. Het gaat allemaal vanzelfsprekend. Wat je zou willen maken, dat maak je in Kotlin, zonder daar echt een hele hoop boilerplate code voor nodig te hebben. Ja, ja, oké. Ja, dus dat is het punt dus meer. Ze zorgen voor dat het alle boilerplate voor je al geweg geabstrijd is. Voor een groot deel, ja. Oké, oké. Ja, nice. Zijn er nog andere voordelen die, stel dat je inderdaad iOS en Android moet gaan supporten, het voordeel van Kotlin ten opzichte van native bouwen. Ja, wat je eigenlijk met Kot in een multi-platform doet, je bouwt ook echt native, maar je maakt eigenlijk een geshared en shared kodelaar, die bouw je in Kotlin. In Android kun je die gebruiken als zijn de native library. In iOS wordt die gecompileerd naar een framework en kun je hem dus ook gebruiken als a native library. Dus dat is eigenlijk gewoon een native app, een native stukje code wat je maakt, maar dan wel gedeeld over beide platformen. Ah, oké. Dus je hebt je business logica kun je delen. We zijn bij InEco begonnen met Kotlin Multi-platform en in eerste instantie deden we de business logica, de HTTP request, de object serialisatie vanuit de server, allemaal in common code. Dus dat werd allemaal gedeeld over beide platformen. En daarnaast zijn we zelfs ook de shared resources, zoals de labels en de teksten en de images, maar zelfs ook de view models gaan schrijven in Kotlin Multi-platform, zodat je eigenlijk alleen nog maar een ui laag overhoudt in je echte iOS en Android app. Ja, en ik denk dat je het een beetje inderdaad zo moet zien van die view models, die spreken gewoon zeg maar een view aan. Die vertellen eigenlijk welke teksten erop moeten komen en dat staat op de view die je bijvoorbeeld in SwiftUI of in Compose maakt. Deze knop, die doet iets en die knop roept dan weer je view model in Kotlin aan, die vervolgens misschien een HTTP request doet. Maar het is allemaal Kotlin en het is allemaal dezelfde code. En dus dat betekent dat je maar één keer de bug of the fixen in plaats van twee keer en dat je geen platform verschillen hebt, wat natuurlijk hartstikke fijn is. Hoep, hoep. Ja, het klinkt als een beetje de backend voor een frontend, toch? Ja, klopt. En sterker nog, je kan het nog mooier maken door dat je bijvoorbeeld je domein modellen, want het is Kotlin, kan je ook nog eens een keer op de server draaien. Dus je hebt, zeg maar, je Kotlin op de server, je hebt de Kotlin op je clients heb je draaien. Dus ja, shared code. En volgens mij, de eerste die daar echt een beetje mee begon was Spotify, met geloof ik z'n C en z'n C++ libraries voor Android en iOS. Volgens mij hadden ze het ook op een gegeven moment gebruikt op de server. En toen dacht ik van, ja, dat is toch wel echt heel cool, dat je dan dat kan doen. Alleen ja, vervolgens heb je natuurlijk, toen werd nog Android in Java gedaan, dus dan had je Java en C in C++ en dan had je Objective C voor iOS. En dan had je ook weer C in C++ en dan dacht ik van, nou, misschien wil ik dat niet. En dan lop je weer met de memory allocation, mallocks, de rotzooien en zo. Nou, dat is misschien nog wat te complex, maar zoals ik al zei, weet je, Kotlin is de eerste langage voor Android vanuit Google. En het lijkt enorm veel op Zwift. Ja, het is gewoon een hele goede fit. Ja, want is er nog veel competitie in dat veld? Want ja, tuurlijk, wat je zegt, het klinkt ook heel logisch. Ja, weet je wel, dat wil je. Maar zijn er ook na Kotlin nog andere concurrenten die dit soort dingen bouwen? Multiplatformen, dat betekent. Ja, ja, er zijn eigenlijk wel een hoop aanbieders waarmee je met één codebase meerdere platformen target, denk het aan Flutter, React Native, vroeger had je Cordova natuurlijk om webapps te maken. Verschillen is dat met Kotlin Multiplatform je nog steeds echt native aan het werk bent. Er is geen interpreter, er is geen runtime aanwezig in je app. Het blijft allemaal native en dat is een grote voordeel. Ik wil niet zeggen dat die andere technologieen niet goed zijn ten opzichte van dat. We hebben ook in use cases, maar voor grotere apps zoals NS en Neko en potentieel ook bij de ANWB die een langere lifecycle hebben, niet dit echt wel voordelen en ook de manier van integreren. Ja, precies. Ik snap dat wel, want wat mij wel best wel raakt en ook wat ik nu wat van geleerd heb, is dat je het inderdaad, je ontwikkelt het. Het kan zowel iOS als Android, noem het maar even gecompileerd worden in een package of iets dergelijks, vermoed ik. Ja, in een library. In een library en dan kan je het weer importeren in de native app en die dan weer gebruiken. Precies, je kan het gewoon direct aanspreken. Er zit geen bridge tussen of een bepaald laagje. Je hoeft niet een plugin te maken of iets dergelijks. Het is gewoon per direct is het gewoon beschikbaar. En gelukkig, het bestaat nou al jaren, dus het is wel redelijk stabiel en robuust. Toolsupport is, nou ja, JetBrains zit erachter van IntelliJ. Dat zijn toch wel echt serieus goede tools. Dus bijvoorbeeld voor mijn iOS ontwikkeling, ik gebruik app code vooral van JetBrains. Xcode gebruik ik niet zo heel vaak omdat ik gewoon de refactoring heel erg mis. En ik vind het ook heel fijn dat ik gewoon dezelfde tool suite heb over mijn backend ontwikkeling en frontend ontwikkeling. En dezelfde shortcuts en dat soort dingen allemaal. Ja, tuurlijk. Weer gaat het over developer experience. En dat is denk ik waar JetBrains heel goed in is. Die houdt daar echt wel gaan rekening mee. Klopt, klopt. Ja, en ja, een beetje een, misschien wel een moeilijke vraag voor jullie om te beantwoorden, maar zijn er ook nadelen die jullie al gezien hebben, waarvan jullie onze luisteraars toch een beetje op de hoogte willen houden? En misschien ook wel een tip om daarmee om te houden. Ik zal als eerste het eerste grote nadeel wat ik ondervond met Kotlin Multiplatform. Maar gelukkig heeft ze dat wel grotendeels gefixt. Die compiler was zo ontzettend traag. Oké. Ik was al gewend dat de Swift compiler af en toe traag is. Want bijvoorbeeld voor de grotere apps ben je toch wel minuten aan het compiler af en toe. Nou, in het begin met Kotlin Multiplatform was dat toch wel bijzonder pittig. Ik denk ook voor iOS ontwikkelaars om toch wel even een andere taal erbij te nemen waar ze niet wat nieuw voor ze is. Dat is toch wel eng en lastig. Dus je moet er wel over open kunnen staan. Dat was toch ook wel heel erg vervelend. En ik denk ook dat als je niet... Onze ervaring was dat het werkte heel goed om met Kotlin Multiplatform te werken op het moment dat we gebruik maakten van trunk-based development en een mono-repo. En dat wil zeggen dat we hadden een bug, die fik je dan en vervolgens zie je gelijk welke app kapot gaat. Omdat die daar nog geen... Omdat je een bepaalde interface verandert. Dus je wil heel snel feedback hebben. Je zou denk ik niet echt goed rond kunnen komen door een soort library te maken die dan ergens te publiceren en die dan één keer in de week binnen te trekken ofzo. Dat zou ik niet doen. Ik zou gewoon lekker voor een mono-repo gaan, trunk-based development en zorgen dat je heel snel feedback krijgt erin op het moment dat je dingen aan je netwerking en je serialisatie en je viewmodels, je business logica gaat veranderen. Ja, en je zegt nu trunk-based development. Ik heb daar ooit een keer een andere aflevering ook... Of was het nou met een ander... Dus had ik daar een best wel lange discussie over. Beteekent dat ook voor jullie dan dat je dan op een gegeven moment ook geen poolrequest en zo weer maakt, dat soort zaken? Oké. Klopt, ja. Ja, en ja, misschien open... Ik denk wel dat ik het antwoord weet, maar ik vraag het even aan jullie. Ik ben nieuwsgierig naar jullie mening. Maar hoe... Kijk, die poolrequest die zijn natuurlijk bedoeld om elkaar scherp te houden op, weet je wel, fouten die we misschien maken, die je een ander misschien sneller ziet. Hoe ondervang je dat dan? Het hangt van je volwassenheid, van je team af. Kijk, als je een onvolwassen team hebt waarbij mensen graag zelfstandig werken, dan gaat trunk-based development niet werken, denk ik. En dat bedoel ik van je maakt wat en je dient, zeg maar, hetgene wat je hebt gemaakt. Of het is zo simpel en iedereen... Je denkt dat iedereen het wel begrijpt, maar je dient gewoon, zeg maar, wat je hebt gemaakt. Te delen met de rest van het team of een aantal andere mensen om gewoon dingen te laten zien wat je hebt gemaakt. En vaak is het zo met een pull request het branchen en vervolgens weer merging met dingen. En dat duurt gewoon te lang. Ik wil gewoon zelf persoonlijk heel graag snel feedback hebben. Net zoals mijn compiler me direct vertelt als iets kapot is of als iets niet goed is, vraag ik ook de mening van anderen van is dit goed, ja of nee. En dan op het moment dat je dan trunk-based development doet, je gelijk merge, zeg maar, je changes op develop, bijvoorbeeld, en je automatische testen gaan af en je weet gelijk of het, zeg maar, bijna productiewaardig is of niet. In plaats van dat je een langere lifecycle eraan vast hebt zitten met een branch. En wat het voordeel is, als je multiplatform werkt op deze manier, kijk, als je alles native doet en je houdt iOS en Android gescheiden, dan heb je eigenlijk twee apps waaraan je ontwikkelt. Bouw je een common laar die beide apps gebruiken, dan krijg je ook automatisch de interactie tussen iOS en Android. Dus de integratie wordt daarmee vanzelf ook beter. Dus ik denk dat het ook positieve effect heeft op beide apps, op functie tijd die je oplevert, omdat je toch met meer met elkaar moet communiceren. Het moet sowieso, maar dit is een gevolg daarvan. Ja, klopt. Ja, want ik mis inderdaad de tijden dat, ik weet nog wel dat mijn eerste baan was, toen werkte ik bij een bedrijf dat heette Music from an L. En die bouwde in PHP een concert agenda, weet je wel. Ik miste inderdaad de tijden van dat je dus inderdaad gewoon echt op de server waar al die PHP scripts stonden, dat je daar gewoon je dingen in ging coderen. En dan drukt hij op save en dan was alles goed of fout. Maar ja, weet je, ik mis die tijd ook wel, maar aan de andere kant zie ik ook wel weer ja, precies wat jij zegt net, van als je toch te maken hebt met mensen die wat minder ervaren zijn, of die zitten nog in de leerkeur om een goede developer te worden, dan kan ik me wel voorstellen dat mensen dan pull requests introduceren. Weet je, gewoon om even die, hoe noem je dat? Een barrière toevoegen. Nou, barrière is het niet meteen, maar ik zie het niet meteen als barrière, maar het is meer een soort van incheckmoment met degene die jou iets zou kunnen leren. Ja, je zou ook kunnen perren natuurlijk, als al die van pull requests, om het echt samen te doen. Ja, dat vind ik ook eigenlijk, dat is gewoon veel beter natuurlijk, dat je gewoon samen aan iets werkt, weet je wel, perprogrammen. Ja, afgelopen tijd wat bij de ANWB hebben ook pull requests, maar onze pull requests gaan tegenwoordig echt heel snel, omdat we van tevoren even mekaar slakken, want we werken remote. Ja, precies. Precies. En we hebben gewoon een gesprek over de dingen die we hebben aangepast. We laten mekaar eens code laten we gewoon zien, en je weet gewoon het verhaal eromheen. En dat is veel beter dan dat je naar een pull request kijkt, en je ziet een snippet van code, en je denkt van, waarom is dit gedaan? Wat is het verhaal eromheen? Waarom heeft iemand een bepaalde naamgeving gebruikt, of een bepaalde constructie gebruikt? Je kan het er dan even over hebben, en je leert van mekaar, en je komt tot nieuwe inzichten, en soms denk je van, nou, wat is dit voor een rare ding? Maar iemand zegt, ja, ik kwam er gewoon niet uit, of ik weet gewoon geen betere oplossing, en misschien weet ik dat zelf ook niet. Ja, dan kan het zijn dat het gewoon zo blijft, weet je. Dat is veel waardevoller dan dat je een pull request aanmaakt, en dat je naar kleine stukjes code gaat lopen kijken, waar je gewoon heel veel dingen mist. Dus de menselijke interactie is superbelangrijk. Ja, nee, mee eens. Helemaal mee eens. En sterker nog, inderdaad, om dit systeem te cheaten, zeg maar, want zo zie je, dat doe ik dus ook, is inderdaad gelijk contact maken met diegene die die pull request moet reviewen. Dus met andere woorden, misschien daarvoor al. Van, hey, ik ga je zometeen een pull request maken, maar zullen we dan even snel door die code heen kijken, zodat je even die pull request snel kan accepteren. Ja, klopt. Ja, dat werkt gewoon veel beter, weet je. Nee, maar even voor alle duidelijkheid, ja, ik ben ook inderdaad, ja, ik zeg het niet meteen, dat schurft echo app aan pull request, maar inderdaad, ik ben er niet geen fan van of zo, weet je wel. Ik vind het ook inderdaad, het stagneert gewoon heel veel productiviteit. Want op een gegeven moment kom je erachter, dat de ander dus inderdaad bezig is met iets anders en niet meer focus houdt. En dan krijg je ook, worst case, is dat je dus een hele slechte review krijgt. Dus dat iemand zomaar zegt, oh, zo al, ik moet toch aan iets anders aan de gang. Ja, dus het kan misschien nog wel meer kapotmaken dan je lief is. Maar ja, goed, kijk, weet je, wat dat betreft, ik vind het ook wel mooi dat snelle feedback loops proberen te creëren om dat stand te houden, weet je, en daar misschien meer over te hebben, dan dat of het wel of niet met een pull request moet of zo. Ja, precies, dat is het, snelle feedback en gewoon leren. Precies. Want je bouwt een product en je bent er om te leren, leren over de code, leren over de business, leren over je klanten allemaal om gewoon het beste product uiteindelijk te maken. Ja, absoluut. Nee, dat is het zeker. Ik heb hier ook nog een vraag rondom Kotlin Multiplatform en Native Development. Maar misschien hebben we daar ook wel wat al over gehad. Bernard, die kwam hier met een vraag hoe het proces verloopt van met die Multiplatform coderen. En het eigenlijkste achterlichtende vraag is, maak je wel optimaal gebruik van de hardware mogelijkheden en de GUI-mogelijkheden van alle platformen? Goede vraag, goede vraag. Ja, doordat je met Kotlin Multiplatform werkt, werk je eigenlijk nog steeds native, dus je hebt de volledige beschikking tot de mogelijkheden van je native device. Daar zit geen abstractie op, dus die kun je altijd aanspreken. En ook alle nieuwste versies van de OS'en, daar is geen beperking op. Nee, want ik neem aan dat dan Kotlin intern dan ook allerlei libraries importeert om iOS en Android functieeliteit te bieden. Die bieden een zogezegde interface aan in je common laag tot de native functieeliteit. Bied die laag niet datgene wat je nodig hebt, dan kun je met zogezegde actual and expect functies in Kotlin je echte native code aanroepen in je target platform, als het ware. Cool. Dus je schrijft geen bridge, maar je roept echt de native code aan. Dus ik definieer een functie in Kotlin Multiplatform, generer een ID. Die kan ik op Android implementeren en op iOS, maar vanuit native code kun je die dan aanroepen. En afhankelijk op welk platform je draait, heb je de een of de ander. Nice. En unit testing rondom Kotlin Multiplatform, moet je daar nog ergens rekening houden, of is dat ook allemaal een hetzelfde, zeg maar, voor Multiplatform? Dat is vergelijkbaar. Je kunt je unit tester schrijven in je comment laag, dat moet je ook doen, en die draai je dan op een target platform, bijvoorbeeld Android of iOS, of beide. Dat is een keuze. Het voordeel is, met die unit tester test je dus je gezamenlijke code, zowel op Android als iOS. Ja, ja, ja, oké. En wat zou dan een goed pad zijn om, want jullie zijn natuurlijk nu bij ANWB Native aan het coderen, dus wat zou jullie pad zijn om richting Kotlinck te gaan? Er zijn verschillende strategieën waarmee je daar tot komen, dat is op zich al mooi, want ik heb in de verleden wel eens gezien, er zijn dan twee Native apps gebouwd en dan wordt er een beslissing gemaakt, nee, we willen toch een cross-platform technologie, bijvoorbeeld React Native, ik noem maar een voorbeeld. Omdat die twee niet compatibel zijn, ben je eigenlijk je complete app opnieuw aan het schrijven in een nieuwe technologie. Bij Kotlinck Multiplatform heb je de mogelijkheid om zelfs in je bestaande app bepaalde delen gefaseerd over te brengen naar een common library, zodat die meteen gebruikt kunnen worden in bijvoorbeeld iOS. Stel, je hebt twee bestaande Native apps. In Android zet ik de domeinobject of mijn domeinlogica om naar mijn common code, en dat is eigenlijk een kopie van de Android code naar de shared code, omdat dat allebei Kotlin is en je hebt meteen een gecompaald framework voor iOS. Wellicht moet je wat platform-specifieke dingen refactoren, maar daarmee kun je dus een bestaande app, afhankelijk van wat je wel en niet wilt delen, geschikt maken voor Kotlin Multiplatform. Andere strategie is, we maken, als je een nieuwe app begint, kun je kiezen, we maken Android en iOS tegelijk met de gezamenlijke laag, of we beginnen eerst met Android met de gezamenlijke laag en we sluiten iOS aan, dus je bent daar heel flexibel in om daar een keuze in te maken. Ja, ja, dus je doet het eigenlijk gefaseerd, dat is een beetje wat ik... Het kan gefaseerd, als je een nieuwe app maakt, dan doe je het in één keer. Ja, natuurlijk. Maar een bestaande app kun je inderdaad gefaseerd overbrengen. Ja, dat was eigenlijk meer de vraag, want daarvoor dat je Native inderdaad veel al gebouwd hebt en je wil... Ja, daar kun je het meeste hergebruiken over bij de platformen. Ja, dat is natuurlijk wel een krachtig framework dan, want dan kan je inderdaad al het bestaande gewoon laten staan en dan alle dingen die je hebt uitgereffecteerd weer toepassen in iets anders. Ja, oké. Nou, dat klinkt als een hele goede aanpak, lijkt mij. Is dat ook iets waar jullie nu mee bezig zijn, of mogen jullie dat niet zo zeggen binnen de ANWB? Ja, Kotlin Multiplatform zijn we nog niet concreet mee bezig. Ah, oké, ja. We zijn wel aan het kijken hoe kunnen we het toepassen, maar dat is nog te vroeg om daar wat... Ja, oké. Oké, nou goed. Mooi. Nou, dan... Ja, ja, we zijn nu eigenlijk al een uur, bijna anderhalf uur lekker aan het podcasten. Ik zou willen voorstellen om even door te gaan naar onze vaste rubrieke van de podcast. Nou, we hebben ook in onze rubrieke, proberen we altijd een beetje Twitter in de gaten te houden van wat er allemaal gebeurt en speelt. En nou had Bernard één onderwerp genoteerd, dat heette Temple OS. Ik heb er nog nooit wat van gehoord. Hebben jullie al iets van gehoord, wat er op Twitter nu aan gaande is en wat het is? Ik heb Twitter niet in de gaten gehouden, maar toen ik het hoorde, heb ik even op YouTube gecheckt. En toen zag ik een prachtig video van Linus Tech Tips, erover. Hetgene wat mij het meest bij stond, is dat het een OS is. Het deed me een beetje denken aan een prachtige DOS, oude Norton Commander DOS, maar dan met allemaal funky kleurtjes. Maar blijkbaar, als je op F7 drukt, dan krijg je een een woord uit de Bijbel. En als je op Shift F7 drukt, krijg je, geloof ik, een verhaaltje uit de Bijbel. Het is helemaal een Bijbelachtig OS, wat er heel erg funky uitziet. Oh, ik vind het prachtig dat mensen dat maken. Ik weet niet zo goed wat ik ermee moet. Ja, nee, nee, nee. Ja, wellicht om geïnspireerd te raken, bouwen ze dat misschien. Maar ik dacht echt dat het iets met mobile devices zo was, maar dat is dus niet zo. Het is gewoon echt op je, is het op elke, is het op de Mac alleen of op Google? Ik heb geen blauwe idee. Ik heb geen blauwe idee. Ik durf het niet te zeggen. Nou, het is in ieder geval niet heel erg bekend in deze gezelschap. Geen probleem verder, maar misschien... Ik lig er niet wakker van. Wat voor dood, wat gaaf. Misschien wel een leuke oproep aan de luisteraars. Chat even mee in ons Slack kanaal op CodeKlets.nl. Mocht je er iets meer van weten, laat het ons vooral even weten. Nou goed, ja, ik heb ook nog even een dilemma die ik aan jullie zou willen voorleggen. Voor privé gebruik, he? Maak je nou gebruik van een iPhone of een Android? Ik maak gebruik van een Android-toestel. Echt joh? En jij? Je mag één keer raden. Android, nee, grapje, iPhone. Nee, ik zal even uitleggen. Misschien, volgens mij in 2001 of zo, toen had ik nog een pc en die stond open. En ik moest grafische kaarten veranderen, dat soort dingen allemaal. Mijn vriendin was datapay'er, die deed dingen in grafische dingen. Die had een G4 Mac, had ze. Nou, schitterend, zo'n quicksilver ding. Die stond open, altijd te loeien. Ik heb een keer met mijn voet in die kast van je gestaan en een keer een vonk gehad of zo. Ga nou eens een keer een normale computer kopen. Die staat altijd te rotzooi met drivers en dingetjes en zo. Dus toen heb ik maar een Apple aangeschaft. En sindsdien nooit meer weg. En blijkbaar, als je eenmaal in het ecosysteem zit, dan blijf je erin vasthangen. Dus ja, ik ben gevangen. Ja, precies. Take my money. Weet je wel, maakt niet uit wat het is. Ja, eigenlijk wel. En het is ook niet zo heel goedkoop. En we hebben laatst ook weer behoorlijk wat geld uitgegeven aan die nieuwe M1 Pro. En Jayme heeft een Macs besteld. Hij moet nog binnenkomen. Hij moet nog binnenkomen. Oh, nice. Een weekje wachten. Ja, dat hoeft niet. Wat ga je ermee doen, jongen? Lief helpen. Ja, oké. Maar zonder stroom, denk ik. Of tenminste, niet zonder stroom, maar zonder de power brick. Dan hoop ik, deze laptop gaat ongeveer een uur mee op de batterij. Oh ja. Ja. Dan zal dat hopelijk beter zijn. Zo. Bij ons vak is het hoe sneller, hoe beter. En waarom jij dan de Android phone? Ja, ik ontwikkel Android apps. Dus ik moet wel een Android telefoon hebben. Oké, dus jij bent echt Android fanboy. Dat zouden we op de E-mail later kunnen, natuurlijk, maar... Ja, het is toch niet echt, hè? Het is niet echt, nee. Nee, ik snap het, ja. Trouwens, ik heb twee jaar geleden weer een pc aangeschaft. Wat nu mijn main workstation is. Dat is wel echt... Ik moet eerlijk wat zeggen, ik heb een Hackintosh. Oeps. Oh. Dus het klopt niet helemaal. Nee. Maar... Deze van de machine, want ik dacht van, weet je, ik ben aan het compileren en die laptop van mij staat te blazen en de batterij gaat per uur mee en het schiet allemaal niet op. Ja. Dus ik heb nu een AMD Ryzen Threadripper, 24 cores, 128 GB aan geheugen en 3 TB SSD's erin en een hele dikke videokaart. Oh, het is zo fijn om mee te werken. Ja, ik snap het. Game je ook ermee, of niet? Ja, sindsdien wel. Nou, wat ik dat doe, dat vind ik wel, zeg maar, ik heb een dochtertje van 4, daar spelen we Zelda, tenminste ik speel Zelda en ik heb ook een Wii U, die staat ergens boven op Zolder, maar nu speel ik dus, ik had geen zin om dat spel nog een keer te kopen en zeg maar het aan te sluiten en zo, maar nu speel ik dus via de Steam link op mijn Apple TV, op mijn tv met een PlayStation 4 controller en dan wordt, zeg maar, Zelda wordt gestreamd. Vanuit mijn workstation in 4K via een semi-amulator op Windows 11. Sorry, Windows 10. Ja, Windows 11. Om even een beetje geeky te zijn. En dat ziet er echt zo cool uit. Maar kan je, ik wist helemaal niet dat je Nintendo Wii spellen al op de... Ja, Wii en Wii U. Ja, die kan je gewoon streamen. Ja, die kan je gewoon streamen, maar ik had dus geen zin om de Wind Waker, Zelda, om dat nog een keer aan te schaffen, dus ik heb het al een keer gekocht. Maar het ziet er gewoon echt zo cool uit. En ik vind het zo gaaf dat je gewoon met Steam, Steam Link, zeg maar, games kan streamen en zo. En je kan dus blijkbaar ook dingen buiten Steam, kan je ook gewoon nietjes erin streamen. Ja, het is echt kicken. Ja, tof joh, want als we toch over games hebben nu. Ik was, even kijken, 3 weken terug ben ik op vakantie met mijn gezin gegaan en ik zat lekker op de bank. En ik dacht, ik ga eens een keer Homeworld spelen. Dat is een hele oude game, een space RPG, strategie game. En die speelde ik vroeger, maar ik dacht van ja, weet je, ik wil weer opnieuw herbeleven. Dus ik ging een beetje googelen en inderdaad, ik zag dat die inderdaad op Steam, dan kan je dus op je Mac, kan je dan gewoon die oude game weer spelen. Ja, het is echt geweldig dat dat allemaal nog kan. Maar ja, echt Steam, ik denk dat het echt een van de tofste platformen zijn op dit moment. Want je kan er nu echt zoveel mee. Ik hoorde ook later van iemand dat die inderdaad al die Xbox games ook erop kon spelen en zo. Leuk, leuk. Maar ik wist niet dat Nintendo ook daar... Nou, niet officieel. Officieel niet, ja. Sorry, sorry, sorry. Het is gewoon Hacker Eye. Ja, ik heb ook op mijn Nintendo DS, heb ik ook Scrumviem, heet het volgens mij? Scrumviem? Scrumviem. Ja, Scrumviem. Ja, Scrumviem. Dat heb ik op geïnstalleerd. Vraag me niet hoe, hoor. Maar ja... Voor de rest heb ik wel netjes, hoor. Ik betaal netjes mijn belasting en zo in... Ja, precies. Precies. Belangrijkste, toch? Ja, precies. Ja, ja, ik snap het. Oké. Ja, even door naar de volgende vragen. Want er zijn er al een paar die we door kunnen nemen. Ja, dat is even een... Niet een trick question of zo, maar even jullie beeld. Van wat is nou een fullstack developer volgens jullie? Fullstack developer? Mijn mening is die zowel op de front-end als op de back-end kan werken. Dus je bouwt APIs, je bouwt je mobile apps, je bouwt web-apps. Je kan met cloud, met AWS. Natuurlijk kom je daar niet meteen. Maar dat zou mijn definitie zijn denk ik van de fullstack developer. Dus de hele stack van voor tot achter. En zou dat dan ook iets moeten zijn dat je echt van alles veel moet weten of een heel klein beetje? Dus dat generalist versus specialist zijn in een bepaalde... Ik denk dat je vooral een generalist moet zijn. Natuurlijk heb je bepaalde specialiteiten. Maar als je generalist bent en je weet ongeveer waar je het moet zoeken en die wijzigingen snel aan kan brengen. Dat is super waardevol. Want je hebt minder overdag tussen teams, minder spraakverwarring af en toe. Ik denk dat conceptuele plaatsen ook belangrijk zijn. Als je concepten kent dan heb je ook de mogelijkheid om snel dingen op te pakken. En dat is denk ik belangrijk bij full-stack developers. Dus jullie hebben ook in jullie team full-stack developers of specialisten? Allemaal full-stack developers. Oké, dus die kunnen ook echt in de back-end bouwen, in Spring? Klopt, in Spring, AWS, Ktor met Kotlin, Native Apps. We hebben ook Flutter Apps gebouwd bij de NS, dus de hele stack. Oké, is er trouwens ook een specifieke reden waarom jullie voor Spring Boot hebben gekozen? Niet iets anders. Spring klinkt ook zo old school. Bij de ANWB was dat omdat dat een redelijke standaard was en we wilden daarin blijven. Ja, precies, precies. Oké, dank je wel. Ja, je hoort het ook nog steeds heel veel, Spring Boot, niet daarvan. Oké, een andere vraag die ik aan jullie beiden zou willen stellen is, welke loopbaan en werktips je aan je jongeren zelf zou willen geven? En misschien is het wel leuk om even bij Robert eerst te beginnen. Volgens mij de belangrijkste tip die ik ooit heb gehad, was van een persoon die nu met pensioen is, volgens mij Kishen die kent hij ook al, Wilco Korn. Die zei ooit tegen mij, als je ergens langer dan 5 minuten over doet, 5 minuten over nadenkt, ga je het dan iemand vragen. Oh ja, ja, ja. Ik vond het echt zo'n mooie regel. Ik dacht, en sindsdien pas ik hem gewoon toe. Daarom vind ik het ook super belangrijk dat je gewoon, zeg maar, dingen laat zien en feedback krijgt en vraagt en leert. Dat is allemaal, als ik zei, de weledelen heer Wilco Korn. Ja. Dus dat zou ik eigenlijk aan mezelf, echt, en vroeger zat ik echt... Ik zie sommige ontwikkelaars, zie ik maanden ergens op zitten. Weet je, en dan wordt er wat gereffecterd en er wordt er wat weggegooid en er wordt er iets compleet opnieuw gemaakt of iets dergelijks. En dan denk ik, maar wat heb je nou gedaan? Had je niet, we hadden samen, hadden we misschien tot een oplossing kunnen, of tot nieuwe inzichten kunnen komen, of dat je sneller dingen had kunnen doen of, weet je, en zeg maar, ja. Ja, ik snap het. Dat deed ik vroeger wel eens, dat was heel slecht. Dus na vijf minuten iemand aan zijn jasje trekken. Nou, het is wel leuk dat je het zegt, want toevallig ook vandaag bij de NS'en gaan we een nieuwe vacature uitzetten. Mij werd gevraagd om een review te doen. En ik had inderdaad één van de, noem het maar even, soft skills of, ja, wat is het, dus de niet, ja, niet de hardcore... Communicatieskills, ja. Ja, die ik erbij had gezet, die miste ik gewoon, was inderdaad durven vragen stellen, want die zag ik er niet tussen staan, want ja, ik denk inderdaad gewoon, we kunnen, denk ik, met z'n allen, ook in de IT, kunnen wij, denk ik, wel sneller aan de bel trekken. En natuurlijk, Google is je best friend, dus ik gebruik hem ook vaak na vijf minuten, maar ook dat, weet je wel. Dan kom je in een tunnelvisie, waar je, waar je misschien met menselijke interactie, misschien toch net even een andere blik hebt. Ik wilde trouwens bijna net rest in peace Wilco zeggen, maar hij is gelukkig nog niet, nee, hij is, ja, op LinkedIn is hij nog gewoon vol bezig. Hij is goed actief, hoor. Ja, precies. Met z'n 42 verhalen over wat er allemaal gebeurd is. Ja, ja, precies. Ik hoop dat we lang van al mogen genieten zo. Zeker. Ja, Jamie, heb jij nog een tip aan je jongeren zelf? Ja, zeker, zeker. We weten natuurlijk allemaal in de IT dat dat dingen heel snel veranderen. Elke jaar hebben we nieuwe technologieën, nieuwe technieken, nieuwe manieren van werken. Je moet dat allemaal bijhouden. Ik denk dat het belangrijk is om in het systeem te investeren, zodat je die kennis ook kan borgen en altijd oproepbaar is. Dat zou mijn tip zijn om daarin te investeren, dat je een systeem hebt waarmee je je kennis die je vergaart op een effectieve manier kan borgen en kan aanroepen. Ja, die vergeet ik ook wel eens inderdaad. Overal na een paar jaar of zo denk je weer bij jezelf, oh, ik had hier een projectje van te maken ofzo. Klopt. Maar als je je daarin traint en je doet daar de juiste dingen in, dan kom je in heel eind, denk ik. Nou noemde ik GitHub als een voorbeeld, maar heb je misschien andere manieren waarop je kennis... GitHub gebruik ik inderdaad ook, maar wat ik tegenwoordig gebruik is Obsidian. Dat is eigenlijk een tool waarmee je al je kennis die je vergaart vast kan leggen op je lokale machine en ook links kan leggen tussen documenten en dingen kan taggen. Dat is eigenlijk een soort knowledge base die je aanlegt. Klinkt als SharePoint. Sorry. Het verschil is dat je hier wel dingen terug kan vinden, met SharePoint niet. Hoezo, hoe bedoel je? Je hebt toch gewoon een zoekfunctie in SharePoint. Nee, maar ik snap het. Ik moet ook ineens aan dat andere product met dat olifantje denken. Evernote? Evernote, ja. Dat gebruikte ik eerst, maar ik heb alles gemigreerd naar Obsidian. Oké, en waarom is dat? Evernote is toch een cloud-based service en ik wilde echt alles lokaal hebben. Het zijn markdown files die je eigenlijk edit, die je kan linken, die je inzichtlijk kan maken. Je kan extenderen met plugins om bijvoorbeeld ook daily notes aan te leggen voor je stand-ups en wat je gaat doen. Dus dat is echt, ja, dat voegt voor mij echt wat toe. Oké, oké. Ja, ik zal hem even noteren straks in de tips. Zal ik nu even gelijk doen. Wat was de naam ook weer nog een keer? Obsidian. Obsidian. O-B-S-I. Obsidian, ja. Nou, een andere vraag die we aan jullie beide misschien kunnen stellen is de grootste fout die je misschien hebt gemaakt in de afgelopen jaar. Jaar? Ja. Ik heb nog veel betere. Die heb ik in volgens mij twee... Wanneer heb ik die gemaakt? 2014 ofzo? Toen merkte we dat zeg maar de NS Reisplanner, die was een object of C geschreven met storyboards en andere dingen, die had een compaaltijd van 20 minuten. Oh. Dus ontwikkelen erin was echt een drama. En toen bedacht ik me, kom, we gaan hem helemaal opnieuw schrijven. Dat was niet zo'n goed idee. Dus we hebben alle code weggegooid en we zijn helemaal van scratch-off aan begonnen. En ik had versie twee gemaakt, ik had versie drie gemaakt. En dit was versie vier ongeveer. Dus ik dacht van, ik weet wel alles hoe het werkt en dat is helemaal geen probleem. Maar toch, oh ik weet nog, we waren te laat en de hardware er ook aan werkte en ik weet nog de eerste reviews, oh wat een drama, dingen werken in die bugs enzo. Ja. Dus ik ga nooit meer van mijn leven iets van scratch-off aan weggooien. Ik ga nu vanaf nu altijd gewoon gefazeerd dingen aanpassen en gefazeerd dingen uitfazeren. Oh man. Maar dus uiteindelijk bleef het probleem hetzelfde, maar eigenlijk nog erger natuurlijk. Want die beeldtijd was nog steeds twintig minuten. Nee, die was heel stuk naar beneden. En de code was super consistent. Dus dat was mooi. Dus dat was het voordeel. Oké, oké, dat gelukkig wel. Alleen ik had het gewoon echt op een andere manier aan moeten pakken. Wat ik had moeten doen is ik had moeten zeggen van nou we pakken hier gewoon een bepaald stuk. Bijvoorbeeld vertrektijden ofzo. En dat gaan we aanpassen. En zodra dat is aangepast, gooi je dat oude weg. En dan pas gaan we de planner doen en dan pak je, weet ik veel, mijn reizen ofzo. Je pakt allemaal losse stukjes, pak je eigenlijk allemaal gewoon op. En dat doe je, want je hebt namelijk in al die jaren dat je de producten hebt gemaakt, heb je allemaal dingetjes gefixt en kleine slimme geetjes heb je erin gedaan enzo. En die verlies je allemaal op het moment dat je alle code weer weg gaat gooien. Dus je code wordt wel prachtig enzo. Dus de ontwikkelaar is hartstikke blij. De klant is niet blij. En volgens mij begon ik de podcast een beetje dat de klant altijd super blij moet zijn. En dat dit niet altijd om de ontwikkelaar moet gaan. Dus dat is een les die ik heb geleerd. Oké, nou dat zijn hele wijslessen. Ik moet er ook ineens denken aan, misschien weet jij dat ook nog wel Robert, in de Xebia tijd zijn we een keer naar een Xebia interne conferentie hadden we dan. Xebicon heette dat geloof ik. Xebicon ja. En toen hadden we Dan North op verzien. En die had ook een hele mooie talk, dat ging over refactoring inderdaad. Dan had die metafoor een boom weet je wel, die dan inderdaad je kon gewoon heel hard op gewoon opnieuw een nieuwe boom planten. Maar je kan ook kijken hoe je de huidige boom kan snoeien en kan knippen. Zodat het inderdaad naar je smaak gaat. Maar goed, ja dat is inderdaad een wijze les. Ja, goed fijn dat je hem even deelt. Jamie, heb jij misschien een interessante fout die je wilt delen? En vooral je learning natuurlijk daarvan. Ja, die heb ik wel. Maar daar vertel ik niks over. Nee, maar mogen jullie niet weten. Nee, naast natuurlijk werkzaamheden voor grote klanten doe ik ook werkzaamheden voor wat kleinere klanten. Sommige doe ik op fixed price basis. In het verleden heb ik weleens de fout gemaakt om een fixed price offerte af te geven voor werkzaamheden met eigenlijk te veel onbekenden. En ik ben daar veel te veel tijd mee kwijt geweest. Niet dat dat heel erg was op dat moment. Het is een leer moment natuurlijk. Maar dat doe ik niet meer. En je kunt dan beter dingen op nakalculatie doen en wat meer flexibeler in edge al werken dan echt fixed price offertes afgeven. Ja. Nee, ik snap het. Dus de scope dan misschien? Of bedoelde je meer? Scope perken of wat meer tijd om een proefconcept te maken. En op basis daarvan die ervaringen een wat betere offerte te maken. Ja, klopt. Oké, nou, dat klinkt ook als een hele goede aanpak. En op alles eigenlijk. Dus alles inderdaad met snelle feedback loops, weet je wel. Dus je snel probeert te leren, waardoor je meer informatie probeert te winnen en daar aan de hand van die informatie weer de volgende stap te zetten. En dat is volgens mij de kern van edge al werken, denk ik. Oké, nou, goede tips. Nou, dan hebben we nog één laatste. De belangrijkste developer skill die jullie zouden aanraden. Wat zou dat volgens jou zijn? Dus de most underrated developer skill. Die jullie zouden willen... Ja, dus wat is voor jullie belangrijk, laat ik zo maar even zeggen. Ik heb er een paar, als dat ook mag. Ja, tuurlijk. Het belangrijkste is natuurlijk altijd communicatie. Wat Robert ook al zei, blijf niet te lang met een probleem zitten, maar vraag hem hulp als je ergens mee vast zit. Andere dingen is, hou dingen simpel, kies voor eenvoud in plaats van complexiteit. En probeer niet eindeloos te discussiëren over specificaties, maar ga op een edge al manier dingen maken, ga itereren, ga leer het probleem kennen en ga op basis van ervaringen je product verder ontwikkelen en feedback. Ik moest ineens denken aan een advertentie die ik zag op LinkedIn. Ik zal de bedrijfnaam niet noemen trouwens. Maar die hadden echt als slogan van, kom bij ons werken aan ons complexe systeem. Ja, dat kan natuurlijk twee kanten op. Dan kan je zeggen, ja, kom, we gaan het nog complexer maken. Of je gaat het beter... Dan kan je het misschien beter opnieuw doen. Wat denk jij, Robert? Ja, ik vind het... Ik vind het... Ik denk dat het belangrijkste is als developer, dat je altijd, en dat is ook lastig voor een hele hoop developers, dat je weet waarvoor je het doet. Wat is zeg maar die business value die je brengt? Nu klink ik een beetje als een soort, weet je al, processcoach, weet ik wel, dat soort dingen. Maar nu snap ik die gasten eindelijk eens een keer een beetje. Ja, precies, ja. Maar ik vind het altijd heel fijn, zeg maar, van waarvoor je het eigenlijk allemaal doet. Ik wil bijvoorbeeld meer mensen onboarden. Ik wil meer sales halen. Hoe gaan we dat nou allemaal doen? En eigenlijk alles wat je doet, staat in teken van dat einddoel. En dat moet je, zeg maar, voor ogen houden. En iedere keer, als je gewoon zo'n stapje maakt, dan kom je daar gewoon, zeg maar, dichterbij. En dus bijvoorbeeld eindeloos discussiëren over requirements, of dit, of dat, of zis, of zo. Weet je, het gaat er gewoon om welk stapje kan ik nu nemen om gewoon daar dichterbij te komen. En niet te ver vooruit kijken. Niet proberen alles in detail gewoon uit te specificeren, want dat werkt toch niet. Gewoon stukje bij beetje. En iedere keer leer je en krijg je nieuwe inzichten. En weet je steeds beter hoe je bij dat einddoel moet komen. Ja. Ja, dat uitspecificeren, misschien klinkt het als een zekerheid, maar dat is het eigenlijk helemaal niet, want je leert pas als je daar echt mee bezig gaat. Ik heb de quote van die IT-advertentie even goed nagezocht. Oh ja. Dat was, bouw mee aan onze complexe architectuur. Maar wat is een einddoel? Een nog complexere architectuur? Ja, inderdaad. Dat weet je nog niet. Nee, dat is ook zo. Maar goed, ik kan me wel wat bij voorstellen. Ik zou juist zeggen van, bouw mee aan onze complexe architectuur om hem simpel en begrijpbaar te maken of zoiets. Ja, precies. Dat viel er net af. Ja, ja. Jammer hoor. Is een gemiste kans. Ja, zeker, zeker. Ja, ik houd van één fout. Nee, precies. Ik denk ook de... Tenzij je een probleem natuurlijk complex is, dan heb je van de dure complexiteit, maar... Ja. Soms denk ik ook van... Ja, is dat überhaupt mogelijk om dingen simpel te maken in complexe materie? Want ik zit even te denken, even hardtopdenkend. We maken toch geen software voor deeltjesversnellers? De meeste van ons? Nee, de meeste niet, nee. Nee, maar ik zit even te denken. We hebben ook een tijdje bij een hypotheekverstrekker of zo hebben we gezeten. En dan zaten allerlei complexe... Laat even de Belastingdienst bijvoorbeeld noemen. Nou, Belastingdienst. Er zitten natuurlijk ook allerlei haken en ogen aan regels, wetgevingen die ook veranderen. Die ook aan veranderingen onderhevig zijn inderdaad, ja. Dus dan heb je al volgens mij te maken met een hele complexe, noem het maar even materie of domein of wat dan ook klopt. En dan, ja. Maar ja, goed, dan kan je nog steeds voor softwareontwikkeling kiezen voor een simpele manier om daarmee op te gaan. Ja, ik denk juist in een complexe omgeving dat het belangrijk is dat je snel een iteratief kan opleveren en snel ook leert van die complexiteit, zodat je het probleem beter begrijpt en daardoor simpele oplossingen kan maken. Ja. Maar dat vereist denk ik ook wel dat je voor een langere tijd in een bepaald domein werkt, zodat je goed begrijpt wat er speelt en tot simpele oplossingen kan komen. Want als jij bijvoorbeeld in die complexe architectuur dingen gaat doen, ik ben net een maand bezig. Kan jij niet verwachten dat je het even simpel gaat maken? Nee. Ik denk toch wel weer een voorbeeld, zeg maar die NS Reisplanner waar we mee bezig zijn geweest. Daar hebben we echt jaren aan gewerkt. En uiteindelijk kwamen we zover dat we best wel complexe vraagstukken simpel konden oplossen door gebruik van microservices en bepaalde dingen aan elkaar te koppelen en zo. Maar gewoon puur omdat we paraten domeinkennis hebben over en ook nog eens een keer over allemaal verschillende afdelingen heen. En dat is super waardevol. Dus ik denk ook dat helaas is onze economie zo, geloof ik, of zeker bij developers zo, dat mensen niet langer dan twee jaar of drie jaar of vier of vijf, vijf is erg lang geloof ik tegenwoordig, ergens blijven zitten. Maar ik zie toch vaak dat de wat oudere werknemers heel veel domeinkennis hebben en vaak ook wel tot simpele oplossingen kunnen komen, omdat ze gewoon die kennis per raad hebben. En ik denk voor bedrijven als ze een goed product willen hebben en dat voor langere periode in willen zetten, zullen ze moeten investeren in hun mensen die daar werken en ze goed betalen, ook netjes. Zodat we niet iedere keer, iedere twee jaar wegvluchten naar een land dat het gras wat groener is, wat uiteindelijk niet zo goed is. Nee. Ja, dat is absoluut zo, want kennis is dan in die zin macht en die kan je dus krachtig inzetten. Maar inderdaad, als je dus opnieuw het wieltje, dus ook in de kennis moet gaan opbouwen, dan heb je weer andere opvattingen, heb je de context niet van die zoveel jaar geleden en dan ga je inderdaad al gauw fouten maken en dan worden systemen complexer. Dus ik zat toevallig net ook even te zoeken naar Conway's Law. Ik moest even aan die law denken, maar ik wist even niet dat er Conway daarvoor stond. Dus dat heb ik net opgezocht en dat reflecteert. Kijk, ook daar weet je, de organisatie reflecteert uiteindelijk gewoon de communicatie en ook uiteindelijk denk ik ook wel de architectuur van software. Maar goed, het wordt een hele diepgaande filosofische discussie. Maar goed, daar gaan we gauw even voorbij. Maar in ieder geval, de most underrated developer skill is inderdaad, ja, vind ik zelf ook inderdaad, is zorgen dat je inderdaad goed begrijpt waarom je dingen doet. Ja, precies. Want software development is gewoon slechts een tool. Klopt, klopt. Dat heeft altijd een einddoel. Ja, ineens. Oké, nou dan hebben we nog één laatste, ja hoe heet dat, vaste rubriek die ik even met jullie zou willen doornemen. Dat zijn onze tips die we aan onze luisteraar zouden kunnen geven. Ik denk dat we ook in de uitzending al een paar hebben gedaan. Maar wellicht misschien dat je nu ook even denkt van, hoi, die heb ik gemist, dus daar is even nu de tijd voor. Robert heb ik nu even als eerste opgeschreven. Heb jij nog een tip? Het mag ook echt totaal niet met code te maken hebben hoor. Ik denk dat het belangrijkste tip is, investeer alsjeblieft in je gereedschap. Oké man. Sorry, het is een beetje, weet je, algemeen. Gereedschap is zo ontzettend belangrijk. Vooral bijvoorbeeld goede laptops, goede workstation of iets dergelijks. Het maakt je leven zoveel plezieriger, dat als je code tikt, dat je gewoon compaalt binnen een paar seconden. Dat je snel resultaat hebt, dat die gewoon netjes reageert. Dat als er een nieuwe versie van iets uitkomt, dat je het gewoon lekker kan installeren in plaats van dat je eerst een uur bezig bent om oude rotzooi op te ruimen en zo. Dat is denk ik, en vraag je manager of sur gewoon net zo lang tot die je gewoon toegeeft, want weet je hoeveel tijd en geld het allemaal kost en ik snap dat die inkoopafdelingen af en toe erg lastig zijn. Maar 1000 euro voor iets uitgeven waar je drie jaar mee moet werken of mee mag werken en dat je heel veel plezier ervan hebt, dat is goud waard. En hetzelfde geldt ook voor je tools. Koop gewoon zeg maar voor 200, 220 euro heb je geloof ik de JetBrains alle tools ongeveer per jaar. Nou, echt fantastisch. Gewoon doen. Ja, ik zit nu ineens te denken aan alle medewerkers die met Citrix moeten werken. Ja, die dan. Ik heb met ze te doen. Hebben jullie dat soort dingen niet bij de AMWB op dit moment? Dat jullie echt via een... Wij werken allemaal op onze eigen machine. Ja, precies. En VPN waarschijnlijk ofzo. Ja, klopt. Ja, oké, dat wel. Oei, oei, oei. Nou goed. Ja, een goede tip. Ja, sorry, een beetje lastig maar. Herre is gewoon die manager. En laat hem gewoon... Dus we willen altijd van die business cases zien. Laat het gewoon maar eens even zien van hoeveel tijd het kost om gewoon die ellende waar je af en toe mee moet werken. Ja, precies. Misschien kan je inderdaad je manager of je leidinggevende daar inderdaad even tijd in laten investeren. Van, joh, maak eens even dat rekenssommetje voor me. Want, ja. Nee, me eens. Goede tip, man. Ja, mocht er nog iets anders binnenkomen, het mag wel echt totaal alles zijn. Favoriete muziek, favoriete film die je gezien hebt. Je hebt zo net eentje gebdeeld, die WeHack. It's the same, it's the same. Echt fantastisch. Ja, oké. Nou, Jamie, heb jij misschien nog een paar tips? Ik had er eentje al opgeschreven voordat we elkaar ontmoeten hier fysiek. Je bent lekker aan het... Of tenminste, nu wat minder. Maar je producing skills, die kan je nog bewonderen, geloof ik, toch? Ja, die kun je, denk ik, nog wel vinden op YouTube. En onder welke naam moeten we dat zoeken? Dat ga ik dadelijk even opzoeken. Zo lang geleden, wauw. Zo lang geleden, inderdaad. Ik heb de LP's, de platen heb ik nog zelfs thuis. Ja, ja. Nou, mooi. Dus je had ook je eigen label toen, of niet? Geen eigen label. Wij brachten onze muziek uit bij bestaande labels. Ook aan bestaande labels? Oké, nice. Ah, mooi. En ik had Opsilon ook al opgeschreven. Ja, het heet Obsidian. Obsidian, sorry. Ja, Obsidian, sorry. Ja, Obsidian. Ja. Nou, die had ik ook al verloopt. En verder wat Robert ook zegt, investeer ook in je software. Denk niet gauw van, ik maak dat tooltje ook wel, want ik wil geen 10 euro uitgeven aan dat tooltje. En ken je development tools? Dat is, denk ik, erg belangrijk. Investeer daar ook tijd in om te leren kennen. Ja. En een leuke waar ik tegenwoordig mee bezig werk, is GitHub Copilot. Ik weet niet of je dat kent. Nee. Ik sta er op de waitlist, potverdorie. Ik wil het ook gebruiken. Ja, dat is zeg maar een... Copilot heet het? Copilot, dat is C. Een artificial intelligence voor je code completion. Binnen je IDE. Oh, die daarna stack overflow... Ja, die GitHub scant. Het is ook een tool van Microsoft. En ja, je zou denken, wat kan die mij voor suggesties doen? Maar je merkt vooral dat die suggesties kan doen voor dingen die je normaal gesproken wellicht op stack overflow moet opzoeken. Omdat het iets is wat je niet heel vaak gebruikt. Doet die dan een suggestie voor je binnen je IDE. Ja. Dus je blijft in je context zitten. En dat is wel een heel krachtig middel. Ja, productiviteit, die gaat gelijk met tien omhoog, joh. Die gaat meteen met tien omhoog, inderdaad. Ja, precies. Eigenlijk begint stack overflow misschien ook wel een knowledge base te worden, dus. Ja, dat is het zeker. Het is vooral de vraag, hoe kom ik zo snel mogelijk tot de juiste kennis op dat moment dat ik het nodig heb. En dit is wel iets wat je daarmee helpt. En Copilot is van? Van GitHub, van Microsoft. Maar ze hebben dus inderdaad een plugin voor de JetBrains tools. Ja. Dus het werkt ook voor Swift. Ja, klopt. Want in principe, iedere taal die op GitHub staat, die scant hij. Dus het maakt niet uit of je nou Ruby of .NET of Kotlin of Swift. Ja, nice. En je vertelde net, jij staat nog op de wachtlijst. Dus voorgenen die moeten aanmelden, die moeten denk ik wel even lang wachten. Ja, ik weet dat een collega van ons er een week op heeft moeten wachten. Dus het verschilt. Ik weet ook niet wat de criteria zijn. Maar het is nu nog een beta, een wachtlijst inderdaad. Oké, ja. Nou, goed joh. Ja, leuke tip. Dank je wel. Ja, ik had hem inderdaad wel eens voorbij zien komen. Maar ik dacht altijd van joh, dat is één grote grap of zo. Weet je wel. Maar het is echt serieus. Zeker, zeker. Oké. Nou, cool. Even kijken. Ja, ik had er ook eentje. Ja, ik had ook mijn Twitter feed nog even bekeken. Ik ben de laatste tijd niet zo heel erg. Veel de laatste tijd ermee bezig met van die tips, de retweeten. Maar ik kan wel delen dat ik een boek aan het lezen ben. Genaamd Ego is the Enemy. Nou, zullen er misschien heel veel mensen denken. Goh, Kishen, je hebt een enorme ego. Ja, die heeft iedereen. Iedereen heeft een ego. Hoe je ermee omgaat is natuurlijk een tweede. En wat dat boekje leert is hoe je eigenlijk met succes om moet gaan. Of kan gaan, laat ik zo maar even zeggen. En natuurlijk ook met failures. En het ding wat mij achtergebleven is, is die humbleness. Dat je constant altijd humbel moet zijn. Ook naar mensen die eigenlijk niks weten. Over software development bijvoorbeeld. Want die kunnen je ook weer dingen leren. Want die zien dingen met een heel blind oog. En gewoon niet logisch meer zien van... Weet je wel, als je iets vertelt dat ze het gewoon niet logisch vinden. En dat is ook een hele waardevolle feedback. En heel vaak denken wij van... Ja, tenminste, dat hoor ik dan in die boek. Dat lees ik in het boek. Er gaan mensen vaak in een soort van defensieve mode. Van ja, maar hallo, ik heb die 15 jaar ervaring. Wat kom jij me nou vertellen? Maar mijn tip zou daarin zijn, laat dat alsjeblieft varen. Maar luister die persoon nou even goed aan. Of die junior, met wie je ook moet communiceren. Keep always learning. Dat zeiden we net ook al. Blijf altijd maar leren. Ja, goed tip. Ja, heel goed. En dat boek is wel... Het is wel taai, moet ik zeggen. Je moet er wel even doorheen. Het is niet eens zo dik of zo. Maar de schrijven gaat wel in allerlei voorbeelden. Dus ik ben uiteindelijk ook nu een soort van samenvatting aan het opbouwen. Waar voor mij een paar mantra's in staan. Weet je wel? Waarmee ik om kan gaan. Dus zeker een tip voor degene die misschien een beetje op zoek zijn naar hoe je daarmee om kan gaan. Met ego. En misschien ook wel mensen die een enorme ego hebben. Weet je wel? Daar staan ook hele handige tips voor. Oké. En Robert, heb je nog een... Ja, ik zat te denken. Ja, ik zie het aan je hoofd. Dat is het mooie van in real life. Nou, ik zat te denken. Misschien tv tips en zo. Ik heb er misschien twee. Ik ben wel zeg maar een Marvel fan. Een beetje van de films in de tv-series. Maar ik vond op Disney Plus de What If serie vond ik echt best wel goed. Want het is een tekenfilm. Maar het gaat er dus over. Dus bijvoorbeeld van wat als Captain America. Geen Captain America maar is geweest. Maar zijn vriendin, Captain Carter. Wat een Britse dame is. Dan krijg je niet Captain America, maar Captain Britain of iets dergelijks. En ik vond het zo grappig. En bijvoorbeeld de tweede aflevering was van... Wat als Star-Lord van Guardians of the Galaxy. Dus het is niet Star-Lord was geweest. Maar degene die Black Panther is Star-Lord geweest. Wat was er dan gebeurd? En dan wordt hij dus onderdeel van Guardians of the Galaxy. Maar dan Thanos, de grote bad guy uit de Avengers films. Wordt dan onderdeel van de crew van Guardians of the Galaxy. En ik dacht eens wat een mindfuck is dat. Ik vond het zo ontzettend gaaf. En het zit best wel goed in elkaar. En het zijn een aantal tekenfilms. Ik dacht in het begin van het samen losse verhalen. Maar aan het einde komt het weer samen. Ik vond het echt heel tof om te zien. Ik dacht in het begin van nou, het is een tekenfilm waar we zitten. Ik vond het echt de moeite waard. Ik denk dat je samen misschien op een tip hebt gegeven. Want die is ook heel erg in Toon Marvel. Ja, ik ga hem ook op mijn lijst zetten. Oké. En jij nog een tweede? Nog één, nog één. Ik kijk ook, en dat vind ik ook echt heel tof, foundation op... Nou goed, ik heb een iPhone, dus ik heb ook Apple TV+. Dat is van Isaac Asimov. Verhaal, serie. En het doet me een beetje denken aan Dune. Beetje diezelfde sfeer en zo. Maar goed, omdat er over Asimov gaat, is het natuurlijk allemaal een beetje wetenschappelijk, mathematician-achtig. En het is een soort keizerrijk, wat echt heel erg lang bestaat. En er is een keizer die heeft bedacht dat hij zichzelf kan klonen. Waardoor hij eigenlijk het eeuwige leven heeft. En er is een of andere matematicus die heeft berekend dat waarschijnlijk het keizerrijk ten onder gaat. Tenzij je die bepaalde stappen neemt. En hij zegt van, het keizerrijk gaat ten onder voor dertigduizend jaar. Tenzij je mijn plannetje volgt, dan gaat hij maar onder voor duizend jaar. Dat is natuurlijk allemaal strubbelingen en dingen. Ik vind het echt prachtig hoe dat om elkaar is gezet allemaal. Ja, dat iemand dan ook dat echt helemaal gaat uitwerken natuurlijk. Zo'n director die dan... En het is volgens mij door David S. Goyer. Die heeft geloof ik ook Game of Thrones, dacht ik, gedaan. Dus de productiewaardes zijn weer... Het is weer heerlijk. Ja, heerlijk man. Nu we het over tv en series en zo hebben. Twin Peaks. Kijkt iemand hier te wallig Twin Peaks? Dertig jaar geleden of zo. Ja, dat is echt ontkomst. Maar ze hebben sinds... Oh ja, dat was een nieuwe. Een nieuwe seizoen hebben ze op Vierderland uitgebracht. Of tenminste op allerlei verschillen. Maar keken jullie dat nog wel eens? Ik niet, ik niet. Ik heb het wel gekeken. Ja, wat dacht je toen? Ik dacht, ik weet niet of ik... Ja, dit nog even door kan blijven kijken. Ik ook. Ik had precies hetzelfde als jij. Dat ik dacht echt van, wat gaat dit nou eigenlijk over? Welke sicko moet je zijn om dit door te kunnen kijken? Nou, blijkbaar ik dus. Maar ik heb het... Ik ben de laatste seizoen dus aan het bekijken. En ja, het blijft me wel... Ik weet niet. Ik ben gewoon een beetje hoek eraan of zo. Aan al die gekke scènes. Dus je moet even doorbijten en dan... Ja. Oké. Ja, maar ik denk wel dat je een sick mind van moet hebben om er doorheen te komen. Want het is inderdaad af en toe dat je echt denkt... Waar heb ik nou naar zitten kijken? Weet je wel? Van dat iemand zo heel vreemd in de camera zit te kijken. En dan echt soms twee, drie minuten lang. Weet je wel? Of naar hele foute muziek aan het einde. Weet je wel? Dat je echt denkt van, waar heb ik nou naar zitten luisteren? Maar toch, het blijft op een of andere manier interessanter naar te kijken. Oké. Goed. Nou, ik... Ja, jullie nog op tevallen heeft misschien nog één laatste. Een filmtip misschien nog? Ja, zeg maar. Er zijn toch vreemde films aan. In de Marvel-hoek natuurlijk, maar we hebben natuurlijk ook de DC-hoek. Sommigen zeggen, als je een Marvel-fan bent, dan ben je geen DC-fan. Maar ik denk dat dat allebei kan. Ja. Als je toch een hele vette film wil zien, vond ik, was de Snydercut van Justice League. Dat kan Robert veramen, denk ik. Die van... Nee, hoe heet die ook alweer? Die vorige andere regisseur? Wade'n ofzo? Joss Whedon. Ja, volgens mij wel. Die van Firefly, die had die film overgenomen van Snyder. Omdat de studio het niet eens was, geloof ik. Of het kostte veel geld of iets dergelijks, weet ik wel wat. Het was niet populair genoeg. Het was niet mainstream genoeg. Het was niet mainstream, maar dat was een beetje een matige film. Wouter heeft dus die andere het weer gedaan en die heeft gewoon zijn originele visie neergezet. Echt een super vette film. Een film van vier uur, maar echt de moeite waard. Oké, oké. Cool, cool, cool. Ik heb hem opgeschreven. Dus ja, die gaat er tussen. Nou, jongens, ik denk dat we het toch maar even gaan afsluiten. Volgens mij zitten we nu echt twee uur en tien minuten ongeveer lekker te kletsen. En het is ook alweer laat en donker. Nou, donker was het altijd. Donker was het altijd. Ja, precies. Dank jullie wel voor het luisteren allemaal. Dat je het helemaal vol hebt gehaald. Ja, ja. Knap, knap. Ja, het is heel knap elke keer van iedereen. Maar ja, goed, het is ook een hele interessante onderwerp natuurlijk. Het gaat natuurlijk wel een beetje alle kanten op. Maar aan de andere kant is het ook wel weer zo interessant dat je er toch altijd wel wat mee neemt. Dus, nou, in ieder geval bedankt Robert en Jamie voor jullie deelname, Vlaamand. Graag gedaan. Graag gedaan hoor. Ja, tuurlijk. En ja, we hebben natuurlijk veel geleerd over mobile development. Maar natuurlijk ook alle dingen eromheen. Zoals, ja, het belangrijkste wat hier achterblijft volgens mij is. Je gebruiker, vergeet die niet, vergeet die niet. Juist, ja. Ook wil ik even Salves test services bedanken voor het gebruikmaken van het kantoor. Ja, ik moet toch wel toegeven dat ik echt heel blij ben dat we weer in real life kunnen opnemen. Want dan, sowieso zie ik jullie weer na zoveel jaar. Dat is sowieso wel even wel leuk om te zien. Want ja, Robert die ken ik uit de Xebia-tijd en Jamie Crank van mijn Q&A-tijd samen. En Saber overigens ook. Saber, die kent Jamie ook. Maar helaas kon hij vandaag niet aanwezig zijn. En verder natuurlijk ook alle luisteraars bedanken voor het luisteren. Ga naar codeklets.nl om meer afleveringen te luisteren. En ik zou het ook wel eens leuk vinden als jullie nog eens een keertje langskomen op ons Slack kanaal. Kom eens even gedag zeggen. Leve je feedback ook vooral. Misschien ook wel opmerkingen die je hebt over deze aflevering. Ik zou ook Jamie en Robert ook graag willen uitnodigen om daarna te komen. Want ja, ligt hier wel een leuke vraag voor jullie. Nou, nogmaals bedankt. En tot de volgende keer. Doei!