Tag waarde
Blijven we dit ondersteunen?
Onze legacy-applicatie focust zich op de constructie van toetsen, niet op de afname. Om de afnameomgeving te kunnen bekijken, heeft de applicatie een integratiepunt met een externe tool. Maar de laatste tijd levert die functionaliteit vooral veel frustratie op. Problemen met de externe tool worden op onze applicatie geschoven, en het gedrag met de geïntegreerde versie is bij een grote load inconsistent met die van de externe tool. De klachten over de integratie vreten tijd van het ontwikkelteam, en zorgen bovendien voor frustraties over en weer naar de stakeholders.
Bewuste technische schuld
Is technische schuld erg? Niet per se, zolang de keuze voor technische schuld maar een bewuste is. Als het team duidelijk maakt dat de oplossingsrichting technische schuld met zich meebrengt en afdwingt dat er op middellange termijn tijd wordt vrijgemaakt om die op te ruimen, hoeft die schuld geen probleem op te leveren. Integendeel: dankzij die schuld zijn we in staat om op korte termijn - vóór de deadline - waarde te leveren.
Tijd om te ontwerpen
Ik heb jarenlang als ontwikkelaar code kunnen kloppen zonder ooit maar één stroomdiagram te hoeven bekijken. Een grappig gegeven, want één van de eerste dingen die ik moest doen toen ik solliciteerde naar een traineeship als back end developer, was een cognitietaak waarbij ik steeds complexere stroomdiagrammen voor mijn neus kreeg. En om de indruk te wekken dat software ontwikkelen méér is dan alleen naar een scherm staren, moest ik dat doen in een ruimte behangen met foto’s van mensen die lachend naar whiteboards staan te wijzen.
Horizontale of verticale PBI's?
Een risico van horizontaal ontwikkelen is dat je veel tijd besteedt aan de back-end, om er vervolgens bij de implementatie van de front-end achter te komen dat je iets over het hoofd hebt gezien. Met als gevolg dat je alsnog verticaal aan het ontwikkelen slaat. Dat is niet alleen irritant, het is ook ontzettend inefficiënt!
Toevallige productieve ontmoetingen
Een collega van me omschreef de huidige, moderne functie van een kantoor als volgt: het faciliteren van toevallige productieve ontmoetingen. Ik viel bijna van mijn stoel toen ik dat hoorde (het was tijdens een borrel), zo’n mooie formulering vind ik het. Tegelijkertijd werpt het een licht op een gebeurtenis die voorheen zo alledaags en vanzelfsprekend was dat hij al die jaren aan mijn aandacht is ontsnapt: een collega tegen het lijf lopen bij de koffieautomaat.
Waarom we Developer Meet-ups organiseren
Sinds kort organiseren enkele enthousiaste collega’s en ik iets wat we een Developer Meet-up hebben genoemd. Dat is een informele bijeenkomst van geïnteresseerde softwareontwikkelaars binnen het bedrijf, die op een laagdrempelige manier ervaringen uitwisselen over een aan softwareonwtikkeling gerelateerd onderwerp. Waarom organiseren we Developer Meet-ups? In de intropraatjes dat ik als initiatiefnemer verzorg, onderscheid ik drie redenen.
Waarheid boven schoonheid
Anders dan Aristoteles, Kant en Wittgenstein, hebben we als softwareontwikkelaars de luxe ons niet bezig te hoeven houden met de metafysische grondstructuur van de werkelijkheid. Dat vereenvoudigt het ontwikkelen van onze applicaties aanzienlijk. Maar dezelfde hang naar schoonheid die ik bij filosofen zo amusant vind, duikt bij tijden ongemerkt in mijn eigen werk op.
Hoe technische schuld te monitoren én prioriteren
Software ontwikkelen is mensenwerk. Hoe goed de tooling tegenwoordig ook is, ze is niet meer dan een hulpmiddel voor ontwikkelaars om grip te krijgen op een codebase. De beste manier om technische schuld in beeld te krijgen, is dan ook niet door allerhande tools op je code los te laten, maar door erover te praten met je collega’s.
Moet je dit willen testen?
“Code is a liability, not an asset.” Van alle zinnen in Vladimir Khorikovs Unit Testing: Principles, Practices, and Patterns is deze me het meest bijgebleven. Ironisch, want op het eerste gezicht is het geen zin die iets te doen heeft met unit testing. Maar ook testcode kan een een blok aan het been zijn. Bijvoorbeeld wanneer je de code eigenlijk niet zou moeten willen unittesten.
Vijf voordelen van bloggen
Als ervaringsdeskundige ben ik heilig overtuigd van de waarde van het bijhouden van een blog - voor de lezer, maar misschien nog wel meer voor de schrijver. Dit zijn vijf voordelen voor de schrijver van het bijhouden van een blog.