Developer teams: een code-fabriek?

Onlangs schreef Jefry een artikel over agile, een containerbegrip in IT waar iedereen zo z’n eigen betekenis aan geeft. Een andere trend in software-ontwikkeling die alweer meer dan 10 jaar geleden is ontstaan, is DevOps: een samenvoeging van Development (ontwikkeling) en Operations (het onderhouden en implementeren van software). Ook hierover is al zoveel geschreven dat er veel manieren zijn om het te interpreteren. Dus excuses, hierbij nóg een blog over dit onderwerp ;)

In de basis houdt DevOps in dat het bouwen van software en het uitrollen, testen, onderhouden en in de markt brengen ervan, niet door verschillende afdelingen wordt gedaan, maar gezamenlijk. Een team van programmeurs wordt dus niet beschouwd als een afgezonderde codefabriek waar voorgekauwde instructies naartoe gaan en een ingepakte software-oplossing uit komt zetten die de implementatie-afdeling vervolgens in de markt gaat brengen, maar als een samengesteld team dat voortdurend nieuwe features toevoegt, test en uitrolt.

Bij jem-id zijn we fanatieke aanhangers van dit principe, maar het gaat verder dan alleen een continue ontwikkelstraat met wat geautomatiseerde tests. Onze visie is namelijk dat ontwikkelaars niet alleen bij de operatie extra betrokken moeten worden, maar ook bij de klantimplementaties, ondersteuning, growth hacking en productontwikkeling. Dit vereist programmeurs met een flinke portie domeinkennis en dus ook vaste krachten die zich jarenlang in de problematiek van de markt/eindgebruiker verdiepen. 

Mocht je dat in één term willen uitdrukken, zou je tot een tamelijk onzinnige afkortingencombinatie als BizDevSupImpMarOps komen. Die gebruiken we dus ook niet serieus. Wel leg ik graag uit wat we ermee bedoelen.

Continue verbetering

Door programmeurs ook bij de operations en support te betrekken, ontstaat er een feedback loop die de software robuuster maakt. Elke storing of probleem grijpen we aan als kans om er beter van te worden. Een paar voorbeelden hoe dit tot uiting komt:

• In plaats van snelle fixes in de database, beheerschermen toevoegen of uitbreiden met tools die vaker gebruikt kunnen worden, ook door de helpdesk
• Onverwachte fouten slimmer afhandelen zodat niet meteen een heel scherm vastloopt zodra een bepaalde database tijdelijk slecht bereikbaar is, met React error boundaries en retry-mechanismes
• Logging toevoegen of uitbreiden voor meer inzicht bij het uitzoeken van bugs
• Alerts inrichten voor onverwachte fouten (zo gebruiken we de Slack-integratie van Sentry) of bijvoorbeeld hoog cpu-gebruik
• Dashboards (in ons geval in Grafana) om snel inzicht te krijgen of processen goed verlopen
• Deployments sneller maken (Gitlab pipelines) zodat fixes nog sneller van ontwikkeling naar productie gaan
• Bij grote storingen vindt dit proces plaats via een zogenaamde post mortem; een meeting waarbij uitgebreid geëvalueerd wordt hoe de storing is ontstaan en voorkomen had kunnen worden. Maar bij elke kleine bug of vraag zit dit in het proces van de ontwikkelaars.
  
  

Productontwikkeling

We betrekken developers dus volop bij de support en monitoring, maar ook bij het uitwerken en bouwen van nieuwe features. In andere organisaties zie je dat een product owner een idee uitwerkt, een designer de schermen ontwerpt, een enterprise architect de endpoints uitdenkt en de developer vervolgens alleen de specificaties van een business analist vertaalt naar code.

Het testen van nieuwe ideeen met eindgebruikers worden ook wel ideation sessies genoemd. Daarna wordt er in een refinement meeting met developers nagedacht over hoe het ingebouwd wordt, welke entiteiten er zijn, hoe de communicatie tussen de schermen en de back-end plaatsvindt etc. Niet alleen maakt dat het werk van developers veel leuker omdat je het grote plaatje ziet, ook kan je vaak een stuk efficiënter werken door vooraf mee te denken over de oplossing. Daarnaast kunnen developers vaak het beste de gevolgen van nieuwe aanpassingen inschatten en zo de juiste vragen stellen aan product owners.

Growth mindset

Tot slot is het ook heel waardevol als developers meedenken over de adoptie van nieuwe functies en doelgerichte marketing. Zo passen we soms gamification toe om gebruikers een bepaalde richting op te sturen (een voortgangsbalk om je profiel te voltooien bijvoorbeeld), en worden marketing tools als Intercom slim ingezet en vanuit code aangestuurd voor doelgerichte communicatie.

Bij growth hacking gaat het er vaak om het grootste succes te boeken met een beperkt aantal resources. Developers zijn bij uitstek degene die gedurende een brainstorm de impact van ideetjes kunnen inschatten en op basis van technische haakjes met heel andere ideeën kunnen komen (in het boek How Google Works is hier ook een hoofdstuk aan gewijd).

Conclusie

Zoals je wel leest, zien we developer teams bij jem-id zeker niet als een gesloten code-fabriek, maar ben je als programmeur betrokken bij veel verschillende vakgebieden. Voor mij persoonlijk maakt dat het werk ook nog eens veel leuker, omdat je aan een proces van continue verbetering werkt en betrokken bent bij het hoe en waarom van nieuwe uitbreidingen.