De ‘ouderwetse’ softwareontwikkelaar.

Toen ik onlangs bij één van mijn relaties op bezoek was, stelde hij de opmerkelijke vraag of ik in mijn netwerk nog wat bedrijven had die aan ouderwetse softwareontwikkeling deden. Ik moest er om lachen en stelde uiteraard de wedervraag waar hij op doelde. Hij vertelde dat zijn 6 jaar oude webshop nodig aan vernieuwing toe is en dat hij een viertal partijen had uitgenodigd om te horen of zij hem konden helpen. “Ik wist niet wat ik hoorde” sprak hij met verontwaardigde toon. “Ze hebben het allemaal over ‘agile’ en ‘lean’! Iedereen is aan het ‘scrummen’. Het gaat over ‘sprints’ en over ‘user story’s’. Het old-school planbord heeft plaats gemaakt voor een Kanban board. En oh ja, iedereen heeft de mond vol over ‘continues improvement’…”

Alleen maar voordelen

Zijn verontwaardiging en onbekendheid met de materie hadden geleid tot een zekere mate van irritatie. En die was kennelijk zo hoog opgelopen dat geen van de partijen nog in staat was geweest om tot hem door te dringen toen men de voordelen ging benoemen. In alle rust mocht ik een poging wagen. En dus hadden we het al snel over het verkorten van de ‘time-to-market’, over de mogelijkheid om tussentijds invloed uit te oefenen op het resultaat, over het inzicht tijdens en op het proces, en over een optimale ‘Return On Investment’. Kortom, hoe ziet softwareontwikkeling er vandaag de dag uit.

Softwareontwikkeling evolueert

Ik legde hem uit dat het conventionele ontwikkelproces niet meer past in deze tijd. Hij had namelijk verwacht dat er allereerst een functioneel ontwerp zou worden gepresenteerd. En dat ontwerp zou, na zijn goedkeuring, aan de basis hebben gelegen van de feitelijke ontwikkeling. Waarschijnlijk had er tussen het eerste contact en de feitelijke oplevering een periode van enkele maanden gezeten. En dan was het nog maar de vraag of hetgeen hij voor ogen had ook daadwerkelijk werd geleverd.

Kwaliteit leveren

“Tegenwoordig gebeurt dat anders” mocht ik hem uitleggen. Iedere ontwikkelpartij weet dat zijn klanten meer dan ooit om snelheid en flexibiliteit vragen. ‘Marketing is de baas’ en naar het zich laat aan zien gaat dat ook nooit meer veranderen. Als een marketeer vandaag iets bedenkt wil hij dat bij voorkeur morgen al live hebben. En daar houdt het niet mee op. Men wil uit kunnen proberen. Men wil kunnen testen wat bijvoorbeeld de impact is van het veranderen van een kleur van een button, om maar iets basaals te noemen. Implementeer je een nieuwe wijze van softwareontwikkeling dan kan dat allemaal. Mijn gesprekspartner onderbrak mij: “O ja, daar hadden ze het ook allemaal over… ‘user experience’ en ‘customer journey’ werd met regelmaat genoemd”. Ik deed een poging om hem uit te leggen wat dat dan behelst. “Bottomline is dat je je gebruikers en bezoekers zoveel als mogelijk de hoogste kwaliteit wilt leveren. En die kwaliteit moet er uiteindelijk toe leiden dat ze, zoals bij jou het geval is, meer gaan bestellen, als ambassadeur op gaan treden, terug komen, enzovoort”.

Ook andere bedrijfstakken moeten mee

Langzaamaan zag ik hem ontdooien. Hij begon de voordelen er van te zien en zou het allemaal nog even laten bezinken. Ik vroeg mij af of hij het allemaal wel had begrepen. De vraag die hij vervolgens stelde maakte echter in één keer duidelijk dat hij weldegelijk in zag wat dit alles behelsde. Hij zei namelijk dat deze evolutie in softwareontwikkeling ook bij andere industrieën het nodige teweeg zou brengen. En daarmee sloeg hij de spijker op zijn kop.

Tijd is geld

De beweging in softwareontwikkeling die in gang is gezet leid er toe dat ook Managed Service Providers (aka hostingbedrijven) moeten veranderen. En liever vandaag dan morgen. Vanuit een conventioneel perspectief gezien faciliteren zij Ontwikkel, Test, Acceptatie en Productie omgevingen (voor de kenners: de befaamde OTAP straat). Deze straat wordt gebruikt om op een gestructureerde wijze nieuwe releases uit te rollen. Geheel in lijn met ITIL processen . Het op deze wijze implementeren van nieuwe applicaties draagt bij aan een hoge mate van kwaliteit en een doorgaans voorspelbaar resultaat. Maar uiteraard zijn er ook nadelen. Zeker als we die afzetten tegen het al eerder genoemde ‘continues improvement’. Eén van de belangrijkste is misschien wel de doorlooptijd. Want hoe flexibel je als organisatie ook bent, het doorlopen van een OTAP proces kost nu eenmaal tijd. En tijd dat is vandaag de dag zo’n beetje het sleutelwoord. Alles moet immers sneller dan snel.

Automatisering en cultuur

Mijn gesprekspartner was uiteraard benieuwd hoe de branche daar dan op inspeelt. Ik liep naar een whiteboard en schreef daar twee woorden op: automatiseren en cultuur. Dat was de kapstok van de rest van mijn betoog. “Als een ontwikkelaar allerlei tools en werkwijzen omarmt die moeten leiden tot een versnelde implementatie van nieuwe software (of dat nu een applicatie of een website is) dan zal de partij die de infrastructuur faciliteert en het beheer voor rekening neemt daar ook zijn voorzieningen voor moeten treffen. En dus verwacht men dat ook zij daar in mee gaan. Dat automatisering van processen daarbij van cruciaal belang is spreekt voor zich. Feitelijk hebben we het dan over het faciliteren van ‘continues delivery’ en ‘continues integration’. Niet zo simpel om dat in een paar woorden uit te leggen, maar het komt er op neer dat ze het proces van softwareontwikkeling naar test, naar acceptatie en naar productie zo veel als mogelijk automatiseren. Zaken die men gewend was ‘handmatig’ te doen, doet men nu via allerlei tooling.

Minder fouten, meer testen

Automatisering zorgt voor versnelling van processen, maar draagt tevens bij aan het elimineren van fouten. De kwaliteit van softwareontwikkleing neemt dus toe, niet alleen van de code, maar ook van de onderliggende service. Maar er zijn nog meer voordelen. Juist vanwege de enorme versnelling van processen is het nu mogelijk om relatief kleine wijzigingen uit te rollen en desgewenst op een beperkt publiek te testen.” Ik haalde de al eerder genoemde kleur van een button aan. “Er zijn allerlei mechanismen om een wijziging niet direct voor iedereen beschikbaar te maken, maar om dat batchgewijs te doen. Valt het resultaat tegen, dan draai je het terug. Doet het wat je verwachtte dan geef je iedereen die nieuwe functie. Facebook doet niet anders. Er zijn over de gehele wereld diverse releases in omloop. Alles wordt nauw gezet gemonitord en geanalyseerd, maar tegelijkertijd is de beschikbaarheid gegarandeerd.”

Verandering is cruciaal

“En wat doet dat allemaal met de beheerders?” hoorde ik van de andere kant van de tafel. “Die moeten dan toch ook veranderen?” Dat bleek een prima bruggetje te zijn naar het volgende onderwerp: cultuur. “Om mee te gaan in de evolutie van softwareontwikkeling moeten alle betrokken disciplines drastisch veranderen. Meer dan ooit moet iedereen samenwerken. Een beheerder moet weten wat een ontwikkelaar drijft en vice versa. Er zal sprake moeten zijn van een gezamenlijk project, een gezamenlijk doel en een gezamenlijke inspanning. Tooling, processen en beloning zullen op elkaar afgestemd moeten worden. Geen eilandjes meer en geen ‘dit is niet mijn probleem’-mentaliteit. Kortom, een gedeelde verantwoordelijkheid.

Een andere cultuur

En zo komen we op dat andere fenomeen uit deze tijd: DevOps. Development en Operations kruipen als het ware tegen elkaar aan. De van oudsher aanwezige scheidslijn moet beslecht worden, maar je kunt je voorstellen dat dat verder gaat dan sec het faciliteren van automatisering. Het is een complete cultuurverandering die zowel bij de gemiddelde softwareontwikkelaar als bij een managed service provider nog flink wat voeten in aarde zal hebben, maar daar wordt aan gewerkt.”

Niet alles veranderen!

Het ‘luisterend oor’ stond op en vroeg of ik nog een kop koffie wilde. Ik liep met hem mee naar de keuken en was blij verrast te zien dat hij nog filterkoffie zette. “Of duurt dat je te lang?” vroeg hij. Ik schudde nee. Sommige dingen moet je lekker ouderwets laten.