Is maximale flexibiliteit in software wel de “holy grail”?

 
26 september 2008

Iedere programmeur is zich ervan bewust dat elk probleem op (ontelbaar) veel manieren is op te lossen. 2 belangrijke variabelen waar je als programmeur bewust of onbewust mee speelt zijn complexiteit en flexibiliteit. Complexe code is code die moeilijk te lezen/begrijpen is, vooral door anderen. Een flexibele applicatie kan gemakkelijk veranderingen ondergaan zonder dat er veel code veranderd hoeft te worden.

Er zijn veel mensen bezig met het zoeken naar de meest flexibele oplossingen, maar is dit wel de “holy grail”? Wanneer je nu software wil ontwikkelen die het beste kan inspelen op veranderingen, is het in veel gevallen niet de variant die het meest flexibel is. Dit omdat zeer flexibele code vaak erg complex te doorgronden is, en daardoor moeilijk op te pakken of te communiceren door andere programmeurs. Wat is dan de “sweet spot”? Moeten we weer terug naar basic, naar procedureel programmeren? Ik denk het niet. Deze code is vaak makkelijk te schrijven, maar wordt al gauw complex om te lezen voor grotere projecten. Daarnaast is de flexibiliteit erg laag hiervan. Een 3-lagen model dan? Komt al meer in de buurt. Dit is vrij eenvoudig te begrijpen voor de meeste programmeurs, en veranderingen zijn relatief eenvoudig door te voeren.

Het is dus NIET correct om aan te nemen dat er een evenredig verband bestaat tussen complexiteit en flexibiliteit. Als we naar onderstaand plaatje kijken, zien we dat de “sweet spot” ergens ligt waarbij de flexibiliteit hoog is, en de complexiteit laag is. Dit is een architectuur waarbij niet te ver vooruit gekeken wordt, maar waar veranderingen eenvoudig door te voeren zijn mede omdat de complexiteit laag is. Welke architectuur voldoet hier het meest aan volgens jou?


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


Categorieën: Architectuur

Tags: ,


Reacties (5)

  • Ligt er op dit architecten vlak dan niet juist een relatie met het agile gedachtengoed ‘ just enough’ en ‘use the right tool’ ? En dit elke keer weer.

    Een complexe oplossing is inherent inflexibel en anders wel inefficient, en dit kan los staan van de technische beperkingen welke een dergelijk systeem met zich meedraagt. Hierbij moet onderhoudbaarheid, begrips vorming, beschikbaarheid en instandhouding in meegenomen worden. Hoe dan ook. Elke oplossing is tijdelijk denk ik en dient slechts om de volgende milestone te behalen. Dit als feit aannemen en gebruiken zou een stap voorwaarts zijn.

    Leuke blog post om dit eens af te trappen.

    Geplaatst op 29 september 2008 om 23:30 Permalink

  • Ivo Limmen schreef:

    Al jaren zoek ik naar de mooiste framework die het helemaal gaat maken, en na al die tijd heb ik er maar een ding over te zeggen: die ene framework is er niet.
    Elk probleem heeft meerdere mogelijke (en werkbare) oplossingen variërend in techniek, framework(s) en de daarbij behorende flexibiliteit.
    De meest potentiële frameworks in mij optiek zijn toch wel OSGi en JINI. Ik ben met beide frameworks wel eens in aanraking gekomen. Toch kan ik er niet even mee spelen. Een “hello world” applicatie in JINI is hetzelfde als kijken of je een Ferrari F40 kan duwen: je toont de kracht er niet echt van.
    Ik denk dat DDD een prima techniek is als je het goed in zet: Service oriented en elke service heeft zijn eigen kleine domein (deel probleem).
    OSGi en JINI hebben dezelfde techniek: SOA maar dan niet met SOAP.

    Geplaatst op 29 september 2008 om 21:33 Permalink

  • Jasper Floor schreef:

    Met flexibiliteit moet je kijken naar wat het doel is van wat je bouwt. Te veel ‘flexibiliteit’ geeft zoals gezegd complexiteit. Dit maakt het systeem wat mij betreft dan ook direkt minder flexibel.

    Het is dan ook handig om niet meer te programeren dan dat wat strikt noodzakelijk is. De flexibiliteit bouw je in de structuur zodat er zonder te veel moeite complexere structuren in gebouwd kunnen worden. Weet je dat een systeem op een bepaalde manier gaat groeien kan je daar rekening mee houden. Van te voren rekening houden met dingen die mischien niet voorkomen moet je dus niet doen.

    Daarnaast vind ik Rob zijn antwoord heel mooi.

    Geplaatst op 29 september 2008 om 10:00 Permalink

  • Rob Vens schreef:

    Ik probeer meestal een beetje anders tegen complexiteit aan te kijken. Complexiteit is goed, we moeten duizenden keren complexere systemen gaan ontwikkelen. En dat ook durven! Hoe? Twee trucjes:
    1. Emergent properties – complexe systemen kunnen hier gebruik van maken om eigenschappen als self-healing te krijgen. Voorbeelden zijn ecologische systemen, of mijn favoriete voorbeeld: een mierenhoop. Cisco maakt hier bijvoorbeeld gebruik van voor router software.
    2. Locale eenvoud – als we inzoomen op een systeem moet op een bepaalde plek maximale eenvoud zijn.
    En een beetje een derde: vergeet het maar overzicht of op globaal niveau controle te krijgen. Daarvoor zijn onze systemen te complex, al is het alleen al omdat ze allemaal gekoppeld zijn. Met bovenstaande regels is dat ook niet nodig.

    Geplaatst op 27 september 2008 om 14:51 Permalink

  • Ralf Wolter schreef:

    Domain driven design natuurlijk. ;)

    Geplaatst op 26 september 2008 om 15:39 Permalink