Streven naar succesvolle software

Een bedrijf waar ik als consultant werkte, had problemen met zijn synchronisatie. De synchronisatie tussen de microservices van hun softwaresysteem was niet geïmplementeerd volgens de noden van de gebruikers. Bovendien faalde ze ook vaak. De gebruikers voegden informatie toe of wijzigden ze op één UI-scherm, maar op andere UI-schermen verscheen ze niet, of pas uren later. Daardoor verdween het vertrouwen in het softwaresysteem. Te veel fouten tijdens de synchronisatie zonder enige melding, en slechte vereisten, zorgden ervoor dat de gebruikers het softwaresysteem niet meer vertrouwden.

Omdat de gebruikers software nodig hadden die ze konden vertrouwen, kochten ze hun eigen applicaties en gebruikten ze die in de plaats. Die applicaties hadden gelijkaardige functionaliteit als hun interne software. Daar had niemand baat bij, want:

Het bedrijf moest duizenden neertellen voor nieuwe software, terwijl zijn bestaande software al hetzelfde kon.
De softwareteams moesten meer synchronisaties bouwen (waar ze niet zo goed in waren) en uren besteden aan het implementeren van functionaliteit die niemand gebruikte.
De business moest voortdurend schakelen tussen meerdere applicaties, omdat de aangekochte software niet alle vereiste functionaliteit had. Ze moesten het interne softwaresysteem nog steeds gebruiken, maar vertrouwden het niet, wat spanning veroorzaakte tussen business en IT.

Om het vertrouwen te herstellen en hun faalproblemen op te lossen, begon ik een campagne om die problemen aan te pakken. Maar vertrouwen herstellen is een traag proces.

Dit is maar één bedrijf, en de software is intern, dus in het grote geheel geen ramp. Maar ik heb dit ook bij andere bedrijven zien gebeuren. Ze vervangen hun huidige applicaties of softwaretools door nieuwe, omdat die niet deden wat ze beloofden. In sommige gevallen was de software te moeilijk in gebruik, in andere gaf ze te veel foutmeldingen. Wat de reden ook was, de software bezorgde hen gewoon geen succesvolle ervaring.

Om als bedrijf succesvol te zijn, moet onze software ook succesvol zijn. Maar wat betekent het om succesvolle software te hebben? In deze blogpost overloop ik de definitie van succesvolle software en de principes en praktijken die je helpen om dat te bereiken.

Wat is succesvolle software?

Het succes van software hangt af van een mix van technische, zakelijke en gebruikersgerichte factoren:

Ze levert over een langere periode waarde voor meerdere stakeholders.
Ze is stabiel en betrouwbaar: ze is gezond.
Ze kan evolueren.

Succesvolle software levert waarde.

Eerst en vooral is software waardevol wanneer ze waarde heeft voor haar gebruikers. Software helpt mensen om met hun problemen om te gaan. Toen ik nadacht over wat ik met mijn carrière wilde doen, wist ik dat ik mensen wilde helpen. Ik koos software maken als manier om dat te doen. Software hoort het leven van de gebruiker makkelijker te maken. Het lijkt erop dat we dat ergens onderweg vergeten zijn.

Maar succesvolle software ondersteunt ook de business. De meeste bedrijven bestaan om geld te verdienen, en software hoort de business te helpen om haar doelen te bereiken.

De software is gezond

Om gezond te zijn, moet software stabiel en betrouwbaar zijn.

Stabiele software draait consistent, zonder crashes of prestatieproblemen. Helaas is dat bijna onmogelijk, maar wanneer die zich toch voordoen, kan de software er netjes mee omgaan. Ons voorbeeld van de synchronisatie die niet werkte, zonder enige melding van wat er eerder misliep, is een goed voorbeeld van onstabiele software. Wat onze infrastructuur betreft: het grootste deel van onze software draait nu in de cloud, en daar hoeven we ons niet (veel) zorgen meer over te maken. Dat is een goede zaak, al gaat het, wanneer het misgaat, ook echt goed mis. Maar we moeten nog steeds naar die infrastructuur kunnen deployen. Stabiele software betekent dus ook dat we tijdig en veilig kunnen deployen.

Betrouwbare software betekent dat de software doet wat ze hoort te doen vanuit het perspectief van de domeinlogica. Software hoort haar functies consistent uit te voeren, en volgens de verwachtingen van haar stakeholders. Wij, de gebruikers van de software, horen niet verrast te worden wanneer we onze software gebruiken, omdat er iets anders gebeurt dan we verwachtten. Wanneer software ons te vaak verrast terwijl we ze gebruiken, verliezen we ons vertrouwen erin. Zodra dat vertrouwen weg is, zoeken we ofwel andere oplossingen, ofwel voelen we dat we onszelf moeten beschermen tegen onverwachte resultaten.

De software kan evolueren in de loop van de tijd

De markt is geen vast gegeven; ze verandert voortdurend. Nieuwe bedrijven ontstaan, andere bedrijven verdwijnen, de wensen en noden van de klant veranderen, enzovoort. Wanneer de markt verandert, moet het bedrijf mee veranderen. Het moet zijn doelen, zijn businessplannen en zijn focus herbekijken en aanpassen. Dat heeft een impact op de software. Software is dus ook geen vast gegeven. Om succesvol te zijn, moet software kunnen mee-evolueren met het bedrijf en de markt. Features verwijderen die niet meer nodig zijn, features toevoegen die gewenst zijn, en veranderen hoe features werken.

Ook technologie is een volatiele markt. Soms maken technologische veranderingen bepaalde features mogelijk. Om voorop te blijven, moeten we de software ook vanuit technisch perspectief laten evolueren. Frameworks en libraries moeten up-to-date zijn om toegang te hebben tot de nieuwste features die ze te bieden hebben. Maar terwijl sommige elementen in je softwaresysteem moeten evolueren, moeten andere stabiel blijven om onderhoudbaar te zijn.

Succesvolle software is dus zowel evolueerbaar als onderhoudbaar.

Hoe maak je je software succesvol?

Wat we willen is succesvolle software, maar hoe komen we daar? Er zijn een paar dingen die je nodig hebt om succesvolle software te bouwen:

Afstemming op de business,
Operationele excellentie,
Veerkrachtig ontwerp, architectuur en modellering,
Feedbackloops,
Cultuur, team en organisatie.

Afstemming op de business

Om waardevolle software te leveren, moet je de business begrijpen. Je software moet afgestemd zijn op de strategische en financiële doelen van het bedrijf. Ik zie vaak een kloof tussen de strategie van het bedrijf en die van de software. Onlangs plande het ontwikkelteam bij een klant om het komende jaar zwaar te refactoren, terwijl de business tegelijk plande om binnen de 24 maanden 3 nieuwe producten op te nemen. Of een van de teams wil Kafka gebruiken, maar kan niet uitleggen waarom dat waardevol is voor het bedrijf. Dat zijn voorbeelden van een gebrek aan afstemming tussen de business en de software. Er zijn manieren om dat te vermijden. Domain-Driven Design (DDD), een ontwerpdiscipline, helpt je om je software beter af te stemmen op de business.

Veerkrachtig ontwerp, architectuur en modellering

Als we naar een business kijken, bijvoorbeeld financiën, dan zijn er heel wat bedrijfsprocessen, regels en policies van kracht. Het kan heel snel ingewikkeld worden wanneer we daar software voor proberen te ontwerpen. Eén enkel model proberen te ontwerpen dat elk aspect van een probleem kan uitdrukken, leidt tot meer problemen. We moeten goede domeinmodellen ontwerpen die een specifiek probleem oplossen. Om daarmee om te gaan, ontwerpen we grenzen, in DDD bounded contexts genoemd. Bounded contexts helpen ons complexiteit te beheersen. Ze laten ons toe om onze domeinmodellen binnen de bounded context te verfijnen, zonder ons zorgen te hoeven maken over de impact daarvan op ons hele softwaresysteem. Goede bounded contexts ontwerpen is niet eenvoudig, maar het geeft ons softwaresysteem een grote veerkracht en aanpasbaarheid. Ze worden modules in een monoliet of microservices in onze architectuur, en helpen ons om onze software te laten evolueren.

Operationele excellentie

Features leveren pas waarde op wanneer ze in productie staan, beschikbaar voor je klanten. Operationele excellentie is een reeks praktijken die erop gericht zijn om de waardelevering in softwareontwikkeling te maximaliseren. Voor softwareteams betekent dit systemen bouwen, deployen en onderhouden op een manier die hoge prestaties en continue verbetering mogelijk maakt.

Testen is volgens mij de belangrijkste praktijk van operationele excellentie. Tests implementeren helpt developers om problemen vroeg te ontdekken, vermindert menselijke fouten en geeft hen het vertrouwen om code te wijzigen terwijl ze nieuwe features implementeren. Verschillende soorten tests helpen je met verschillende dingen:

Unittests: testen individuele eenheden code (bv. functies, methodes of klassen) in isolatie, om te verzekeren dat ze werken zoals verwacht.
Integratietests: testen de interactie tussen meerdere componenten en/of systemen (bv. databases, API's, services) om te verzekeren dat ze correct samenwerken.
End-to-endtests: testen de volledige workflow van de applicatie vanuit het perspectief van de gebruiker, en simuleren zo het echte gebruik. Vaak gebeurt er voor end-to-endtesten ook wat manueel testwerk door QA-mensen.

Een goede tweede praktijk die softwareteams helpt met hoge prestaties en continue verbetering, is de automatisering van softwarelevering. Automatisering van softwarelevering wordt vaak "de CI/CD-pijplijn" genoemd, en gebruikt geautomatiseerd testen, continuous integration (CI) en continuous delivery (CD) om op een veilige manier sneller waarde naar productie te brengen. Het versnelt processen en maakt je teams vrij om zich te concentreren op innovatie. De DORA-metrieken zijn een prima startpunt om te meten hoe goed je software kunt leveren.

Er zijn nog veel meer praktijken, zoals monitoring, caching en infrastructure as code. Ervoor zorgen dat softwareteams goed presteren en continu kunnen verbeteren, is een job op zich (DevOps). Operationele excellentie is geen eenmalige inspanning—het gaat om leren, aanpassen en evolueren.

Feedbackloops

Succesvolle software levert waarde voor haar klanten. We zijn er echter niet altijd zeker van of een idee waardevol zal zijn voor onze klant. Daarom hebben we feedbackloops nodig. Veel bedrijven hebben feedbackloops op het einde van de ontwikkelcyclus, wanneer alle betrokkenen al het werk al gedaan hebben. Zulke trage feedbackloops vereisen dat onze ideeën juister zijn, omdat het duurder is als ze dat niet zijn. Toch beschikken we niet over de informatie die ons dat kan vertellen.

Wat we nodig hebben, zijn snellere feedbackloops en korte iteraties. Snelle feedback en korte iteraties laten je toe om vroeger te leren, te verbeteren en bij te sturen, en dus goedkoper. Het begint met ons idee valideren. Ten eerste kunnen we kijken wat het minimale waardevolle ding is dat we kunnen doen, in plaats van meteen alles te implementeren. Ten tweede willen we ons idee zo snel mogelijk aan onze gebruikers/stakeholders voorleggen om er feedback op te krijgen. We kunnen mock-ups maken, ze tonen en kijken wat onze gebruikers ervan vinden.

Zodra we vastgesteld hebben dat het de moeite waard is om in ons idee te investeren, kunnen we het beginnen ontwerpen. Collaboratief modelleren is een goede manier om vroeger feedback te krijgen. Prototyping ook. Naast prototyping en collaboratief modelleren zijn er nog veel feedbackloops mogelijk die ons belangrijke informatie geven. Tests zijn een vorm van feedback die ons vertelt of we al dan niet iets breken terwijl we onze code wijzigen. A/B-testen is een manier om gebruikersonderzoek te doen naar welke van onze oplossingen ons probleem het doeltreffendst oplost.

Cultuur, teams en organisatie

Geen van de voorgaande punten is haalbaar zonder een gezonde bedrijfscultuur. Een "bemoei je met je eigen werk"-houding maakt afstemming op de business onmogelijk. Als teams door hoepels moeten springen om hun softwarelicenties goedgekeurd te krijgen, lijdt de operationele excellentie eronder. Wanneer teams ingedeeld zijn volgens vaardigheid (productmanagers, front-end, back-end), zal je ontwerp suboptimaal zijn.

Ik heb dit allemaal bij bedrijven gezien. Een bedrijf heeft een cultuur nodig die continu leren aanmoedigt, met financiële steun achter die aanmoediging. Het heeft een cultuur nodig die teams autonomie geeft, met ruimte voor experiment en om op een gezonde manier te leren uit fouten.

Conclusie: software bouwen die blijft duren

De anekdote waarmee ik begon, herinnert ons eraan wat er gebeurt wanneer software niet voldoet aan de basisverwachtingen van haar gebruikers. Dit is geen alleenstaand geval; het is een probleem van de hele sector. Ik zie overal waar ik kijk onsuccesvolle software. En die ergert niet alleen de gebruikers; ze kost bedrijven geld, vertrouwen en kansen.

Succesvolle software is meer dan code die werkt—ze levert blijvende waarde, is gezond en kan zich aanpassen aan verandering. Maar dat bereiken vraagt meer dan technisch kunnen. Het vraagt afstemming - ervoor zorgen dat je softwarestrategie je bedrijfsdoelen weerspiegelt. Het vraagt veerkracht - systemen ontwerpen die verandering kunnen opvangen zonder te breken. Het steunt op operationele excellentie - levering automatiseren, grondig testen en continu monitoren. En het gedijt op feedback - de lus tussen idee en validatie verkorten, zodat je sneller kunt leren, bijsturen en verbeteren.

Het belangrijkste is dat succes geworteld is in cultuur. Een cultuur die samenwerking bevordert, teams autonomie geeft en leren omarmt - ook uit fouten - is het fundament van software die niet alleen functioneert, maar floreert.

Dus, stel jezelf de vraag: Is jouw software klaar voor succes?

Hoe we je bedrijf kunnen helpen om succesvolle software te bouwen

Worstel je met software die geen waarde levert, onverwacht crasht of verandering niet kan bijhouden? We zijn gespecialiseerd in teams en bedrijven helpen om hun software te transformeren van een bron van frustratie naar een betrouwbaar, waardevol en aanpasbaar bezit. Of je nu een nieuw product lanceert, legacy-systemen moderniseert of je technologie- en bedrijfsstrategie op elkaar probeert af te stemmen, we bespreken graag hoe we kunnen samenwerken. Neem contact op om het gesprek te starten.