Complexiteit: Controleren of Evolueren

 
15 oktober 2007

Vaak roep ik dat het kernpunt van software ontwikkeling de omgang met complexiteit is. In de geschiedenis van software ontwikkeling zie ik bijna alle stappen in het licht van beheersing van deze complexiteit van de software systemen, van procedures en object oriented programming tot service oriented architecture. De meeste ontwikkelaars knikken instemmend als ik dit roep en gaan daarna gewoon verder met ontwikkelen zoals ze dat altijd deden. Ze laten me achter met een gevoel dat ik iets heb verkondigd dat ze al jaren wisten en triviaal oplosbaar is. Hun code en applicaties vertellen echter een ander verhaal.

Ze proberen altijd de complexiteit te beheersen en te controleren. De technieken geven dit al aan door hun naamgeving. Tijdens mijn introductie in programeren werd mij vertelt te werken volgens het verdeel en heers principe: Deel een probleem net zolang op in kleine deel problemen totdat het probleem opgelost is. Dit is een logische aanpak als je een algoritmisch probleem hebt. De onderliggende aanname is wel dat het gaat om een statisch probleem. Er is een bepaalde invoer en gegeven deze invoer wordt er een uitvoer berekend. Dit proces kent geen willekeur. Elke stap is duidelijk, compact en volgt de vorige stap op.

In een modern systeem leeft deze code niet in een vacuum. Dat ene stukje code maakt deel uit van een groter geheel dat continue aan verandering onderheving is. Het draait onder een platform dat de code tijdens executie analyseert en optimaliseert. De applicatie communiceert daarnaast nog met heel veel andere software over de hele wereld, die weer wel of niet beschikbaar kunnen zijn. Steeds meer zien we dat een systeem verandert over tijd. Dit is een kenmerk van chaotische systemen. De dynamiek heeft nog niet het niveau bereikt dat we van onze software echt chaotisch is, maar het gaat wel deze richting uit.

Het verschil tussen complexiteit en chaos is dat chaos dynamisch en onstabiel is. Het verandert over tijd en een kleine verandering kan een groot effect hebben. Er is geen momentum dat een aanpassing of effect tegen werkt of localiseert. De verandering wordt omarmd in het systeem. Dit wordt ookwel de breakdown of predictability genoemd, het maakt een systeem onvoorspelbaar. Dit is een fundamentele eigenschap. Het is niet mogelijk deze onvoorspelbaarheid weg te nemen door meer analyse of informatie verzameling toe te passen.

In software ontwikkeling zien we al een aantal gevolgen van. We kunnen de gevolgen van een aanpassing in veel systemen niet met zekerheid vaststellen. Het is niet zo onvoorspelbaar dat we volledig willekeurig gedrag kunnen krijgen, maar het is wel bekend dat elke verandering een onbekend aantal bugs met zich meebrengt. Ook concurency kan vreemde fouten opleveren. Door ontkoppeling van gedrag naar verschillende systemen en de groei van de systemen zelf zal het phenomeen, mijns inziens alleen groeien.

Dit wil zeggen dat onze methode van ontwikkelen gebaseert op het onder controle houden van de complexiteit niet vol te houden is. Naar mate de complexiteit chaos wordt zullen onze huidige methoden falen. Een ontwikkelstijl moet niet meer gebaseerd zijn op het behouden van een volledig overzicht, maar zich richten op het interne gedrag en niet verder gaan dan dat gedrag.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Development

Tags: ,