Tag software ontwikkelaar (rol)
Semantische bugs
Voor een presentatie klooide ik wat variaties op het FizzBuzz-algoritme in elkaar. En ergens in de loop van die codeeroefening stuitte ik op een interessante bug – hoewel, ik weet niet eens zeker of het wel een bug was. Dus: wat is een bug eigenlijk?
Wat zegt deze test?
“Wat zegt deze test?” – Het meest voor de hand liggende antwoord is natuurlijk: wat de code doet. Maar dat is slechts wat een test expliciet zegt, de informatie die een test inhoudelijk overbrengt. Dat is niet het enige wat het zegt – verre van.
Een goede ontwikkelaar begrijpt eerst het probleem
Een softwareontwikkelaar is niet iemand die code schrijft. Iemand die slechts dat doet, kan, ondanks al zijn inspanningen, van geen enkele toegevoegde waarde zijn. Want uiteindelijk gaat het niet om de code. Het gaat niet om de code, zelfs niet als die code precies doet wat er gevraagd wordt. – Software ontwikkelen gaat om het oplossen van problemen.
Grote refactorslagen ondermijnen vertrouwen
Wat een stakeholder betreft is een grote refactorslag een enorme kostenpost zonder aantoonbaar resultaat. Een team dat erop staat niet verder te kunnen werken zonder eerst een hele tijd heel veel geld uit te geven – nota bene zonder daar iets voor terug te geven! –, ondermijnt het vertrouwen dat de stakeholder hen daarmee geeft.
Een oudergesprek
Onlangs mocht ik op mijn oude universiteit jonge studenten (en hun ouders) geruststellen: het is goed mogelijk een leuke en uitdagende baan te bemachtigen met een studie filosofie. Na afloop had ik een leuk gesprek met een Steve Jobs-lookalike – een vader, geen student –, die me vertelde dat ook hij overwoog om te leren programmeren. Hij zei wat iedereen zegt die overweegt te leren programmeren: “Ik heb het altijd leuk gevonden om dingen uit elkaar te halen om te kijken hoe ze werken.” – En ik besefte me opeens: ik heb dat totaal niet.
Waarom testen testers?
Tijdens een Retrospective gaf onze tester aan dat hij omkwam in het werk. Eigenlijk verbaasde niemand dat. Ons team bestaat uit vijf ontwikkelaars en één tester, en die ene tester is verantwoordelijk voor het schrijven van geautomatiseerde tests voor de code van al die vijf ontwikkelaars. Je kunt op je vingers natellen dat die situatie niet houdbaar is. – Dus wat te doen?
Een herwaardering van Fowlers Refactoring
Martin Fowlers Refactoring is een klassieker in het genre – en baanbrekend voor zijn tijd. Boeken over het ontwerp van nieuwe software bestaan al zo lang als dat software bestaat. Maar het idee dat je bestaande code aan kon passen – niet als noodzakelijk kwaad, maar als essentiële vaardigheid van elke programmeur –, dat was ongekend. – En toch was ik teleurgesteld toen ik het boek uitlas, drie jaar geleden.
First time right?
Na afloop van mijn praatje kreeg ik de vraag of ik geloof in het idee van first time right. Mijn antwoord was: “Ik geloof niet dat er zoiets bestaat als first time right. Maar ik geloof wel in first time een stuk beter dan we het nu doen.” Tijd om dat antwoord verder uit te werken, was er op dat moment niet. Maar de vraag bleef wel in mijn achterhoofd spoken. Is het mogelijk om een systeem in één keer goed te bouwen?
Codefluisteren
Een goede codefluisteraar kan in een stuk code werken en hoort dan – aanvankelijk zachtjes, maar met ervaring steeds duidelijker – plots een probleem. Het probleem is niet: de code werkt niet. Het probleem is: ik als ontwikkelaar ben nu harder aan het werk dan de code.
Overpeinzingen (over vakmanschap)
“Ziet u niet hoe vaklieden, hoewel zij tot op zekere hoogte bereid zijn om hun opdrachtgever tegemoet te komen, zich niet kunnen veroorloven af te wijken van de voorschriften van hun vak? Is het niet verbazingwekkend en teleurstellend tegelijk dat bij een architect en een geneesheer de grondbeginselen van hun vak meer gerespecteerd worden dan bij de rede bij de doorsneemens, terwijl het juist de rede is die hij met de goden gemeen heeft?”