Vandaag in mijn werkkamer weer wat orde in de chaos gebracht. Chaos in een werkkamer betekent volgens mij dat er hard wordt gewerkt en dat de tijd nuttig wordt besteed. Daar is dus niks mis mee. Mijn vrouw bestrijdt dit natuurlijk op alle mogelijke manieren. Sterker nog, ik beweer dat je met rommel taart kunt verdienen.
Brengt een vrouw aan het stuur orde en netheid in programmatuur?
Enige tijd geleden beoordeelde ik de kwaliteit van een twintig jaar oud Cobol-systeem. In alle opzichten zag dit systeem er goed en netjes uit. Toch leek er een klein beetje ‘rommel’ aanwezig te zijn in de vorm van een paar niet meer in gebruik zijnde onderdelen. Ik legde dit voor aan de hoofdontwikkelaar, een vrouw in dit geval. De verontwaardiging was groot: ‘Rommel in mijn systeem, uitgesloten!’. Eigenwijs als ik ben, ben ik natuurlijk de weddenschap aangegaan, om een slagroomtaart. Genietend van de slagroomtaart vroeg ik me toch af of de orde en netheid te maken had met dat er een vrouw aan het roer stond? De orde en netheid zorgden er in ieder geval voor dat het systeem nog jaren meekon.
Zijn de ontwikkelaars 1.0 of 2.0?
Onlangs kwam ik weer een oud Cobol-systeem tegen, dit keer bij een productiebedrijf met twee heren van midden vijftig aan het roer. Op slordigheidjes heb ik ze niet kunnen betrappen. Ze maakten zich echter wel zorgen over het behoud van de kwaliteit door de toenemende inzet van externen. Het gesprek met deze twee heren ging al gauw over de huidige generatie ontwikkelaars. Ze hadden pogingen ondernomen om intern tot gedeelde kwaliteitsnormen en werkwijze te komen. ‘Het werden emotionele bijeenkomsten, waarbij we als zó 1.0 bestempeld werden.’ Je vraagt je toch af welk kamp hier gelijk heeft en waar de goede programmeurs zitten die een factor tien beter zijn dan de slechtste en waar de ontwikkelaars zitten die nog nooit gezien hebben hoe goede software gemaakt moet worden (zie Professional Software Development, Steve McConnell, Addison Wesley, 2003).
Wed om een taart!
Vorige week heeft een jonge .NET ontwikkelaar het door hem ontwikkelde systeem aan mij toegelicht. Hij was al een paar jaar niet meer direct betrokken, maar wist zijn weg nog goed te vinden in de geordende structuur. Al pratende ruimde hij gelijk een paar bestanden op en bekeek de laatste versies van de ontwerpdocumentatie. ‘Jammer dat ze die niet bijgewerkt hebben, misschien geen tijd voor…’ Hij ging zijn collega’s daar toch even over aanspreken. Ik heb hem aangeraden te wedden om een taart.
Dit brengt mij bij de volgende gedachte. Hoe zit het met het opruimen van de rommel in software nu er meer en meer software ontwikkeld wordt, de tijdsdruk steeds meer toeneemt en Agile werken de trend is? Laten we op zoek gaan naar het antwoord en ik stel daarom het volgende experiment voor:
- Zoek de baas van de software ontwikkeling van een systeem. Is deze niet te vinden dan is er zeker taart te verdienen, alleen je weet niet bij wie. Zelf kopen is een optie, je hebt immers een belangrijke quick win gevonden.
- Vraag aan hem of haar of er rommel is in de software. Als het antwoord ja is dan kijk je bezorgd. Ga verder met stap 3 als het antwoord nee is.
- Vraag om een kopie van alle documentatie en broncode en wed om een slagroomtaart dat er rommel te vinden is. Tip: als het lang duurt voordat je de spullen krijgt, komt de taart snel dichterbij!
Wie o wie zal de slagroomtaart winnen?
Als ik daar taarten voor had gehad had ik nu, na bijna 30 jaar betrokken te zijn geweest bij software ontwikkeling, minstens 3 of 4 keer zo zwaar geweest.
Ik heb al menig probleem waar teams uren op aan het studeren waren kunnen oplossen door gewoon de hele broncode groot te laten projecteren (of lang geleden zelfs afdrukken en de muur laten behangen).
Vaak was het zo dat de ‘rommel’ (of moet ik zeggen ‘gerommel’) visueel direct zichtbaar was en snel tot een oplossing leidde.
orde en netheid in de code zorgen voor 1) de minste problemen en 2) snelste inzicht in de code waardoor problemen snel kunnen worden gevonden en opgelost. Goed opgezette software heeft daardoor mijns inziens ook minder losse detaildocumentatie nodig.
Dus ik ben het stellig met je eens. Rommel moet er uit!
Luuk,
Zoek een paar geestverwanten om de taart te delen (goed voor de lijn) en te helpen de juiste baas te zoeken (goed voor de teamspirit) bij de meest rommelige software (goed voor de softwarekwaliteit van de organisatie).
Win + Win + Win
Het verzuimen om rommel op te ruimen is vaak een technologie schuld. Je hoeft er nu even niet voor te betalen, maar later valt de rekening (veel) duurder uit door de rente.
Rommel ontstaat steevast als er veel druk is en weinig governance. Of als diegene die leiding geef aan ontwikkelaars zelf geen clue heeft over schone code, want uiteindelijk elke ontwikkelaar is corrupt. Zonder toezicht zal hij sneller voor nieuwe leuke dingen kiezen en de ongeziene rommel laten voor wat het is.
Overigens vind ik het voorbeeld over een vrouw die rommel had in haar code niet sterk. Waarom hier een man-vrouw ding van maken in dit stuk toch helemaal niet relevant? Brengt juist rommel in je stelling…
Rommel in de software ontstaat vaak ook door korte termijn denken. Systemen hoeven geen 20-30 jaar meer mee te gaan, maar hooguit een jaar of drie. Tegen die tijd zit er toch weer een nieuwe manager die alles over een andere boeg gooit. Dus in plaats van systemen te bouwen die toekomstvast zijn wordt er wegwerpsoftware gebouwd.
Deze is slechter te onderhouden en ontstane rommel wordt vanzelf opgeruimd als er weer eens verhuisd wordt naar een nieuw systeem.
@Jan Wouter: dan moet ik je helaas teleurstellen; er zijn nog wel degelijk systemen die langer dan 3 jaar geacht worden mee te gaan. Denk daarbij vooral aan de grote complexe systemen zoals medische scanners en wafer steppers.
Overigens is het niet altijd korte termijndenken, maar vaak ook een kwestie van prioriteiten stellen. Meestal wordt het belangrijker gevonden dat de ontwikkelaars zich bezig houden met nieuwe features. Dat opruimen kost alleen maar tijd, en voegt niets toe aan het product.
Een tweede oorzaak die al meermalen gezien heb is dat men het niet op durft te ruimen. De code is zo’n spaghetti geworden dat men bang is dat er van alles omvalt als ze de “rommel” er uit halen.
@Wim Goes, het is mij werkelijk een raadsel wat je met dit artikel nu eigenlijk wil mededelen of bereiken.
Zeker heeft Luuk gelijk, netjes werken voorkomt een hoop gelazer, de voorbeelden die PaVaKa terecht aankaart zijn gewoon terug te voeren op zorgvuldig, netjes en doordacht werken.
Ik kan de opmerking van Henri ook niet helemaal plaatsen. de gebruikte technologie de schuld geven en daar ook nog een prijskaartje aan plakken ?
Ongeacht de gekozen technologie kan een beetje technisch onderlegde codeboer zowel het gelijk als het ongelijk hiervan aantonen.
Het gaat er gewoon om dat de aap die de code tikt weet waar hij mee bezig is, en dus dat de opdracht duidelijk is.
Het is helemaal niet zo moeilijk om goede code te kloppen, ook niet als het om een wat ingewikkelder en complex project gaat.
De vraag is of je lui kan vinden die er geen rommeltje van maken.
Die zijn er best, maar je moet ze zoeken en ze geen pinda’s voeren !
Wat is rommel in een systeem? Geef mij eens de totale set aan requirements die precies beschrijven wat het systeem wordt geacht te doen. Grote kans dat er ergens een oud ontwerp wordt opgediept en een grote stapel doorgevoerde RFC’s. Bepaal jij dan maar eens wat “rommel” is.
Ik vind het aandoenlijk hoe buitenstaanders over een bestaand systeem met ettelijke tientallen mensjaren bouw en onderhoud kunnen oordelen.
Rommel vind ik niet de juiste term hiervoor. Rommel associeer ik met slecht geschreven software, die om de haverklap hapert.