Blog

Ik wil een kleine high-end telefoon

De fijnste telefoon die ik heb gehad was de HTC Magic. Ik had de developer versie daarvan, de Ion. Hij was klein, had een snelle cpu (voor die tijd dan) en een goed scherm. Prima telefoon. Hij was klein, glad, afgeronde hoeken, je kon ‘m makkelijk in je hand houden of in je zak steken. Het was ook de high-end Android telefoon van HTC.

Vandaag de dag kun je zulke telefoons niet meer kopen. Je hebt voor een Android telefoon de keuze tussen een high-end telefoon, die heel groot is, of een kleine telefoon, die dan een trage cpu heeft en weinig geheugen. Of althans, ik kan zo’n telefoon niet vinden. De beste die ik nu heb gevonden is de Pixel 4, die heeft goede specificaties en is relatief klein, maar wel twee keer zo groot als de Ion.

Waarom kan ik niet een telefoon kopen die zo klein en handzaam is als de Magic/Ion, maar wel met de snelste cpu die bestaat, en een machine learning chip erin, en een scherm met hoge resolutie? En met 5G? Is het echt zo dat mensen die een goede telefoon willen, dan ook per se een grote telefoon willen?

Lieve telefoon-fabrikanten, maak eens een kleine snelle telefoon. Je doet er veel mensen een plezier mee.

Agile

Agile werken zonder vergaderen en zonder regels

Agile betekent “slagvaardig” of “lenig” of “flexibel”, of zelfs “wendbaar”. Het kan een heleboel betekenen. Wat het volgens mij in ieder geval niet betekent is “veel vergaderen” of “strenge regels en richtlijnen” en al helemaal geen “checklists”.

Ter illustratie heb ik een stukje geschreven over hoe je een agile project kunt starten, met een Project Startup Hackathon. Daarnaast heb ik een blogje geschreven met tien tips voor de agile manager.

Nog meer ideeën en gedachten over Agile werken en Agile project management heb ik opgeschreven in mijn boek Agile zoals het bedoeld is. Ik vind dat voorschriften en regels niet goed bij Agile passen. Ik vind eigenlijk dat het schrijven van een boek over Agile een paradox is. Vandaar dat je in mijn boek geen schema’s vind, geen voorschriften of regels, maar alleen ideeën en anekdotes. Zoals het hoofdstuk “Een weekendje naar Parijs”.

Agile, Programming

Nieuwe features in software: hoe beslis je welke je bouwt? #Agile

Nichtje had zichzelf getekend in de brief

Ik heb een site gebouwd, en ik bouw daar nog aan, waarin ik de brieven van de familie Schwartze archiveer en documenteer. Vooralsnog ben ik zelf de enige gebruiker van de site. Ik had kunnen beginnen met een site en een API en een database met alle functionaliteit die ik kon bedenken. Dat was veel werk, en dan had ik in de loop van de tijd veel moeten veranderen wegens voortschrijdend inzicht.

Dus ben ik minimaal begonnen: met alleen een database waarin ik data heb ingevoerd met SQL. Die database heb ik geconverteerd naar een netjes gestructureerde database, op basis van wat ik inmiddels over de content had geleerd. Toen wilde ik een overzicht van alle brieven, dat heb ik gemaakt met ReactJS. Brieven hebben afzenders en ontvangers, die wil ik documenteren, dus heb ik daar features voor gemaakt. Minimalistisch, maar wel functioneel.

Nu ben ik in het stadium dat ik de toekomstige bezoekers van mijn site in het vizier heb, en ik kan allerlei functies en features bedenken die ze misschien handig vinden. Maar dan ben ik daarmee maanden aan het programmeren terwijl ik ook de content nog compleet moet maken. Ik kan ook niets meer bijprogrammeren en me concentreren op de content, maar dan maak ik steeds meer work-arounds wegens missende features. Wat ik dus doe is het volgende: iedere keer als ik een nieuwe feature bedenk, dan programmeer ik die niet, maar verzin een work-around met de bestaande software. Pas als ik voor de derde keer die feature zou willen gebruiken, bouw ik ‘m erbij. Dan weet ik inmiddels ook meer in detail wat die feature moet doen.

Als voorbeeld: een brief heeft één afzender, degene die de brief schrijft. Maar soms is er een briefje van tante waar een nichtje een velletje heeft bijgevoegd: dan zijn er twee afzenders. Dat hoeft niet per se zichtbaar te zijn in de database, als tante de afzender is, is het duidelijk genoeg. Totdat ik voor de derde keer twee brieven in één envelop had, toen heb ik alles zo gemaakt dat je meerdere afzenders kunt hebben voor één brief. Hetzelfde gebeurde voor de ontvangers: tante schrijft een brief aan de drie nichtjes.

Ik wilde kunnen zoeken in de brieven, dus heb ik met Apache Lucene een zoekfunctie gemaakt op de content van de brieven. Wat ik nog niet heb is een zoekfunctie op afzenders of ontvangers in de database. Ik blader alfabetisch door de brieven om iemand te zoeken. Dat wordt nu hinderlijk, dus ik ben nu op het punt een zoekfunctie te maken voor afzenders en ontvangers en locaties en dergelijke.

Ik werk dus efficient: ik besteed minimale tijd aan het bouwen van de web site en de API en wat daarbij hoort zodat ik maximaal tijd heb voor de inhoud, waar het tenslotte om gaat. Als ik inhoud af is, en ik er een boek over heb geschreven, dan heb ik tijd om de features toe te voegen die ik zelf nu niet nodig heb maar die voor bezoekers van de site handig zijn. Zodat als het boek verschijnt, ook de site optimaal is.

Deze aanpak klinkt simplistisch, maar ik denk wel dat je ieder project zo zou moeten doen. Je verzint met z’n allen de absolute bare bones structuur van je applicatie of web site, en je bouwt dat. Dan gaan gebruikers aan de slag en pas als ze een feature echt missen, dan bouw je die erbij. Je backlog krijgt dus een extra column: “aantal verzoeken”. Pas als tien gebruikers een feature in de praktijk node missen, bouw je die erbij. Niet met toeters en bellen, maar alleen de minimale feature waar gebruikers of klanten om hebben gevraagd. Is er dan een toeter of een bel die ze nog missen, dan gaan ze vanzelf piepen en bouw je de toeter of bel erbij.

Taalblog

Hét cliché van de biograaf

“Thérèse Ansingh wordt op 19 juli 1883 in Amsterdam geboren als jongste dochter van het echtpaar Ansingh-Schwartze”.

Foei, wat een akelig cliché. Ik kan me voorstellen dat een biograaf zoiets een keer schrijft vanwege de vlotte schrijfstijl of om origineel te zijn. Maar Ansingh wordt niet geboren, ze ís geboren, 137 jaar geleden, in 1883. Waarom moet iedere biograaf mijn hersens in de knoop slaan met zo’n cliché?

Laten we afspreken dat we in een biografie, groot of klein, voortaan gewoon de voltooid tegenwoordige tijd gebruiken, zoals het hoort. “Thérèse Ansingh is in 1883 in Amsterdam geboren. Ze was de jongste dochter van Clara Schwartze en Edzard Ansingh”. Dat klinkt toch deftig genoeg? En als iemand het dan een keer anders doet, laat dan niet alle biografen gelijk denken “oh, dat is mooi geschreven zo, dat ga ik ook doen” want dan hebben we weer een nieuw akelig cliché. Laten we de akelige clichés overlaten aan de TV-sportverslaggevers, die maken onze hersenen al genoeg in de knoop.

Blog

Mondkapjes?

Gisteravond in Op1 op NPO1 werd druk gediscussieerd over mondkapjes. Het kabinet heeft ze een paar uur eerder niet verplicht gesteld, terwijl iedere leek ervan overtuigd is dat ze verplicht moeten zijn. De presentatoren en gasten aan tafel droegen geen mondkapjes. Ze zaten met z’n tienen in een niet zo kleine maar ook niet zo grote ruimte, een uur lang naar elkaar toe te ademen. Er was ongetwijfeld ventilatie, maar ik zag geen kleding wapperen dus het was bescheiden ventilatie. Ze ademden naar elkaar toe, en omdat uitgeademde lucht iets warmer is dan de kamertemperatuur stijgt die uitgeademde lucht boven de tafel op, om langs het plafond en dan langs de wanden weer naar beneden te gaan. Richting tafel, richting mensen. Als één van de mensen aan tafel besmet was geweest, dan was de kans zeer groot geweest dat de meeste aanwezigen besmet waren geraakt, niet omdat ze te dicht bij elkaar zaten maar omdat ze een uur lang samen aan tafel zaten. Maar ze droegen geen mondkapjes.

Een supermarkt is heel anders dan een studio. In de supermarkt kom je meer mensen tegen, maar je komt ze maar één of twee keer vluchtig tegen, in het voorbijlopen, je houdt afstand, het besmettingsgevaar is klein. Ik ben er vrij zeker van dat als er een besmet persoon rondloopt in de supermarkt, je kans om besmet te raken klein is. Je bent immers maar één of twee keer, of nul keer, heel even bij zo iemand in de buurt. Toch is iedereen ervan overtuigd dat het kabinet mondkapjes in supermarkten verplicht moet stellen.

Ik stel voor dat iemand gedegen onderzoek gaat doen naar het besmettingsgevaar op allerlei locaties. In supermarkten, in vergaderkamers, in kerken en theaters, op de markt, op het terras, in het OV, overal. Dat onderzoek heeft twee onderdelen: onderzoek in de praktijk, op basis van informatie waar mensen daadwerkelijk met covid-19 besmet zijn, en onderzoek met modellen en metingen in het laboratorium.

Immers, als we weten waar mensen wel besmet raken en waar mensen niet besmet raken, kan het kabinet goed beleid maken waar mondkapjes en eventuele andere beschermingsmaatregelen effectief en dus gewenst zijn, en waar niet. Nu heb ik het idee dat het natte vingerwerk is, deels gebaseerd op andere argumenten dan medische of anderszins wetenschappelijke argumenten.

En ja, ik denk dat de studio veel groter was dan het zichtbare deel dus dat het risico kleiner was dan ik hierboven schets. De Op1 studio staat voor mij model voor iedere vergader- of andere ruimte waar mensen langere tijd samen zijn en praten. Om die reden zou Op1 best het goede voorbeeld mogen geven en mondkapjes dragen, als iedereen dat zo graag wil.