Auteur: Niels Doesburg

Het risico van in-house softwarebouw

Binnen het bedrijfsleven wordt veel software ontwikkeld, een deel daarvan betreft in-house softwarebouw. Het is mogelijk dat in-house ontwikkelteams het risico lopen op een onevenwichtige aandachtverdeling tussen functionele en structurele kwaliteit tijdens de bouw van de software. Hoe kan het risico hierop worden ingeperkt?


In-house softwarebouw
Vanaf de jaren ‘70 was een belangrijk deel van de IT-ondersteuning van bedrijfsprocessen gebaseerd op de inzet van standaard softwarepakketten. Tegenwoordig is de inzet van softwarepakketten niet meer vanzelfsprekend, en is het laten bouwen van software voor veel bedrijven een realistische optie. De “build-or-buy” keuze die het management moet maken voor de ondersteuning van bedrijfsprocessen valt vaker dan voorheen uit in het voordeel van “build”, de software laten bouwen. Daarvoor zijn hele diverse redenen aan te wijzen. Denk aan de dalende kosten van de benodigde infrastructuur voor softwarebouw, de verbeterde overdraagbaarheid van het beheer van custom software, het groeiende aantal software gedreven bedrijfsmodellen en de hogere verwachtingen van consumenten ten aanzien van flexibiliteit in de procesgang.

Sommige bedrijven gaan nog verder op het “build”-pad. Zij maken niet alleen de keuze voor het laten bouwen van de benodigde software, maar kiezen ervoor om dit in-house te bouwen, ondanks het feit dat softwarebouw niet hun primaire proces is. De organisatie stelt zelf een team samen, bestaande uit mensen van binnen en buiten de organisatie.


Het verschil tussen functionele kwaliteit en structurele kwaliteit
De kwaliteit van software bestaat uit twee aspecten, namelijk de functionele kwaliteit en de structurele kwaliteit. De functionele kwaliteit is de mate waarin de software voldoet aan de functionele specificaties en criteria. Doet de software wat de gebruikers nodig hebben? De structurele kwaliteit is de wijze waarop de software is opgebouwd. Is de opbouw logisch, schaalbaar, eenvoudig aan te passen en te analyseren? Het risico bestaat dat structurele kwaliteit onvoldoende aandacht krijgt in een in-house ontwikkelteam.


Risico op onevenwichtige aandachtverdeling
De opbouw van het in-house ontwikkelteam en de context van de organisatie kan ervoor zorgen dat het team het structurele aspect van de softwarekwaliteit uit het oog verliest. Hierbij enkele voorbeelden die een dergelijke onevenwichtigheid zouden kunnen veroorzaken:

De Product Owner en budgethouder van het in-house ontwikkelteam kent de business zeer goed, en kan de belangen uitstekend inschatten, maar heeft meestal geen achtergrond in softwarebouw. De ontwikkelaars moeten dus erg goed kunnen communiceren en zeer sterk in hun schoenen staan om uit te leggen waarom bepaalde keuzes met betrekking tot de structurele kwaliteit beter zijn dan andere.

Wanneer de bewijsdrang in het team hoog is, of bepaalde ontwikkelaars zich graag presenteren als slim en snel, kan er een toxische interactie ontstaan tussen de Product Owner en de betreffende ontwikkelaars waarbij het realiseren van functionaliteit wordt beloond, maar waarbij de borging van een beheerbare, schaalbare en begrijpelijke software-architectuur ontbreekt.

De organisatie waarin het team opereert kan veel nadruk leggen op de business cases achter de tijdsverdeling van de ontwikkelaars. Maar wat is de business case van een goede errorlogging-infrastructuur of een logische modularisering? De business case voor een degelijke software-architectuur is lastig te kwantificeren en bestaat hoofdzakelijk uit het voorkomen van oplopende kosten (en niet onbelangrijk: gedemotiveerde ontwikkelaars). Wanneer de software wordt opgebouwd met short-cuts, workarounds en andere structurele zwakheden, zal het in de loop van de tijd steeds meer moeite kosten om de applicatie te begrijpen, monitoren, analyseren, wijzigen en uit te breiden.


Typische symptomen van onevenwichtige aandachtverdeling
De volgende tekortkomingen in de software zijn typerend voor het ontbreken van voldoende aandacht voor de structurele kwaliteit van de software:

  • Gebrekkige error-handling zodat de gebruiker geen notie heeft dat z’n data corrupt is nadat een fout in de code is opgetreden,
  • Gebrekkige logging, zodat opgetreden fouten lastig zijn te constateren en op te lossen,
  • Onvolledige autorisatie-implementatie waardoor sommige API’s voor de hele organisatie (en wellicht daarbuiten) openstaan,
  • Gebrekkige validaties op de juistheid en volledigheid van de invoer door de gebruiker,
  • State-management, het vasthouden van de fase waarin het programma of het bewerkte object nu is, wordt met losse variabelen bijgehouden verspreid door de logica in plaats van op één centrale plek met voor gedefinieerde scenario’s,
  • Geen modularisering maar directe connecties tussen alle onderdelen van de applicatie,
  • Geen abstracties voor onderdelen die in de toekomst mogelijk vervangen gaan worden, maar verwevenheid van deze onderdelen met aangrenzende logica,
  • Gebrekkige inline documentatie,
  • Onduidelijke naamgeving van directories, files, functies en variabelen, waardoor nieuwe ontwikkelaars de samenhang van de code niet goed kunnen doorzien,
  • Inconsistente syntax waardoor het lezen en begrijpen van de code tijdrovend wordt


Risicobeperkende maatregelen
De maatregelen om het risico van onevenwichtige aandachtverdeling tussen beide aspecten van softwarekwaliteit binnen het in-house ontwikkelteam te beperken liggen voor de hand, maar deze zijn niet eenvoudig te implementeren:

  • Borg dat alle ontwikkelaars voldoende conceptueel denkvermogen hebben, en dat er voldoende senioriteit binnen het team aanwezig is.
  • Borg teamspirit en voorkom haantjesgedrag.
  • Borg een goed ontwerp van de applicatie en nieuwe features, die door het hele team gedragen worden.
  • Zorg dat de organisatie, stakeholders en de Product Owner begrijpen dat het bouwen van software meer is dan code kloppen, en dat softwarekwaliteit uit twee delen bestaat: Functionele kwaliteit en structurele kwaliteit.

Specifiekere vragen?

Vul uw e-mailadres in en Oliver IT neemt zo spoedig mogelijk contact met u op!

Gelukt! We nemen spoedig contact met u op!
Eddy Driessen Consultant
Eddy Driessen