Software-ontwikkeling behoort tot de informatica. Een beta vakgebied. Toch is het uitoefenen van software-ontwikkeling in de hedendaagse praktijk nog steeds een ambacht. Het vraagt om vakmanschap en inzichten die samenhangen met ervaring en gevoel.
In mijn praktijk tref ik veel verschillende soorten klanten. Uiteenlopend van grote bedrijven met een interne software-ontwikkelafdeling tot bedrijven die software ontwikkelen om het vervolgens te verkopen. Het bestaansrecht van deze partijen is dat ze goede software kunnen ontwikkelen. Maar: wat maakt software goed?
Een stelling die ik vaak gebruik luidt 'goede software kan omgaan met veranderingen'. De achterliggende gedachte is eenvoudig. Vanuit een gebruiker is het veelal moeilijk van tevoren voor te stellen hoe software eruit moet zien of hoe het zich moet gedragen. Wanneer weet de gebruiker dat het beste? Op het moment dat hij de software daadwerkelijk gebruikt en deze in productie draait. Juist dan komen de meest essentiële eisen en wensen naar boven en ziet de gebruiker écht welke dingen handiger, slimmer, beter of sneller kunnen. Wensen die de gebruiker vervolgens graag verwerkt ziet in de software die op dat moment aangepast en vaak ook uitgebreid moeten worden.
In zijn werk 'Enterprise Patterns' staat Martin Fowler uitgebreid stil bij verschillende stijlen van softwaredesign. Bij het maken van software die goed met veranderingen om kan gaan, is in mijn optiek de domeingedreven stijl de meest interessante. In deze stijl wordt gezocht naar manieren om de essentie van de business centraal te stellen en de techniek er omheen te plaatsen. Het werk van Martin Fowler aanvullend met de 'Hexagonal Architecture' van Allistar Cockburn en andere OO-designprincipes geeft ons een software-ontwerpstijl die ontwikkeling van een business-specifiek domein en technische services faciliteert. Deze ontkoppeling maakt het mogelijk om software te veranderen.
Nu kan ik hier natuurlijk heel uitgebreid ingaan op de eigenschappen die software veranderbaar maken, maar waar het mij om gaat is dat software-ontwikkeling meer is dan coderen alleen. Om software succesvol te maken moet er tijdens de bouw ervan een balans zijn tussen de drie dimensies project, proces en design.
Vanuit de projectdimensie gezien, gaat software-ontwikkeling met name over de tijd, het geld en de middelen die nodig zijn. Het schept de randvoorwaarden waarbinnen de ontwikkeling plaatsvindt. In veel trajecten staan de hoeveelheden waarin deze beschikbaar zijn vast of wordt aan ons gevraagd deze vooraf vast te zetten.
De procesdimensie gaat met name over de wijze waarop we de software ontwikkelen. Iteratieve werkwijzen genieten daarbij op dit moment de voorkeur. Het gaat hier ook over de wijze waarop ontwikkelaars, domeindeskundigen, gebruikers en testers met elkaar samenwerken. De manier waarop we onze modellen en requirements visueel kunnen maken, zodat we een gezamenlijk afgestemd beeld krijgen.
De designdimensie wordt vaak de software-architectuur genoemd. Hoe is de software ontworpen? Welke onderdelen hangen op welke manier met elkaar samen? Waar kan ontkoppeling plaatsvinden?
Ik kan me voorstellen dat jij als lezer denkt 'leuk Edwin, maar dit is niet allesomvattend'. Nee, daar heb je gelijk in. Dat is ook het punt. Hier komt de aap uit de mouw: die allesomvattende aanpak die we generiek voor alle vormen van software-ontwikkeling kunnen gebruiken, bestaat niet!
Gedurende de afgelopen decennia hebben we meerdere methoden en technieken zien komen en gaan die ons 'de oplossing' moesten bieden. Wat we hieruit geleerd hebben, is dat de silver bullet niet bestaat. Daarmee valt software-ontwikkeling weer terug op de mensen die het doen. Het gaat om hun ervaringen, kennis en inzichten. Het is een ambacht. Dat vraagt om een gilde.
“dat vraagt om een gilde…”
Helemaal mee eens Edwin!
Een organisatie / vereniging van MEESTERS, EXPERTS die IN DE PRAKTIJK het vak aan elkaar overdragen, gelijk het “meester en gezel principe” uit de vorige eeuw in de handen-arbeids / bouwnijverheids sector.
Niet te veel academisch, theoretisch en filosofisch geleuter in een klaslokaaltje of college-zaal, maar heel veel “hands-on-terminal” kennis overdracht van ervaren mensen naar jongere leergierige developers.
Hierbij moet de kennisbehoefte van de leerling centraal staan en de meester is daar dienend aan!
In een gilde aanpak staat de meester centraal die weet welke kennis nodig is om het vak te beoefenen. De leerling met een kennisvraag centraal stellen is de omgekeerde wereld.
Dit terzijde, want ik ben het niet met die insteek eens, omdat de software discipline zo nooit boven het niveau van ambacht uitkomt. De ‘academische’ kennis van een Newton, Einstein, Bohr, Planck, en vele anderen heeft ons de industrialisatie, kennis en – voor ICT leuk – halfgeleidertechniek opgeleverd waar de huidige welvaart op gebaseerd is. Zonder theoretisch inzicht, verworven door academisch onderzoek, in electromachnetisme geen microtechnologie, glasvezel, TV, computer.
De complexiteit en kennis die nodig is voor goede software gaan voorbij aan iets wat door afkijken van de meester en een beetje boerenverstand kan worden geleerd. Een beetje theoretisch fundament is onontbeerlijk. Zo wordt ook een beetje computer taal of software architectuur niet bedacht door een hacker maar door een (groep) harde denker(s).
Als ik een huis ga bouwen wil ik een ervaren, academisch geschoolde, architect maar heb ik verder toch het liefst een vakman (ambachtsman) die de bakstenen op elkaar stapelt.
Helaas denken mensen die een paar jaar theoretische scholing achter de kiezen hebben dat zij behoeften van gebruikers kunnen analyseren, de benodigde systemen kunnen ontwerpen en dat zij die ook nog eens perfect kunnen bouwen. Ik heb dan liever dat een MEESTER zich met de eerste stappen bemoeit en dat de LEERLINGEN zich, aan de hand van de meester, alleen met het stapelen van de stenen mogen bemoeien. Als zij bewezen hebben meer te kunnen mogen zij wellicht in de andere fases meepraten.
Vertel dit eens aan de projectmanagers die het liefst jongen (lees goedkope) honden aan het werk zet. Dat die nog te naief is om zich te laten peoplen en in alle mogelijke valkuilen valt neemt hij dan maar voor lief. Want hij is immers op de hoogte van de nieuwste ontwikkelingen en kent alle buzzwords als de beste.