Goede en betrouwbare software schaf je niet zomaar aan. Het vraagt om sterk opdrachtgeverschap. Anders bestaat de kans dat je door dienstverleners onder de tafel wordt ´gekletst´.
Spaghettisoftware staat nogal in de belangstelling. Het is dure software die uiteindelijk niet doet waar het voor is bedoeld, en waardoor klant en de dienstverlener over straat rollen en elkaar verwijten maken. Dat kan anders, bijvoorbeeld door een quality level agreement (qla) op te stellen, waardoor je tussentijds kunt monitoren en bijsturen.
Je hebt grofweg twee soorten software: pakketten en maatwerk. Bij implementatie van financiële of crm-pakketten ga je niet zelf programmeren (dat is althans de bedoeling). Je kunt de functionele eisen van het systeem benoemen en vervolgens met je leverancier bekijken of het voldoet en waar aanpassingen nodig zijn. Bijvoorbeeld: je hebt in je financiële pakket een scherm nodig voor de balans, maar dat scherm is er niet. Dan kun je dat laten aanpassen. Over het algemeen is pakketsoftware betrouwbaar, omdat het vaak eerst getest wordt door de leverancier en in gebruikersgroepen. Onvolkomenheden en wensen worden dan in volgende versies meegenomen.
Bij maatwerksoftware ligt dat ingewikkelder. Daar moet je ook eisen stellen aan de software zelf. Hoe goed zijn code, complexiteit en architectuur bijvoorbeeld? Dit zijn feitelijkheden en die kun je beoordelen. Maar in veel gevallen heeft de klant die kennis niet in huis en moet hij zich wenden tot een externe deskundige. Om problemen vóór te zijn, moet die specialist altijd onafhankelijk zijn.
Met zo’n professional kun je ook vooraf een qla opstellen als bijlage bij het contract. In zo’n document regel je, bijvoorbeeld, aan welke eisen de code moet voldoen, hoe er gerapporteerd wordt en op welke momenten je kunt toetsen. Op die manier blijf je als opdrachtgever uit het moeras van spaghettisoftware.
Ik raad iedereen een qla aan, want voorkomen is beter dan genezen. Te vaak hoor ik in de praktijk: ‘Ik geloof wel dat het goed komt.’ Of: ‘Die verantwoordelijkheid ligt bij de leverancier.’ Dat is te vrijblijvend, ook al staan er sancties en boeteclausules in contracten. Want geloof me: Zowel klanten als leveranciers van de it-afdeling krijgen buikpijn als software niet, gedeeltelijk of te laat wordt opgeleverd.
Waar download ik een QLA Template?
Jaren geleden schreef ik over de twee smaken van software automatisering; maatwerk / standaard.
Toch zie je dat er nog een 3e smaak is die er eigenlijk tussenin valt. De platform software. Daar bestaat al veel en is veel geregeld, maar kun je het zelf inrichten en stukjes maatwerk code op laten landen.
Heel krachtig, maar ook met risico’s.
Je mag inderdaad verwachten dat het met pakketten beter zou moeten , maar dat is geen enkele garantie. Sommige leveranciers luisteren wel heel slecht, slepen fouten jaren mee tot groot jolijt van hun business partners die steeds opnieuw de reddende engel mogen spelen, en maar al te vaak dan maar excel inschakelen, daar werkt toch iedereen graag mee. Als het na 3 jaar nog niet behoorlijk gaat krijg je te horen : dat is normaal, dat moet iedereen meemaken.
tsunami van moslims zei schreeuwitje met gevoel voor beeldvorming. qla-eend denkt er net zo over. NIemand wil immers wegzakken in het moeras van spaghettisoftware. Daarvoor hebben we hulp nodig door een onafhankelijk leverancier. Das een leverancier die zogenaamd alleen zijn eigen zakken vult. Zoiets als Platini en zijn fifa baas zegmaar. Zou het net als sla’s om inspanningsverplichting gaan ? Dat de programmeur zich ff moet inspannen ? Daarna zegtie, ik heb flink gewerkt aan code, complexiteit en architectuur. Als je al kunt aantonen dat het niet geholpen heb dan heeftie toch zijn best gedaan ..
90 dagen schorsing dan maar ?
Felix: u r an idiot
Kleine toelichting: Je maakt het wel heel bont. Jij bent zeker ook een zakkenvuller?
die Henri,
Zal best zijn dat je jaren geleden al eens over verschillende smaken hebt geschreven, maar je 3 laatste reacties op artikelen zijn :
1) @Business Rules: Fair enough. Als je afzeikt moet je kunnen onderbouwen.
2) Felix: u r an idiot
3) Kleine toelichting: Je maakt het wel heel bont. Jij bent zeker ook een zakkenvuller?
Wou je nog iets melden over meetbare kwaliteit van code, complexiteit en architectuur of is je laatste inspanning genoeg geweest ? Bij mij moet jouw maatwerk nog even landen.
Zolang QLA geen papieren tijger is of blijkt te zijn lijkt het me in essentie een goed plan. Maar hoe kan je controleren of de QLA ook wordt nagekomen? Als je er zelf geen verstand van hebt zul je toch weer bij een derde partij uitkomen die ook weer een eigen agenda heeft.
Code review kun je ook automatiseren (tot op een zekere hoogte) en met die cijfers kun je concreet wel iets zeggen over de kwaliteit van de software.
@Felix
Moeilijke week gehad of zo?
Felix: Nummer 2 was gewoon even een eerste reflex. Niet mijn stijl, want op de man, maar reacties kan ik niet verwijderen en ik vind het nog steeds geen stijl.
Want de schrijver associëren met corruptie en graaien vind ik erg zwak en voegt ook weinig toe want niet spitsvondig en niet grappig.
En zoals je zelf aanhaalt. Als ik ergens tegen ben of zwak vind, dan licht ik dat ook toe. Overigens onder mijn eigen naam.
On Topic: Ik review ook code. Niet op directe functionaliteit, maar om te controleren of de ontwerp principes gehanteerd worden en of de code netjes volgens een (naam) conventie geschreven is. Dit voegt direct wat toe aangezien je hiermee een stukje technology schuld voorkomt en overdraagbaarheid vergroot.
Het idee van QLA vind ik dus zeker niet slecht en is iets wat je zelden ziet.
Ben benieuwd naar jouw inhoudelijke bijdrage Mauwerd 😉
Goed punt Johan, maar het voordeel van een contract is dat je ook achteraf kunt vaststellen dat dingen niet goed zijn gegaan. Overigens zou je de controle van het houden aan de QLA weer uit moeten besteden als je zelf de kennis niet hebt. Ja dit is een extra kostenpost, maar qua tijd kost (basis) reviewen veel minder tijd dan het schrijven en testen van code.
Hoe ga je de kwaliteit van code beoordelen ?
We hebben ongetwijfeld allemaal heel wat echte bagger gezien,
Maar waneer is het dan wel goed ? Alle kriteria zijn tegenwoordig toch al beperkt tot Java en C# (zelfs php valt daar dus nog buiten).
Overigens een opmerking nog richting Wilbert.
De manier waarop je tekst is opgesteld doet vermoeden dat je het over een definitie van ‘spagetti software’ hebt.
De algemeen gebezigde term is echter ‘spagetti code’ en wat je beschrijft is een van de gevolgen ervan.