Software engineers op veel fronten overbelast
Het is het allemaal, maar het liefst wel in één persoon. Een software engineer (SE), de moderne variant van de ontwikkelaar-met-de-vijf-poten, moet dus een schat aan kennis, vaardigheden en ervaring bezitten. Aan de hand van een aantal stellingen laten we zien welke aspecten tegenwoordig een rol spelen in het werkveld van de SE. Waar moet de SE al die kennis laten? En hoe komt hij er aan? Geen gemakkelijke vragen die ook geen gemakkelijke antwoorden hebben. De ‘nieuwe SE’ moet daarom ook sterk in zijn schoenen staan, soms ‘nee’ durven zeggen tegen zijn baas of zelfs de klant en vooral plezier hebben in wat hij doet. Zonder de wil om te presteren, te leren en aan te passen kan de SE zich niet meer staande houden. ‘Een SE kan alleen goed zijn als hij op z’n minst twee platformen beheerst’ Het allerbelangrijkste dat een SE in zijn bagage moet hebben is een berg kennis en ervaring op zijn specifieke vakgebied. Het vakgebied is de laatste jaren aan zo’n enorme verbreding en verdieping onderhevig geweest, dat de specialismen niet meer op één A4-tje kunnen worden weergegeven. En van dat alles moet de SE iets weten; van een aantal onderwerpen moet hij alles weten. Hij wordt overvraagd (zie kader). Hij moet niet alleen ‘wat’ van Java weten, nee, hij moet ook de weg kunnen vinden in Visual Studio.NET. Sterker nog, er wordt van hem verwacht dat hij een antwoord kan geven op vragen als: Waarom moeten we deze applicatie nu met Java ontwikkelen? Kan dat niet met Microsoft-dingetjes, of is er geen standaardpakketje voor? Hoe schraapt een SE al die kennis in z’n spaarzame tijd bij elkaar? Het is immers ontzettend lastig om zowel op hoog niveau in een Java-omgeving te opereren als in een.Net-omgeving. Zeker als de.Net-projecten waar hij in acteert lang duren, zodat de kennis over de ins en outs van de Java-omgeving sterk veroudert. Hoewel vaak gezien als noodzakelijk, is het daarom in de praktijk moeilijk twee platformen tot in de details te beheersen. Maar men verwacht het wel. ‘Een SE kan zich bijna niet meer onpartijdig opstellen door de vele partnerships die in de krappe markt worden uitgebuit’ De druk om meerdere platformen te beheersen wordt veelal veroorzaakt door de werkgever, die op deze manier een flexibelere inzetbaarheid van zijn SE’s wil garanderen. Daarnaast ontstaat er echter ook steeds meer druk op SE’s om niet van bepaalde platformen, maar juist van bepaalde producten veel te weten; en dan natuurlijk liefst de producten van partners. Daar is op zich niets mis mee, maar de SE wordt hierdoor gedwongen steeds meer zijn aandacht te richten op bepaalde producten. Dat is niet alleen slecht voor de latere inzetbaarheid - stel dat het product morgen niet meer verkoopt en dus overmorgen niet meer bestaat, waar staat de SE dan? - maar ook voor de objectiviteit of onpartijdigheid. De klant vraagt vaak naar een objectief advies dat de SE niet kan geven als hij door zijn werkgever op pad wordt gestuurd met de glimmende productbrochure van product X op zak. ‘Het carrièrepad van de SE is geen gegeven meer’ In het verleden was het voor een ontwikkelaar voldoende wanneer hij zich technologisch staande kon houden, hierbij geholpen door de veelvuldige toepassing van bijvoorbeeld watervalmethoden. Met technische kennis en een technisch ontwerp van een collega kwam hij de dag wel door. En een goede, ervaren ontwikkelaar werd op een gegeven moment toch wel ‘gepromoveerd’ tot technisch ontwerper; als ontwikkelaar was hij op dat moment te duur geworden. Carrièrepaden waren vroeger niet ingewikkeld. In het kielzog van de internet-hype is de huidige wereld steeds dynamischer geworden. De oude ontwikkelmethoden zijn niet meer toepasbaar of op zijn minst niet meer hip. Iteratief werken zal menig SE inmiddels niet vreemd meer in de oren klinken. Methoden als DSDM en toepassing van RUP vereisen nu eenmaal een iteratieve werkwijze. De SE kan zich dan ook niet meer voordoen als ontwikkelaar pur sang; er worden in iteratieve projecten andere vaardigheden verwacht dan in de ‘oude’ wereld. De persoonlijke ontwikkeling moet hier dan ook op afgestemd worden. Waar de SE vroeger alleen beter hoefde te worden op zijn eigen beperkte technologische gebiedje, moet hij nu veel meer bezig zijn met allerlei zachte vaardigheden. Hij moet met deze nieuwe werkwijzen om kunnen gaan om z’n carrière veilig te stellen. ‘De overlap tussen de hardware- en softwarewereld wordt groter en groter’ Meerdere platformen beheersen. Ondanks alles toch proberen je onafhankelijkheid te behouden. Gedwongen worden op een andere manier naar je carrière te kijken en dan ook nog wat van ‘de dozen’ moeten weten. De wereld naast softwareontwikkeling was altijd de wereld van de infrastructuur. Een softwareontwikkelaar installeert en configureert ‘natuurlijk’ geen hardware. Echter in de huidige tijd wordt de scheidslijn steeds dunner. Denk maar eens aan middlewareproducten die van essentieel belang zijn voor het functioneren van software, die meer en meer integraal deel uitmaakt van wat er onder infrastructuur wordt gerekend. En die trend is nog lang niet voorbij. Meer en meer onderdelen uit de vroegere softwareontwikkeling worden in de toekomst als ‘commodity’ meegeleverd met de infrastructuur. Niet gek dus, dat bovenop alle andere kennis die een SE moet bezitten ook verwacht wordt dat hij om weet te gaan met steeds ingewikkelder wordende infrastructuren. ‘ICT-architectuur is ook voor de SE van wezenlijk belang’ Software en hardware, dus. Waar zijn de tijden gebleven dat de ontwikkelaar zijn tijd kon besteden aan het bouwen van applicaties die hij naar eigen goeddunken kon vormgeven? Die zijn al lang en breed achter de horizon verdwenen. In de wereld waarin alles ‘connected’ moet zijn, ontkomt de SE niet meer aan de wetten van de ICT-architectuur. Zelfs als hij zelf niet verantwoordelijk is voor deze architectuur worden zijn werkzaamheden hier direct en stevig door beïnvloed. Dat kan op grote schaal zijn, waar een schijnbaar kleine applicatie toch een onderdeel vormt van een heel systeemlandschap. Op kleine schaal bieden de zogeheten ‘patterns’ SE’s ook genoeg redenen om zich zorgen te maken; deze patterns helpen natuurlijk wel - bieden absoluut toegevoegde waarde - maar waar zijn ze te vinden? En zijn ze wel zo goed als dat wat de SE zelf bedenkt? Het gaat om de acceptatie dat het wiel in de meeste gevallen niet meer zelf uitgevonden mag worden, de SE moet zich conformeren aan standaards die door zijn ‘connected peers’ worden voorgeschreven. Software engineer overvraagd Niet alleen diepgaande kennis van twee technologische platformen wordt verwacht, ook het volgende hoort tot de minimale bagage van de SE: • -Modelleringstechnieken. • -Modelleringstools. • -Projectbeheersingsmethodieken. • -Eén maar liever meerdere ontwikkel/implementatiemethodieken. • -Conceptuele ICT-kennis: aanvullende kennis van beveiligingsvraagstukken, communicatieprotocollen, databases. • -Planning- en calculatiemethoden. • -Ontwerpmethodieken. • -Analysetechnieken en -tools. • -En een scala van sociale vaardigheden: coaching, luistervaardigheden, procesbegeleiding, teamleiding. Vooral van het laatste heeft het gros van de wereldbevolking wel wat in huis, maar aan een SE worden andere eisen gesteld. Neem bijvoorbeeld flexibiliteit. Een onderdeel van flexibiliteit is om kunnen gaan met onzekerheid: bij opdrachtgevers, eindgebruikers en bij de SE zelf. Hij moet dus zowel de opdrachtgever (en vaak zeer veel mensen daaromheen) het goede gevoel geven, de zekerheid die zo nodig is, en daarnaast ook zichzelf managen bij allerlei onverwachte zaken ("Ach het berekenen van het pensioengat is toch niet zo ingewikkeld, dat kun je er toch wel even bijprogrammeren?"). Flexibiliteit dus. Zelfmanagement. Verwachtingsmanagement. En ook nog goed kunnen communiceren - in woord en geschrift, liefst tweetalig. Dan wordt er ook nog van hem verwacht dat hij wat weet van de markt waarin de organisatie opereert. Voor die SE’s die ’het geluk’ hebben bij het ICT-onderdeel van een grote organisatie te werken, is voor het verkrijgen van marktkennis een minimale inspanning nodig. Maar voor diegenen die in adviesorganisaties werken, moet er ergens toch een keer inzicht verworven worden in de wijze waarop men met pensioenen omgaat, of welke eisen er aan de import van hout worden gesteld. Bovendien moet de SE ook nog thuis zijn in concepten als Supply Chain Management, Call Center Efficiency en de effecten van Basel II. Met andere woorden: de SE moet ook nog één, het liefst twee, maar nog liever een stuk of drie/vier materiegebieden onder de knie hebben. Certificering Een element dat de laatste jaren naar voren is gekomen, met betrekking tot de kwaliteitswaarborg is certificering. Hoe kan een SE daadwerkelijk aantonen dat hij zo goed is als hij zegt dat hij is? Door een aanvaard certificaat te dragen. Certificaten die door een externe, objectieve organisatie worden uitgegeven doen het goed, certificaten die door een specifieke technologieleverancier worden ondersteund zijn ook prima, maar ook interne certificaten bieden toegevoegde waarde bij een meer gestandaardiseerde bepaling van de kwaliteit van een SE. Is dat alles? Een stevig cv is natuurlijk ook nooit weg. Theoriekennis van technologie, ondersteund door de benodigde certificaten, is voor een doorgewinterde SE (met ervaring op andere technologie) vrij eenvoudig in de praktijk te brengen. De abstracte begrippen zullen niet snel anders zijn dan wat hij al als bagage aan boord heeft. Theoriekennis van een ontwikkelmethode, eveneens ondersteund met felbegeerde certificaten, heeft door de intermenselijke aspecten die horen bij de manier van werken geen waarde zonder de nodige praktijkervaring. Sommige certificaten stellen juist ook eisen aan praktijkervaring, bijvoorbeeld in geval van DSDM. Certificering op basis van zowel theoretische kennis als praktische toepassing van die kennis is een typisch voorbeeld van ‘de som der delen’. Maar er is nog iets. De juiste manier van intercollegiale coaching. Iedere SE heeft iemand in zijn buurt nodig die hem als coach kan begeleiden en waarvan hij kan leren - op alle vlakken. Die misschien zelfs wel een onderdeel kan uitmaken van de (interne) certificeringsmethodiek. De nieuwe wereld Platformen, programmeertalen, architecturen; alle techniek heeft op zijn minst een eindige levensduur. Technologieën kunnen ook vrij eenvoudig abstract worden gemaakt; uiteindelijk bestaan in alle programmeertalen constructies om een beslissing te kunnen programmeren. Ontwikkelmethoden pogen echter technologie te koppelen aan intermenselijke aspecten: Hoe zet ik mensen op een zo efficiënt mogelijke manier gezamenlijk aan het werk met een gemeenschappelijk (ontwikkel)doel? Deze intermenselijke aspecten zijn niet zo eenvoudig te abstraheren. In de veranderende wereld wordt van een SE dan ook verwacht dat zowel de technologische als de methodische kant van het vak - inclusief die complexe intermenselijke aangelegenheden - effectiever en efficiënter wordt bijgehouden. Een verandering, dus. En als de SE deze verandering niet kan of wil (mee)maken dan zal het onmogelijk zijn overeind te blijven in ‘de nieuwe wereld’, waarin de opdrachtgever niet meer akkoord gaat met het tentoonspreiden van louter technologische kennis. Uiteindelijk zullen daarom ook de SE’s die zichzelf in beide richtingen - technologisch en methodisch - kunnen blijven (bij)sturen, van onschatbare waarde zijn. De letters ICT zijn dus ook anders uit te leggen: het gaat nu om Intermenselijke vaardigheden, Commerciële aanleg en Technologische kennis, en misschien ook nog wel in die volgorde. Marc Kessler (marc.kessler@capgemini.com) en Tommes Snels (tommes.snels@capgemini.com) zijn Managing Consultants bij Capgemini in de Technology discipline. Beiden zijn actief in Software Engineering. Snels is mede-auteur van ‘Workshops, how to facilitate workshops in software engineering related environments’ (2004).