Vaak wordt bij software-ontwikkeling gezegd dat er documentatie van het gemaakte programma of het systeem ontbreekt. Vooral technische documentatie is doorgaans afwezig. In dit artikel geef ik aan waarom het technisch ontwerp juist in de prullenbak thuishoort.
De namen functioneel en technisch ontwerp komen oorspronkelijk uit de System Development Methodology (SDM). Deze ontwikkelmethodiek is beter bekend als de watervalmethode. SDM is verouderd en de meeste software-ontwikkeling gaat nu iteratief met als methodiek bijvoorbeeld RUP of Scrum. Hierbij is afstand genomen van het idee dat in één keer een totaal ontwerp gemaakt en uitgewerkt kan worden. Oorspronkelijk bevatte het technisch ontwerp vaak procedurenamen en beschrijvingen, detailschermen, datamodellen en datacomponenten. Dit was tot in detail beschrevenl. Welke documentatie wordt gemaakt is nauw verbonden met de gekozen ontwikkelmethodiek. Voor RUP wordt er bijvoorbeeld gewerkt met een software-architectuur document en analyse en design models. Binnen Scrum bestaat er geen technisch ontwerp of vergelijkbaar document.
Naar de prullenbak
De eerste reden waarom het technisch ontwerp in de prullenbak zou horen te verdwijnen is dat het document niet past binnen de huidige methodieken. Als er gekozen wordt voor Scrum is er eigenlijk geen technisch ontwerp. In de praktijk worden er wel vaak documenten gemaakt met een technische inslag. Dit wil ik geen technisch ontwerp noemen omdat het niet de volledigheid en vorm van het vroegere technisch ontwerp kent. De ontwerpdocumenten worden gebruikt in de discussies en bewijzen vooral hun nut tijdens ontwerpen en ontwikkelen.
De tweede reden waarom het technisch ontwerp in de prullenbak hoort te verdwijnen is, omdat het document moeilijk te onderhouden is. Er staan zoveel details in een technisch ontwerp dat het nagenoeg altijd moet wijzigen als de software wijzigt. Soms wordt het document zelfs vanuit commentaar in de code of vanuit metadata in het databasemodel gegenereerd. Vaak is dit een eenmalige actie en wordt het document later slecht bijgehouden. Nieuwe ontwikkelaars weten niet van het bestaan van het document, of hebben er geen vertrouwen in, met als gevolg dat het niet gebruikt wordt. Er wordt liever in de code gekeken. Het document wordt dus later in het software- ontwikkeltraject niet gebruikt, maar alleen tijdens het ontwerpen zelf.
Technische documentatie niet nuttig?
Technische documentatie is zeker nuttig omdat het een abstractie is van de code. Deze abstractie helpt de ontwikkelaar bij aanpassingen of bij de analyse van problemen. De veelgemaakte fout is echter dat er teveel naar de details wordt gekeken. De systeemstructuur of kernprincipes worden dan vaak vergeten. Maar documentatie op architectuurniveau is juist wel belangrijk om te hebben. Software-architectuur gaat over de essentie van de gemaakte software en verandert ook niet zo snel. Een architectuuraanpassing kost veel meer moeite en zal niet snel doorgevoerd worden. Het beschrijven van de architectuur helpt ontwikkelaars enorm bij het begrijpen en uitbreiden van de gemaakte software.
Buiten de architectuur is er tijdens het ontwerpen ook behoefte aan meer technisch detail. Het maken van klasse en sequence diagrammen is niet ongebruikelijk en ook zeer nuttig in de ontwerpfase. Ook hier helpt de abstractie in de discussies. Het bewaren van dergelijke modellen is niet zo nuttig. De diagrammen worden immers niet bijgehouden en verder zijn er vaak alleen maar delen tot in dat detail beschreven. De diagrammen worden namelijk voor een bepaald project gemaakt. Zeker als de diagrammen ouder worden, verliezen ze hun waarde.
Als eenmaal keuze is gemaakt om de diagrammen niet te onderhouden, dan worden ook de kwaliteitseisen met betrekking tot het model anders. Het maakt niet meer uit dat ze niet met een duur tool zijn gemaakt, maar gewoon met potlood en papier. Ook een whiteboard diagram voldoet prima. Een foto hiervan kan eenvoudig later nog worden gebruikt. Tijdens het ontwerpen helpen de diagrammen je op een andere manier na te denken over de te maken oplossing. Tijdens ontwikkeling helpen ze vervolgens met het uitzetten van de richting en grote lijnen, maar daarna kunnen de diagrammen gewoon naar de prullenbak.
Hear. Hear. En er is nog veel meer wat direct de prullenbak in kan omdat het alleen maar misverstanden in de hand werkt en vertragingen veroorzaakt.
De harde realiteit van vandaag is dat er zoveel met de hand moet worden aangepast omdat de ontwikkeltools nog niet voldoende zijn geëvolueerd dan wel geïntegreerd. Alles wat dubbel moet worden onderhouden en daarmee dwangmatig uit elkaar gaat lopen (zoals bijvoorbeeld het technisch ontwerp) moet worden geschrapt.
Als software architect is het mij vandaag de dag onbegrijpelijk dat we nog geen steek verder zijn als toen ik begon in de IT in 1989. De systemen zijn complexer geworden,maar de toegenomen complexiteit wordt niet opgevangen door betere tooling maar door meer mankracht en meer (onbetaalde) overuren.
De moeite die het kost om een UML model synchroon te houden met het daadwerkelijke systeem, heeft mij ervan overtuigd dat deze inspanning, net als het technisch ontwerp, eruit gegooid kan worden. Het leidt alleen maar tot verwarring.
Een whiteboard, een fotocamera, één document waarin je alle beslissingen en ideeën opschrijft (ook die later worden verworpen), een leuke programmeertaal, een goede debugger en een Agile ontwikkelmethode is alles wat je nodig hebt om supersystemen te schrijven. Er zijn heel wat start-ups die ons dat voordoen.
Bijna vergeten: natuurlijk gemotiveerde en getalenteerde medewerkers (maar dat zijn we allemaal ;-)).
Voor een bepaalde vorm van software ontwikkeling zal bovenstaande ongetwijfeld waar zijn, maar (in mijn ogen) wordt er een grote denkfout gemaakt:
Als IT-er lever je geen project, maar een product.
Je werk als architect houd ergens halverwege het project al op waarschijnlijk, want dan hoeft er alleen nog maar afgetest te worden.
Maar hoe zit het met het onderhoud van hetgeen je maakt?
Mensen die apparaten kopen als wafer steppers, telefooncentrales (nee, niet die tcp/ip dingen, maar de echte grote telecomswitches zoals de AXE van Ericsson), mri of röntgenscanners gaan uit van een levensduur van 10 of meer jaren. In het geval van medische appartuur gelden er zelfs wettelijke regels over hoe lang je dingen moet onderhouden.
Probeer jij nu eens na 5 jaar een probleem op te lossen, waarvan het technisch ontwerp bestaat uit een foto van de achterkant van een bierviltje, waarop een architect in onleesbaar handschrift wat getekend en geschreven heeft……
Momenteel ben ik bezig met een stuk kennisoverdacht naar collega’s in India, die ons gaan helpen bij het onderhouden van onze producten. Zelfs met 7 jaar product- en domeinervaring kom ik nu nog dingen tegen waarvan ik me afvraag: wie heeft dit bedacht en waarom.
Er is weliswaar een technisch ontwerp, en inderdaad, zoals de auteur aanhaalt, is deze achterhaald.
Maar meneer de consultant, 2 vragen:
– waarom wordt het technisch ontwerp niet bijgehouden
– waarom wordt het product niet gebouwd volgens dit ontwerp
Met name de laatste vraag is iets waar ik al eens tegenaan ben gelopen: er wordt een prachtig technisch ontwerp en architectuur neergezet, waar iedereen het mee eens is. Echter, tijdens implementatie blijkt dat niet alles werkt zoals gedacht. Omdat de deadlines al gesteld zijn, en de commitments naar de klant al gemaakt, worden er wat bochten afgesneden om op tijd een werkend product op te leveren.
Uiteraard is er naderhand geen tijd meer om de implementatie alsnog volgens de architectuur te implementeren, en de architect die alles bedacht had zit op een ander project, dus die heeft ook geen tijd meer.
Effect: je loopt nog jaaaaaaaaaren te *(&#_(*&@#)&(@# met een product dat eigenlijk net niet helemaal lekker werkt omdat van de architectuur is afgeweken.
In het ergste geval kan dit zelfs betekenen dat bepaalde klant-variaties op het standaardproduct gewoon niet mogelijk zijn, omdat men zoveel jaar geleden af is geweken van de architectuur.
Bovenstaande is een geval van korte termijn denken, en niet kijken naar de onderhoudbaarheid van een product op lange termijn. Zoals in het begin al gezegd: voor bepaalde producten zal dit ongetwijfeld goed werken, maar het is veel te kort door de bocht dit als algemene stelling neer te zetten.
Arnold’s Laws of Documentation:
1. If it should exist it doesn’t.
2. If it does exist it’s out of date.
3. Only useless documentation transcends the first two laws.
Ik kan mij ook niet echt vinden in de bevindingen van Ben.
Voornamelijk om redenen die PaVaKa aangeeft.
Ik heb dagelijks last van het het argument ‘kijk dan even in de code’ waarna ik veel tijd moet steken in cryptisch geschreven gedrochten zonder enige vorm van foutcontrolle. Meestal is nieuw schrijven een betere oplossing dan bugfixen.
Duidelijke specs is een minimum waar je je als ontwikkelaar zult moeten houden wil je een onderhoudbaar product neer zetten.
Goede documentatie is voor het onderhoud van belang.
Niet voor een lullig databaseje van het lokale uitzendburo dat met de volgende versie van Windows toch vervangen wordt, maar wel voor serieuze projecten van systemen die wat langer (en nog heel, heeeel veel langer dan PaVaKa aangeeft) moeten draaien.
Met goede documentatie bedoel ik dan ook niet doxygen troep (technisch slim maar in de praktijk nooit actueel of gewoon ontbrekend en dus waardeloos) maar een fatsoenlijk document waarin specs, technische overwegingen en kritische notes te vinden zijn.
Maar ja als MicroSoft Consultant heb je kenlijk maar zelden te maken met lange termijn projecten.
PaVaKe, jouw praktijkervaringen spreken er toch voor om het TO eruit te gooien!
De levensduur van het “product” heeft niets te maken met het wel of niet bestaan van een technisch ontwerp. Ik heb wel veel collega’s horen vloeken over documentatie die niet op orde was maar ik heb nog nooit meegemaakt dat we een systeem hebben weggegooid omdat er geen technisch ontwerp was.
Weliswaar is het moeilijk problemen op te lossen waarvan het technisch ontwerp uit een foto van de achterkant van een bierviltje bestaat, maar waarschijnlijk niet moeilijker dan de problemen die jij beschrijft waar jij nu tegenaan loopt. Ik weet in ieder geval wel dat de foto van de achterkant van het bierviltje een stuk goedkoper was. Het TO waar jij je nu dus mee bezig moet houden is verspilde moeite geweest. De foto had het ook gedaan.
Het bierviltje klinkt leuk maar we spraken natuurlijk over foto’s van het whiteboard en deze zijn zeer behulpzaam bij het begrijpen van een systeem en de evolutie van het systeem.
Een TO wordt niet bijgehouden omdat er sprake is van een mediabreuk. De huidige ontwikkeling stand van de ter beschikking staande tooling is te primitief om daadwerkelijk te kunnen gebruiken in grote projecten.
Door het gebrek aan goed gereedschappen gaan mensen oplossingen zoeken. Bij een hele grote Duitse autofabrikant heb ik ooit eens een verzameling business processen mogen aanschouwen. Geschreven in…. powerpoint. Mag jij raden of de implementatie overeen kwam met de powerpoint documentatie.
Je kunt geen systeem bouwen volgens een statische TO. Er kunnen heel veel redenen zijn om de architectuur aan te passen. En als je de architectuur aanpast, dan vloeit dit nooit terug in het TO omdat dit handmatig moet gebeuren.
De ontwikkelomgevingen moeten beter worden en vloeiend in elkaar overgaan. Jetbrains heeft hier een uiterst interessante aanzet gegeven met MPS. Maar het is nog niet voldoende.
Microsoft heeft het met OSLO geprobeerd maar heeft het opgegeven waarbij ik het concept van Jetbrains wezenlijk beter vind.
Zolang de tooling niet beter wordt val ik terug op foto’s en één document. Ik kan al dat dubbele werk niet meer verdragen.
prettige avond nog!
Allereerst: Een geweldige titel. Lekker prikkelend en ik snap de genoemde punten en wil hierop wat aanvullen.
Als je het over prullenbak hebt ben je nog niet in het digitale tijdperk aangeland 🙂
Als je een document in de prullenbak moet gooien omdat het onderhouden zo moeilijk is, dan gaat er iets mis met de volwassenheid van je organisatie. Grappig is de correlatie tussen de kwaliteit van je product en onkunde om een document actueel te houden. Ook in de kwaliteit van de software zal veel te wensen overblijven.
Orion6 is blijven steken in 1989. Het klopt dat coderen nog steeds iets is wat op typen lijkt. Dat betekend niet dat de code an sich is blijven steken. In tegendeel.
Door frameworks zoals .NET is het mogelijk om vrij complexe zaken met een enkele regel code te schrijven. Met Linq is het mogelijk om Set-based code op te roepen in een loop-based omgeving en dan heb ik het nog niet over de mogenlijkheden om parallel en multi-threaded code uit te voeren en een begrijpbare manier.
Neem nu eens als voorbeeld WeTransfer.com . Een klein clubje personen kan een tool maken die door miljoenen mensen gebruikt word. Als dat geen hefboom is?
Overigens kan een technisch ontwerp prima wat visie en filosofie bevatten.
Dus hoewel het artikel leuk leesvoer is en de reacties vermakelijk, vind ik de uitspraak, argumenten en conclusie te kort door de bocht. Zet dan het technisch ontwerp op een interne social media site en kunnen gebruikers en stakeholders foto’s en gedachten toevoegen. Ontstaat er een mooi stukje terugvindbare geschiedenis…
Orion6 heeft1989 al lang achter zich gelaten en houdt zich serieus bezig met hoe de tekortkomingen in complexe systemen en grote projecten opgevangen kunnen worden. Het kan niet aangaan dat meer dan 15% van de IT projecten uiteindelijk niet wordt opgeleverd [Intermediair].
Het TO moet in de prullenbak omdat de toegevoegde waarde gering is. De kosten om een TO te schrijven en te onderhouden staan niet in verhouding tot het latere nut. Dat het onderhoud moeilijk is, heeft te maken met de slechte tooling. Niet met een onvolwassen organisatie.
Ik ken niemand, maar dan ook echt niemand met wie ik ooit heb gesproken die zei: Ik moet software onderhouden en ik heb een super TO, ik hoef niets na te zoeken, alles staat er in en komt volledig overeen met het systeem. Niemand.
Aan de andere kant ken ik heel veel mensen die klagen dat het TO waar ze mee moeten werken niet volledig is en eigenlijk niets brengt.
Of alle organisaties zijn onvolwassen of er schort iets aan de manier waarop een TO wordt geschreven en bijgewerkt.
Dus moet je naar alternatieven kijken en dat is, zoals eerder aangehaald, foto’s van een whiteboard en een enkel document met de beslissingshistorie.
De hele ontwikkeling van .NET met LINQ volg ik met argusogen. Dat een ontwikkelaar zich steeds compacter uit kan drukken is niet per sé een voordeel. Het verhoogt de leesbaarheid van software niet. Dan heb je weer een TO nodig om de software te begrijpen 😉
Bij een club als WeTransfer.com is de hefboom het internet en niet een framework. Dat miljoenen mensen er gebruik van kunnen maken ligt aan de beschikbaarheid van de dienst.
Nog een prettige dag.
Het ontwerpen van een computertoepassing kent enkele valkuilen. De eerste lijkt triviaal: een computertoepassing staat niet op zichzelf maar is een hulpmiddel bij het proces van een klant. Natuurlijk begrijpen wij na 10 of hooguit 20 minuten perfect wat de klant doet. Dat is valkuil twee. Je zult meestal met moeite begrijpen wat het klantproces is, tenzij je dat vereenvoudigt tot een tweede, derde, of nog lagere orde proces. Tenslotte zul je met heel goed waarnemen het standaard klantproces wel in beeld kunnen krijgen. Maar dan komt valkuil drie: de uitzonderingen, waar meestal 50-80% van de tijd in gaat zitten die medewerkers van de klant besteden. En last but not least kan er, gedreven door interne èn externe factoren, van alles en nog wat veranderen aan het klantproces.
Een ontwerp dat voldoet aan de verwachtingen van de klant, wijkt dus meestal “iets” af het werkelijke proces en is meestal “iets” minder toekomstvast dan de werkelijke wijzigingen waarmee rekening gehouden had moeten worden.
Ik zou dus in ieder geval willen pleiten voor een goede en houdbare architectuur, waarbij de ondersteuning van klantproces voor de komende vijf tot tien jaar gegarandeerd is. Uiteraard is dit een zaak van de klant. Maar het kan geen kwaad om hem daar bij een beetje te helpen. Al was het alleen maar om de tijd- en kostenoverschrijding te beperken. Maar ook het welbegrepen eigen belang vaart er wel bij. Stel je voor: Ook in 2012 geen tijd- en budgetoverschrijdingen bij automatiseringsprojecten.
En voor verder lezen: https://www.computable.nl/artikel/opinie/overheid/2998823/1277202/architecten-terug-naar-de-blokkendoos.html
Inderdaad leuk geschreven artikel.
Veel reacties terwijl men het eigenlijk best met elkaar eens is:
SDM en waterval bleek voor merendeel van IT systeemontwikkel projecten niet optimaal en veel tijd steken in documentatie die niet wordt bijhouden of te gedetailleerd is, is niet efficient.
Maar enige vorm van abstractie van code, de architectuur beschrijving, is weer wel altijd handig.
Maar goed, dan krijg je hoogstens alleen maar een aantal keer : “vind ik leuk”.
Bij een discussie als hierboven kom ik meestal uit bij de conclusie dat je voor alles je gezond verstand moet gebruiken om in de geldende situatie te bepalen wat en hoe gewenst is. De klassieke tot in detail uitgewerkte TO’s zijn passe. Maar een aantal essentiële, ook technische, zaken zullen vaak wel voldoende uitgewerkt moeten zijn voordat je loos gaat in je ontwikkelomgeving.
Ga je voor een overzichtelijk project met een bekend team scrummen dan kunnen globale architectuur en afspraken voldoende zijn. Gaat het om een groot project met meer partijen, of besteed je het maken uit en moet je de specs naar India mailen, dan zal is er meer technische uitwerking nodig. ‘Just enough’ lijkt me daarom een betere doelstelling dan ‘de prullenmand’.