Het moet een hele tijd geleden zijn geweest dat ik de term ‘wegwerpsoftware’ voor het eerst gehoord heb. Hoewel je de term op meerdere manieren kunt interpreteren, wil ik er in dit stuk een positieve connotatie aan geven.
Is het logisch om software te maken met het idee om deze binnen afzienbare tijd weer weg te gooien? Intuitief zal een ieder antwoorden dat het zonde is om iets te maken dat je gaat weggooien. Het is demotiverend, niet waard er veel moeite in te steken. Anderzijds zal de cynicus opmerken dat in it de betekenis van ‘tijdelijk’ heel rekbaar is, en dat er in een willekeurig groot bedrijf nog allerlei kernsystemen draaien die ooit als tijdelijk bestempeld waren.
Voor de eeuwigheid?
We kunnen de vraag overigens ook omdraaien: is het logisch om software voor de eeuwigheid te maken? De kunstenaar die diep van binnen in de programmeur zit, zal dit in zekere zin wel graag zo zien. Je broedt dagenlang, wekenlang op een stuk software; je schaaft het bij en boetseert het in een mooie vorm; hier en daar nog een fliebeltje ombuigen en een puntje erbij plakken, en dan… dan heb je een prachtig stuk van jezelf op aarde gezet. En je denkt trots: dit mag gezien worden. Sterker nog: als ik er nog een klein beetje meer aan schaaf, dan is het voor anderen ook bruikbaar. Het is emotioneel gezien moeilijk om het dan nog de nek om te draaien, “killing your darling” is tough.
Maar de waarheid is dat het erg moeilijk is om een zelf geschreven stuk software herbruikbaar voor anderen te maken, en dat geldt zowel op technisch als organisatorisch (beheer, documentatie, et cetera) gebied. Nadat je hebt opgeleverd dendert de tijd door en stapelen de technologische nieuwigheden zich op. Jouw zelfgemaakte stuk software blijkt binnen de kortste keren verouderd. Niemand wil het meer gebruiken, laat staan aanpassen of beheren. Er zijn intussen nieuwe frameworks of nieuwe (versies van) programmeertalen die hetzelfde issue veel beter oplossen, of waarin je het probleem veel eleganter kunt oplossen.
Zo nu en dan vervangen
De truc is om niet bang te zijn om software weg te gooien. Als je je houdt aan de principes van “Egoless programming” dan scheidt je de code van de ego’s en wordt het makkelijker om software zo nu en dan te vervangen.
Het goede nieuws is dat ook op architectureel vlak de wereld veranderd is, wat er voor zorgt dat we minder moeilijk hoeven doen over de creatie van wegwerpsoftware. Zo is een architectuur gebaseerd op microservices, opgedeeld in kleine stukken waarin onafhankelijke DevOps-teams zoveel als mogelijk parallel kunnen werken aan fijnmazige services, prima geschikt om af en toe hele stukken opnieuw in te maken. Het is hierin wel belangrijk dat je het weggooien van software absoluut niet ziet als een nederlaag, zoals ook Martin Fowler in zijn stuk over Sacrificial Architecture accentueert.
Goede architecten en programmeurs zullen altijd hun best doen om goede software te maken, en soms kan dat er extreem mooi uitzien. Maar net als bij de prachtige zandmandalas van de Tibetaanse monniken, is er na een lang en minutieus proces tijd voor een afscheidsceremonie. Dat hoeft niet iets droefigs te zijn. De term softwaremandala gaat misschien wat ver, maar het idee van wegwerpsoftware… dat is zo gek nog niet.
Wegwerp-software hebben we toch al?
Windows 1, 2, 3(.1), 95, 98(se), XP, Vista, 7, 8(.1) en nu 10.
Zo ook met Office…
Begrijp het niet helemaal…
@Jasper
Ik denk dat de schrijver het in jouw vergelijking heeft over de code in de verschillende vormen van een Windows release. Dus waar je een aparte variant hebt voor de desktop, mobiel en embedded systemen zoals IoT en de HoloLens, is een groot deel van die varianten gebaseerd op dezelfde code.
SacrificialArchitecture gaat dan meer over het dubbel of tijdelijk implementeren van sommige code en het later gewoon opnieuw maken voor een ander paltform of als achteraf blijkt dat het beter moet schalen.
De vraag die ik mis in het verhaal is wat het vervangen kost.
Ik ken een paar bedrijven die best een keer hun software (of gedeelten ervan) zouden willen wegwerpen en vervangen. Echter, het herontwikkelen (+testen etc) van een codebase van 10 MLoc of groter is ook een zeer kostbare aangelegenheid.
Wil je grote en complexe softwareproducten wegwerpbaar maken (of gedeelten ervan) zul je daar vanaf het begin al rekening mee moeten houden in de architectuur. (microservices klinkt leuk, maar is niet overal even goed toepasbaar)
Friso
Misschien moet je toch eens een ander boek lezen, koning SOA valt nogal van zijn troon in ‘SOA in practice’ want samengevat is het service denken daarin toch vooral een business functionaliteit in een container proppen. DevOps is meer een governance dan een ontwikkel paradigma waarin je net als bij een kanban-systeem uiteindelijk maar een beperkt aantal productvarianten en/of veranderingen kunt ondersteunen. Het Ops gedeelte gaat namelijk om release management, het SOA lifecycle probleem waardoor parallel werken in een pijplijn lastig en vaak onmogelijk wordt.
En ‘egoless’ programmeren gaat dus in eerste plaats om een attitude, het afscheid nemen van het Agile Manifesto is namelijk met DevOps begonnen. En het is dus niet dat ik een aversie heb tegen SOA als principe maar de wijze waarop het als technologisch wonder verkocht wordt. En idee van een spaghetti architectuur met microservices lijkt me dus geen oplossing, teveel complexiteit en te weinig flexibiliteit zoals de meeste organisaties nu merken.
Afscheid nemen van software die vertroeteld wordt door de business is trouwens een lachertje als ik kijk naar oplossingen welke al meer dan 20 jaar ongewijzigd – misschien nu in de container van virtualisatie gepropt zijn – draait binnen de architectuur. Jasper vergeet even dat de professionele versies van Windows meer dan 15 jaar op de NT kernel draaiden en een onopgeloste bug hadden waarvan nog opmerkelijk veel applicaties afhankelijk zijn. In theorie is dus het patch management prima op orde maar in de praktijk worden deze niet aangebracht omdat ze simpelweg niet getest kunnen worden.
@Wie roept mij,
Voor de goede orde: het is niet koning SOA maar koning Proces die hier van z’n troon blijft vallen.
Want ook microservices zijn – net als voorheen de Services in SOA – weer staaltjes van procesdenken en niet servicedenken zoals jij abusievelijk blijft volhouden. Dat microservices ook weer processen zijn is al op te maken uit de eerste zin op deze wiki-pagina: https://en.wikipedia.org/wiki/Microservices
Wat je vervolgens wel weer heel raak omschrijft als “business functionaliteit in een container proppen” met alle funeste gevolgen voor complexiteit en flexibiliteit van dien.
Toch lijk je inmiddels wat milder te worden ten aanzien van het idee van SOA; waar je voorheen nog sprak over SOA-klutsers stel je nu dat je geen aversie hebt tegen SOA als principe.
Is hier enig verband met het fascinerende pseudoniem dat je hebt gekozen binnen dit forum?
Want de vraag Wie roept mij? is vooral bekend binnen religieuze en spirituele bespiegelingen en dat kan ik niet zomaar bij jou plaatsen.
Op luchtige wijze brengt de auteur in zijn boeiende betoog de eeuwigheid ter sprake maar als ik zijn linkje naar de zandmandala’s volg vraag ik mij toch af of die Tibetaanse monniken niet wat beters te doen hadden 🙂
Jack,
Koning proces valt niet van zijn troon, processen zijn uiteindelijk bedoeld om tot de voorspelbare uitkomsten te komen. Als we het over spirituele bespiegelingen gaan hebben dan moet je kijken naar het lachspiegelpaleis van SOA, digitale residu van processen zorgt hier steeds steeds vaker voor lachwekkende situaties.
…Inmiddels heb ik reeds heel wat software weggegooid.
Met name wat rommel van MS. – ruimt lekker op – zoals ik eerder ’tikte’ – wegwerpsoftware.
Wij verdienen per week teveel om ons daar druk over te maken, hebben het niet nodig in onze bedrijfsvoering, alternatieven genoeg.
’t Fijne is, ik beslis uiteindelijk.
Oeps, was een 😉 vergeten, …voordat iemand kwaad wordt.
@Wie roept mij
Als je stelt dat SOA niet werkt vanwege de losse schakels binnen de ketens ben ik dat met je eens, want dat is precies de procesoriëntatie binnen SOA – voorheen met BPM, en nu weer met (event-driven) microservices – waardoor SOA haar belofte van complexiteitsreductie en flexibiliteitsverhoging nog steeds niet heeft waargemaakt.
Bij processen gaat het om de vraag of je de juiste dingen maakt (volgens regelgeving, wetgeving, etc.); denk ook aan governance en compliance. Bij services gaat het om de vraag of je de goede dingen maakt (conform de normen en waarden) en dan zijn we op het terrein van de ethiek.
In de hoofdstraat van een dorp kun je je aan de maximum snelheid van 50 km/u houden, maar je kunt ook rekening houden met de gevaarlijke verkeerssituatie en dus veel langzamer gaan rijden.
SOA werkt zolang je alle knikkers ervan in de juiste zak houdt en een event-driven architectuur is daarin dezelfde wijn in oude zakken als we kijken naar de supermarkt. In plaats dat de mens een subproces initieert is het de machine die dit doet op basis van tresholds. En dat werkt prima als je niet het verlies van ‘proletarisch winkelen’ vergeet omdat dit een proces is dat buiten de ‘check & balance’ van het systeem valt.
Mogelijk kijk ik er een beetje vreemd tegenaan maar SOA is toch een beetje als een supermarkt en kan vaak slecht overweg met out-of-band processen, dat we nu moeten betalen voor een plastic tasje terwijl het werkelijke probleem in overtollig verpakkingsmateriaal zegt wel iets over het paard achter de wagen spannen in het reduceren van de complexiteit en verhogen van de flexibiliteit.
Een blik met 5 hotdogs en een zak met 6 broodjes is alleen handig als je 30 klanten hebt.