Tag software ontwikkelen
Stapje voor stapje data migreren
Als er één constante is in softwareontwikkelland, dan is het wel dat software constant verandert. Nieuwe inzichten noodzaken ontwikkelaars om hun code aan te passen om bepaalde use cases (beter) te kunnen ondersteunen. Soms betekent dat dat er een aanpassing moet plaatsvinden in je model. Hoe ga daarbij om met data die nog is opgeslagen volgens het verouderd model?
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.
Check op permissies, niet op rollen
Op een gegeven moment begon onze autorisatiecode uit de hand te lopen. De code in onze front-end was haast onleesbaar geworden van alle rollenchecks die de logica vervuilde. Erop terugkijkend, hadden we twee fouten gemaakt in onze oorspronkelijke implementatie. Ten eerste hadden we gebruikers de mogelijkheid gegeven meerdere rollen te hebben, en ten tweede bevonden onze checks zich op een te grof niveau.
Werk en privé
Vergelijk de volgende twee zinnen eens met elkaar:
- “Ik ben een softwareontwikkelaar.”
- “Ik werk als softwareontwikkelaar.”
Zeggen ze hetzelfde?
De kwestie autorisatie
Onze Product Owner ging anderhalve week ondergronds met onze informatie-analist om een autorisatiematrix uit te tekenen. Toen hij het eindresultaat eindelijk presenteerde aan het team, leidde hij zijn verhaal in met de woorden: “We gaan jullie meenemen.” Dat was een slecht teken.
Incrementele versus iteratieve ontwikkeling
Als ik geen zin heb om over software ontwikkeling te lezen tijdens mijn ontbijt, zet ik een filmpje op YouTube op. Laatst keek ik er een van software architect George Fairbanks over de bijdrage van softwareontwikkelprocessen aan (het wegwerken van) technische schuld. Ik at die ochtend, als ik me het goed herinner, afbakbroodjes met jam. Het was dus in meerdere opzichten een prima begin van de dag.
Empathie met je stakeholders
Software ontwikkelen is meer dan alleen code schrijven. Sterker nog, één van de leukste dingen aan het vak is het scala aan competenties dat erbij komt kijken - en de ontwikkelmogelijkheden (no pun intended) die dat met zich meebrengt. Zo las ik onlangs bijvoorbeeld Articulating Design Decisions van Tom Greever en vond daar een schat aan informatie in, ondanks dat ik geen designer ben.
De architect, het team en de business
Ik vind dat een softwarearchitect mee moet draaien in een ontwikkelteam. Mijn leiddingevende is daar minder van overtuigd. “Vind je dan ook dat een architect mee moet draaien met de business?” vroeg hij me tijdens een discussie - retorisch uiteraard. Maar toen ik erover nadacht, vroeg ik me af: waarom eigenlijk niet?
Wat wil je zijn: een architect of een ontwikkelaar?
Mijn leidinggevende stelde me onlangs de vraag: “Wil je een softwarearchitect zijn of wil je een softwareontwikkelaar zijn die zich met architectuur bezighoudt?” Dat vond ik een confronterende vraag, omdat ik me tot dan toe nauwelijks gerealiseerd had dat er een verschil bestond tussen die opties. In deze blog onderscheid ik twee manieren waarop de rol van architect kan worden ingevuld binnen Scrum: als ontwikkelaar en als stakeholder.