NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.
Craftsmanship, ofwel vakmanschap, is een stroming binnen softwareontwikkeling die de vakkennis van ontwikkelaars vooropstelt. Het doel is om kwalitatief goede software te schrijven.
De term craftmanship is niet nieuw. Jack W. Reeves introduceerde de term craftsmanship in 1992 in relatie tot softwareontwikkeling. Pas in 2001 schreef Pete McBreen het boek met de titel ‘Software Craftmanship’. Vreemd genoeg is het dan lang stil rondom dit onderwerp. In 2008 wordt het onderwerp door Uncle Bob weer opgepakt.
De laatste jaren komt het onderwerp steeds vaker op de voorgrond. Volgens mij zijn outsourcing en agile softwareontwikkeling twee belangrijke drijfveren voor de hernieuwde interesse in craftsmanship.
Outsourcing
Het uitgangspunt van outsourcing en offshoring is dat softwareontwikkeling een eenduidig en lineair productieproces is. De locatie voor het ontwikkelen is minder relevant. De focus binnen een softwareontwikkeltraject verschuift naar de financiële aspecten. Met andere woorden: het moet vooral goedkoop zijn. Vele projecten faalden spectaculair en de gewenste kostenreductie werd vaak niet gehaald. De software was veelal niet van de gewenste kwaliteit. Dit wordt vaak verweten aan het gebrek aan vakkennis, maar miscommunicatie en culturele verschillen zijn volgens mij net zulke belangrijke factoren in het falen van outsourcingsprojecten. Deze sociale kant is een vaak onderschatte component.
Agile
Veel teams werken dagelijks met agile- of scrumtechnieken. Als lid van een agile-team zijn zowel de communicatieve als de technische vaardigheden erg belangrijk. Als team ben je verantwoordelijk voor het resultaat en communiceer je vaak direct met de eindgebruikers of een representant. De agile-beweging gaat er impliciet van uit dat elk lid een softwarecraftsman is; iedereen verstaat zijn vak grondig. Deze basisaanname is te simplistisch. Hierdoor staat codekwaliteit en de definitie van craftsmanship vaak ter discussie in veel teams.
Wat is kwalitatief goede software?
Een eenduidig antwoord op de vraag ‘Wat is kwalitatief goede software?’ is lastig in softwareontwikkeling. Het begrip kwaliteit is namelijk al snel subjectief. Natuurlijk zijn er al goede kengetallen en technieken die de algemeen geldende ‘best practices’ kwantificeren. Hierdoor kun je tot op zekere hoogte kwaliteit meten. Dit zijn goede hulpmiddelen en geven een goede basis voor een discussie binnen je team over codekwaliteit.
Vanuit technisch oogpunt is goede software redelijk objectief te beschrijven. Goede software beschrijft de gewenste functionaliteit van een systeem in een heldere architectuur. Door de architectuur te implementeren met behulp van design patterns, Java-standaarden en andere best practices wordt het ontwerp niet alleen duidelijk voor de ontwikkelaar zelf, maar ook voor zijn collega’s die thuis zijn in dezelfde principes.
De samenstelling van een team heeft eveneens grote invloed op het begrip en perceptie van kwaliteit. Elk team heeft verschillende ingrediënten nodig. Een balans tussen ervaring, kennis en communicatieve vaardigheden is een vereiste. Met deze ingrediënten kun je tot een goede en gefundeerde definitie van kwaliteit komen voor het project waaraan het team werkt.
Wat is een goede softwareontwikkelaar?
De sociale kant van de discussie over craftsmanship is een stuk minder eenduidig. De houding van een softwareontwikkelaar is een vaak genoemd argument. Hij moet leergierig zijn, proactief, verantwoordelijk, een teamplayer, sociaal, communicatief, trots op zijn werk en niet snel tevreden over het resultaat. Los van het feit of zo’n ontwikkelaar überhaupt bestaat, heeft iedereen wel een beeld bij deze karaktereigenschappen. Juist dit subjectieve beeld maakt het lastig een objectief en algemeen beeld te vormen over craftsmanship.
Meten is weten. Of niet?
Ik noemde het al eerder; softwarekwaliteit kun je meten. Deze meetgegevens zijn erg belangrijk bij de definitie van softwarekwaliteit. Helaas worden ze te vaak als repressiemiddel gebruikt. Een veelvoorkomend fenomeen is het sturen van ontwikkelteams op basis van kengetallen. Ongeacht welk kengetal centraal staat, zullen ontwikkelteams ernaar streven dit doel te halen. Daarmee creëer je een schijnzekerheid dat de kwaliteit van de software op het gewenste niveau is. Deze schijnzekerheid ontstaat doordat de context van het het kengetal in relatie tot de kwaliteit verloren gaat. De context is meestal een combinatie van de architectuur en de gekozen implementatie.
Stel je bouwt een simpele CRUD-applicatie en leunt hierbij sterk op een bestaand en bewezen framework voor je implementatie. Door het vele hergebruik is een unittest niet meteen noodzakelijk. Hierdoor gaat je test coverage drastisch omlaag. De vraag is nu of dit een probleem is? Als het beleid bij het bedrijf is dat alle software een test coverage van 90 procent moet hebben, dan heb je grote kans dat het team veel unittesten gaat schrijven omwille van het kengetal. Het voegt weinig toe aan de softwarekwaliteit. De gekozen implementatie was namelijk al goed bevonden door de vele andere gebruikers van het gekozen framework.
Meetgegevens over softwarekwaliteit zijn een hulpmiddel om de vaardigheden binnen een team te verbeteren. Je kunt je als team een aantal doelen stellen om de kwaliteit van je software te verbeteren. De verworven kengetallen geven een indicatie in hoeverre je een doel hebt gehaald. Kengetallen moet je altijd relateren aan de context waarvoor ze gelden. Wees voorzichtig als je projecten met elkaar vergelijkt. Kijk niet alleen naar de getallen over codekwaliteit.
Door als team de meetgegevens openlijk te bespreken, begint vaak een beter besef, of beter gezegd, gevoel te ontstaan over codekwaliteit. De definitie van het begrip craftsmanship wordt zo geplaatst binnen de context van je team, de gekozen architectuur en de codestandaarden van het bedrijf waar je werkt.
Hoe word ik een betere vakman?
De verbeterpunten voor elke softwareontwikkelaar liggen mogelijk op sociaal of op een technisch vlak. De technische vaardigheden zijn wat makkelijker te trainen. Er zijn talloze boeken geschreven over het schrijven van goede code. Door veel te oefenen, huidige best practices toe te passen en veel code te verbeteren, krijg je meer gevoel bij de achterliggende principes. Het schrijven van code in meerdere talen is een andere en interessante manier om beter inzicht te krijgen in het schrijven van code. Verder is het belangrijk dat je weet hoe de tools werken.
Goede software schrijven kost tijd. Door regelmatig de softwarekwaliteit ter discussie te stellen en het vele oefenen en verbeteren van bestaande functionaliteit wordt veel tijd geïnvesteerd in iets dat niet meteen zichtbaar is als toegevoegde waarde. Het is namelijk een diepteinvestering. Dit levert vaak een spanningsveld op tussen projectmanagement en ontwikkelteams. De verwachte resultaten van de gemaakte tijdsinvestering overspannen vaak de tijdsduur van een project. Dit brengt andere, doorgaans financiële, belangen in het geding.
Samenspel
Ik hoop dat je na het lezen van dit artikel een beter beeld hebt gekregen over de te term craftsmanship. Eén conclusie kunnen we wel trekken, craftsmanship is niet zo makkelijk op een objectieve manier te meten. De sociale en communicatieve aspecten zijn even belangrijk als de technische aspecten. Het is een samenspel tussen kennis en kunde, samenstelling, bedrijfscultuur en waarden. Hierdoor kan een algemeen besef of beter gevoel ontstaan waaraan de code moet voldoen.
Samenvatting
Dit artikel raakt bij lange na niet alle aspecten die gerelateerd zijn aan craftsmanship. Ik heb wel geprobeerd om de belangrijkste eruit te lichten. Door de hele tekst heen speelt perceptie een grote rol. Dit is ook direct het grote struikelblok in de hele discussie die er gaande is over craftmanship. Er zijn vele meningen en invloeden die een definitie trachten te geven aan kwaliteit. Helaas is het niet mogelijk om deze definitie objectief te maken. Persoonlijk vind ik het goed dat er verschillende percepties zijn van goede code. Door met anderen te spreken over de gehanteerde normen en waarden, kan ik mijn eigen perceptie mogelijk aanpassen, zodat deze een breder draagvlak krijgt. Voor het bereiken van een goede kwaliteit is communicatie essentieel.
De interpretatie van de kengetallen is en blijft lastig, met name omdat deze binnen veel organisaties als pressiemiddel gebruikt worden en niet direct bijdragen aan de kwaliteit. Het is belangrijk dat wij aan het management duidelijk maken dat de getallen wel een indicatie geven over kwaliteit, maar zeker niet objectief zijn.
Wezenlijk voor craftsmanship is het continu willen verbeteren van jezelf en anderen. Je kan dit doen door trainingen. Beter is met anderen te sparren over verschillende aspecten, congressen en seminars zijn uitgelezen momenten om dit te doen. Je moet niet vergeten dat een teamoverleg minstens zoveel kan toevoegen aan kwaliteit. Alleen wij als developers zijn in staat om gezamenlijk een breed geaccepteerde definitie van kwaliteit te maken.