De Kick Ass development reeks

Je bent als software ontwikkelaar continu bezig om je allerlei gereedschappen en technieken eigen te maken. De vaardigheid om snel en effectief te leren is misschien wel de belangrijkste die je als ontwikkelaar hebt. Het belangrijkste gereedschap dat je hierbij gebruikt is je brein. Maar maak je daar wel optimaal gebruik van? In de Kick Ass Development reeks zullen we je aan de hand van modellen en praktijkvoorbeelden inzichten en tips geven om je brein te refactoren voor optimaal rendement. Waar het eerste artikel in deze reeks zich vooral richtte op de vraag hoe je als software engineer te werk kunt gaan om kennis te vergaren richt dit artikel zich vooral op de vraag welke kennis belangrijk is. In een volgend deel van deze serie zullen we ons vooral richten op een van de kernaktiviteiten van software engineering: ’problem solving’.

Deel 2: Kennisgebieden voor developers.

Wat zijn belangrijke leergebieden voor ontwikkelaars die tot de categorie ‘kickass developer’ willen behoren? Daar verschillen de meningen nogal over. Over het algemeen leggen bedrijven de nadruk vooral op (inter)persoonlijke vaardigheden en platformspecifieke vaardigheden of 'technologieën'. Alhoewel die vaardigheden zeker ook belangrijk zijn, richt dit artikel zich met name op twee soorten kennis die over het algemeen duurzamer zijn: domeinkennis en algemene software engineering vaardigheden.

Veel software ontwikkelaars denken bij software engineering vooral aan kennis van specifieke technologieën: Java, .Net, C++, HTML, Javascript, Linux, Windows, etc. Kennis van die technologieën is zeker nodig om software te kunnen ontwikkelen. Maar is dat werkelijk de bepalende factor om een goede ontwikkelaar te worden? Ben je echt voornamelijk code aan het produceren als je software ontwikkelaar bent? 100% van de tijd?

Veelal ligt bij het ontwikkelen van software de nadruk op productieverbetering. De manier om dat te bereiken wordt vaak gezocht in technische oplossingen zoals kennis van frameworks. Zou je productiever worden in schaken als je traint in het sneller bewegen van de schaakstukken?

Frederick Brooks schreef in de jaren 80 een klassiek artikel: ‘No silver bullet – Essence and Accidents of software engineering’ (Brooks, 1987). Volgens Brooks is het moeilijkste deel van ons werk niet zozeer het vertalen van concepten in ons hoofd naar de technologieën waarmee we die ideeën uitdrukken: ‘I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.’ Wat software engineering in essentie zo moeilijk maakt volgens Brooks zijn ‘complexity, conformity, changeability, and invisibility’.

Complexity – zelfs als je een perfecte DSL (Domain Specific Language) tot je beschikking hebt blijft ons werk ingewikkeld omdat de relaties tussen entiteiten nog steeds precies gedefinieerd moeten worden, excepties nog steeds exact en volledig geïdentificeerd moeten worden en er nog steeds geanticipeerd moet worden op alle mogelijke ‘state transitions’.

Conformity – zelfs als je een volledig nieuw systeem gaat ontwikkelen moet de software zich meestal conformeren aan allerlei beperkingen zoals: hardware omgeving, software omgeving, 3rd party components, legacy data, etc.

Changeability – hoe succesvoller een applicatie is, hoe meer manieren er gevonden zullen worden om het te gebruiken, hoe groter de druk wordt om het aan te passen in richtingen waar vooraf nooit op geanticipeerd is.

Invisibility – zelfs het meest eenvoudige runtime gedrag van software wordt binnen de kortste keren absurd ingewikkeld als je het probeert te visualiseren. Kennis over runtime gedrag is dus bijzonder moeilijk over te dragen.

Alistair Cockburn verwoordde de complexiteit in ons vakgebied op de agile 2009 conference als volgt:

Ons vak is dus in essentie complex en kennis van verschillende frameworks helpt maar mondjesmaat in het omgaan met die complexiteit. Sterker nog: een veelvoud van talen, frameworks en tools die regelmatig van versie veranderen maken het er niet makkelijker op! En dat terwijl ze vaak juist gemaakt zijn met de bedoeling om tijd te besparen. Tijd die vervolgens gebruikt kan worden voor het oplossen van de essentiële problematiek. Hoe die essentiële problemen dan opgelost kunnen worden wordt vaak in het midden gelaten. Het lijkt er soms op dat frameworkbouwers, opleiders, maar vaak ook werkgevers en klanten veronderstellen dat die kennis al aanwezig -, of minder relevant is.

Algemene engineering vaardigheden

Wat betekenen die conclusies van Brooks en Cockburn voor ons als software engineers? Ze helpen wellicht om dat nieuwe productiviteitsverhogende framework - waarmee je zogenaamd met 4 annotaties en 3 muiskliks een volledige webapplicatie kunt bouwen - in perspectief te zien.

De focus op methodieken, technologieën en (inter)persoonlijke vaardigheden heeft veel vruchten afgeworpen. De balans echter is naar ons idee soms zoek en we pleiten in dit artikel daarom voor een herwaardering van algemene software engineering vaardigheden. Algemene software engineering vaardigheden zijn niet gericht op een specifieke taal of platform. Het is kennis die altijd van pas komt of je nou met java, .NET, Oracle, flex, C, C++, Ruby of wat voor taal dan ook werkt. Deze kennis gaat vrij lang mee, is niet of nauwelijks onderhevig aan trends en daarom een uitstekende investering voor kick-ass developers.

SWEBOK

IEEE en ACM vakmensen uit de theoretische en uit de praktische hoek (o.a. McConnell, Kruchten, Sommerville, Pressman, etc.) hebben jaren geleden wereldwijde consensus bereikt over wat software engineering inhoudt. Hun streven was een 'Body Of Knowledge' te definiëren waarmee het software engineering vakgebied geprofessionaliseerd wordt. Wat ze o.a. opgeleverd hebben is 'the guide to the SoftWare engineering Body Of Knowledge (SWEBOK)'. De SWEBOK richt zich op algemeen aanvaarde kennis en laat daarmee de nieuwste- maar ook de heel specifieke vormen van software ontwikkeling onberoerd. In de woorden van de SWEBOK: 'The generally accepted knowledge applies to most projects most of the time, and widespread consensus validates its value and effectiveness.' Relevante deelgebieden ('SWEBOK knowledge areas') die onderscheiden worden zijn: requirements, design, construction, testing, maintenance, configuration management, management, process, tools and methods en quality.

Deze deelgebieden worden weer verder opgesplitst in subdeelgebiedjes (bouwstenen). Tabellen maken duidelijk welke literatuur je zou moeten lezen om jezelf een bouwsteen eigen te maken. In feite is de SWEBOK dus een taxonomie waarvan de ‘leafs’ gevuld zijn met verwijzingen naar ‘best practices’ literatuur.

Ter illustratie zoomen we kort in op de ‘design knowledge area’. Deze knowledge area is opgedeeld in: Software Design fundamentals, Key Issues in Software Design, Software Structure and Architecture, Software Design Quality Analysis and Evaluation, Software Design Notations en Software Design Strategies and Methods. De ‘Key Issues in Software Design’ subarea is vervolgens weer opgedeeld in: Concurrency, Control and handling of events, Distribution of components, Error and exception handling and fault tolerance, Interaction and presentation en Data persistence. Voor ‘Control and handling of events’ wordt bijvoorbeeld verwezen naar hoofdstukken en paragrafen in ‘Software Architecture in Practice’ (van Bass, Clements & Kazman), ‘Object-Oriented Software Construction’ (van Meyer) en ‘Software Engineering: Theory and Practice’ (van Pfleeger). In de ‘list of further readings’ van de design knowledge areas staan nog vele andere interessante verwijzingen zoals: ‘Refactoring’ en ‘Patterns of Application Architecture’ van Fowler, ‘Design Patterns’ van the gang of four, ‘The 4 + 1 view model of architecture’ van Kruchten, Object Oriented Design heuristics van Riel en ga zo maar door. Niet de minste boeken en een uitstekend uitgangspunt om op verder te bouwen!

Figuur 1: Impressie van de SWEBOK indeling

Deze deelgebieden worden weer verder opgesplitst in subdeelgebiedjes (bouwstenen). Tabellen maken duidelijk welke literatuur je zou moeten lezen om jezelf een bouwsteen eigen te maken. In feite is de SWEBOK dus een taxonomie waarvan de ‘leafs’ gevuld zijn met verwijzingen naar ‘best practices’ literatuur.

Gebruik van de SWEBOK

De SWEBOK kan op allerlei manieren gebruikt worden. In dit artikel belichten we 3 manieren van gebruik: als hulpmiddel bij het zoeken naar ‘wat vind ik leuk in m’n vakgebied’, als hulpmiddel om lacunes in vaardigheden op te sporen en als literatuurverwijzer.

Allereerst helpt de SWEBOK om inzicht te krijgen in wat je leuk vindt in het software engineering vakgebied. Nadenken over je professionele toekomst met een leeg vel papier voor je is een stuk moeilijker dan met de SWEBOK indeling bij de hand. Je zou er voor kunnen kiezen de gebieden weg te strepen die je totaal niet aanspreken en in te zoomen op de gebieden die overblijven.

De SWEBOK kan je ook helpen bij het in kaart brengen van lacunes in je kennis. De SWEBOK geeft een zeer goed overzicht van het totale software engineering landschap. Met de SWEBOK bij de hand is het veel eenvoudiger om gebrek aan kennis op te sporen, te benoemen en in een groter geheel te beschouwen. Het wordt makkelijker om het gebrek aan kennis op te heffen: je kunt de kennisgaten immers sneller opsporen en door de SWEBOK taxonomie zul je al vrij snel zien welke aangrenzende kennisgebieden je al wel beheerst. Van daaruit kun je je kennis dan verder uitbreiden.

Daarnaast kun je de SWEBOK gebruiken als literatuurverwijzer. De SWEBOK bevat verwijzingen naar allerlei boeken die hoog scoren in verschillende software engineering boekenlijsten. Bovendien is de kans heel groot dat je in de SWEBOK interessante artikelen en boeken vindt die je nog niet kende. Aangezien het om 'generally accepted knowledge' gaat is de leeftijd van de guide (5 jaar) geen bijzonder groot probleem. Als je de SWEBOK hebt gebruikt om te bepalen waar je passie in het vakgebied ligt, zijn de literatuurverwijzingen in de gekozen deelgebieden uitstekende zelfstudie wijzers.

Minpunten en tekortkomingen van de SWEBOK

De SWEBOK wordt weleens gezien als het kroonjuweel van de traditionele software engineering methodieken. Het lijkt gebaseerd te zijn op de veronderstelling dat alles gedocumenteerd moet worden (Rico, Sayani, Sone, 2009). Bovendien is veel literatuur waar naar verwezen wordt in de ‘requirements’-, ‘management’- en ‘proces’ deelgebieden gebouwd op de waarden uit het rechterrijtje van de ‘manifesto for Agile Software Development’: processes, tools, comprehensive documentation, contract negotiation and following a plan. Dit wordt deels veroorzaakt door het moment waarop de SWEBOK is gecreëerd. De SWEBOK reflecteert ‘the state of the practice’ rond de milleniumwisseling. Hierdoor wordt nauwelijks aandacht besteed aan agile methodieken, maar bijvoorbeeld ook niet aan gedistribueerde ontwikkelteams en web-based development. Andere gebieden die niet opgenomen zijn in de SWEBOK, maar bijvoorbeeld wel vaak opgenomen zijn in ‘university programs’ zijn o.a. Human computer interfaces graphics and visualization, algorithms, databases and information management, safety and security, networks internet and distributed systems, operating systems and middleware & hardware and computer engineering (Pyster, Turner, Henry, Lasfer, Bernstein, 2009).

De waarde van SWEBOK

Ondanks de kritiek op de SWEBOK, is het op dit moment de beste taxonomie voor software engineering en een rijke bron van literatuurverwijzingen. Er is ontzettend veel kennis over algemene software engineering aanwezig in het vakgebied maar die kennis is versnipperd in allerlei boeken en artikelen. De SWEBOK heeft die kennis netjes ingedeeld en bij elkaar gebracht. De SWEBOK wordt actief onderhouden en de volgende versie wordt al in 2010 verwacht. Veel van de boeken en artikelen die in de 2004 versie genoemd werden zullen ook in de 2010 versie terugkomen omdat die algemene engineering kennis ook belangrijk is in een ‘agile’ tijdperk.

Als ontwikkelaar heb je kennis van technologieën nodig om je vak uit te kunnen oefenen, maar heb je kennis van algemene engineering vaardigheden nodig om je vak goed uit te kunnen oefenen. Misschien ken je het Spring framework niet in detail, maar weet je wel alles van Aspect oriëntatie en dependency injection. Misschien heb je nog nooit gewerkt met Hibernate, maar ken je wel de belangrijkste problemen en oplossingen rondom Object Relational Mapping (ORM). Door de onderliggende kennis te beheersen overleef je het hoge tempo waarin talen en frameworks komen en gaan. Algemene software engineering kennis overleeft langer dan specifieke implementaties. De SWEBOK helpt om die algemene kennis te vinden.

Domeinkennis

Naast de algemene engineering kennis wordt in ons vak domeinkennis vaak onderbelicht. Domeinkennis wordt over het algemeen pas na je studie opgedaan, en wordt vaak bepaald door de omgevingen waar je als ontwikkelaar in beland. Als techneuten houden we ons graag bezig met techniek en denken daarom niet vaak na over een investering in domeinkennis. Toch is het voor een ontwikkelaar handig om hier bewust mee om te gaan.

Domeinkennis is noodzakelijk

Om software te schrijven voor een business domein moet een ontwikkelaar een solide grip hebben op de concepten en processen in dat domein.
Gewapend met deze domeinkennis kan een ontwikkelaar samen met teamleden een gemeenschappelijke 'taal' ontwikkelen waarmee deze concepten en processen ook in code kunnen worden gevat. Door dit gebruik van wat Eric Evans (Evans, 2004) een 'ubiquitous language' noemt kunnen veel misverstanden omtrent de functionaliteit worden voorkomen. Veel ontwikkelaars zijn geneigd om zo snel mogelijk met programmeren te beginnen. Agile software development lijkt dat ook te stimuleren: lever snel software op, die je vervolgens samen met de klant evalueert op geschiktheid. Wat hierbij vaak wordt vergeten is dat een verdieping in het domein een ontwikkelaar kan helpen om effectiever en productiever te zijn door eerder de juiste oplossingen te kiezen. Een eerste iteratie met werkende software die totaal niet aansluit bij het domein van de klant zal de productiviteit in volgende iteraties vrijwel zeker vertragen. Domeinkennis helpt bij het maken van designkeuzes, bij het kiezen van de juiste benamingen, en bij het op peil houden van de productiviteit.

Daarnaast helpt domeinkennis bij het inleven in de eindgebruiker. Als je niet precies begrijpt wat een gebruiker met de software wil bereiken is het meestal erg moeilijk - zo niet onmogelijk - om de juiste keuzes te maken bij het ontwerp van een oplossing. Een ander belangrijk voordeel van domeinkennis is de verminderde afhankelijk van de beschikbaarheid van domein experts - in veel projecten een bottleneck.
Overigens zien we in de praktijk nog wel eens dat de focus op domeinkennis en het vervatten ervan in code applicaties oplevert die niet vooruit te branden zijn. De focus op het modelleren van het domein moet hand in hand gaan met de benodigde software design skills die zorgen voor een applicatie met voldoende performance.

Domeinkennis helpt bij het scheiden van verantwoordelijkheid

Het benadrukken van het domein kan namelijk ook helpen om een duidelijke scheiding aan te brengen tussen de domein logica en ondersteunende technische code. In projecten krijg je al snel te maken met de al eerder genoemde 'accidentele' complexiteit. De kunst is om te blijven focussen op de essentiële problemen: de business problemen die de software op moet lossen. Voor accidentele complexiteit bestaan vaak al oplossingen en frameworks die zichzelf al bewezen hebben in de praktijk. Domeinkennis maakt duidelijk wat bij het domein hoort, wat niet en op welke manier. Door in het ontwerp van een systeem een duidelijk onderscheid aan te brengen tussen de domeinlogica en de plumbinglogica, wordt het veel eenvoudiger om het domein te doorgronden, te begrijpen en te onderhouden. Dit is waarom Eric Evans met zijn Domain Driven Design boek zo'n enorme bijdrage heeft geleverd aan ons vakgebied.

Domeinkennis kan een strategisch voordeel opleveren

Naast de al eerder genoemde voordelen kan domeinkennis ook voordelen opleveren bij het verkrijgen van een klus of nieuwe baan. Klanten werken graag met mensen die begrijpen waar ze het over hebben en domeinkennis kan je daarom een voorsprong bieden ten opzichte van andere ontwikkelaars die zich liever beperken tot technische onderwerpen. Bovendien heeft domeinkennis over het algemeen een langere houdbaarheidsdatum dan technologische kennis. Verzekeringssoftware heeft bijvoorbeeld meestal een zeer beperkte levensduur, maar kennis van het domein verzekeringen kan zomaar je hele leven van pas komen. Laat het niet van toeval afhangen welke domeinkennis je opbouwt, maar probeer je te richten op een domein dat je interesseert en dat toekomst heeft.

Wat is nu belangrijk?

In zijn bestseller ‘the seven habits of highly effective people’ (Covey, 1989) deelt Stephen Covey activiteiten in in een belangrijk/ urgent kwadrant:

Figuur 2: Stephen R. Covey’s Time Management Quadrants

Door de focus op 100% inzet van mensen besteden veel IT-ers het overgrote deel van hun leerinspanningen in kwadrant I. Men heeft de tooling van het voorgaande project nog maar net onder de knie en de nieuwe tooling in het nieuwe project dringt zich alweer op. Vooral in de commerciële sector ligt de nadruk vaak op het onder hoge druk snel opleveren van oplossingen. Er is nauwelijks tijd om er achter te komen ‘waar de configuratievinkjes zitten’, laat staan om een goede, onderhoudbare oplossing te ontwikkelen. Tom DeMarco omschrijft dit gedrag als template junkies: hectische activiteit wordt aangezien voor gezonde productiviteit(DeMarco, 2008). In de spaarzame overgebleven tijd ontsnappen ontwikkelaars naar kwadrant III en IV activiteiten. De tijd wordt dan gevuld met onbelangrijke activiteiten waar weinig druk op zit en die je het gevoel geven dat je in ieder geval bezig bent. Volgens Covey richten effectieve professionals zich echter vooral op Kwadrant II. Op kwadrant I hoef je je niet te richten; die activiteiten dienen zichzelf wel aan. Door je op kwadrant II activiteiten te richten zullen de crises echter afnemen.

In zekere zin zou je kunnen zeggen dat specifieke technologieën zich bevinden in kwadrant I en III. Ze kunnen belangrijk of minder belangrijk zijn voor het slagen van projecten, maar ze dringen zich in ieder geval op en je krijgt als ontwikkelaar al snel het gevoel dat je de tooling van een project zo snel mogelijk onder de knie moet krijgen. Algemene engineering vaardigheden dringen zich minder op, zijn minder urgent aanwezig, maar wel degelijk belangrijk. Het aanscherpen van algemene engineering vaardigheden is overduidelijk een zeer belangrijke, maar in het dagelijkse werk schijnbaar minder urgente vaardigheid. Het is een typische kwadrant II activiteit. Door je te concentreren op algemene engineering vaardigheden zul je de specifieke talen en tools - die elk project weer in andere samenstellingen en versies voorkomen - veel sneller onder de knie krijgen. Bovendien heb je dan echt krachtig gereedschap in handen: gereedschap waarmee je de complexiteit die inherent is aan software engineering binnen de perken kunt houden.

Tenslotte

Algemene software engineering vaardigheden helpen om zo goed mogelijk om te gaan met de complexiteit in ons vakgebied. Een investering in algemene engineering vaardigheden rendeert veel langer dan een investering in een specifieke technologie of tool. Investeringen in talen en tools dringen zich echter veel meer op dan investeringen in engineering vaardigheden of domeinkennis. De reden daarvoor komt tot uiting in de kwadranten van Covey. Een kickass developer zorgt dat hij of zij de verschillende technologieën goed beheerst, maar probeert zich vooral algemene engineering vaardigheden eigen te maken. Als je stevig geworteld bent in deze fundamentele kennis val je niet om als de wind uit een andere richting gaat waaien.

Referenties

• Abran A. et al. Guide to the Software engineering body of knowledge (SWEBOK). IEEE CS Press. (2004)
• Brooks Fred P.  "No Silver Bullet - Essence and Accidents of Software Engineering". IEEE Software 20 (4): 10-19. (April 1987)
• Covey, Stephen R. The 7 habits of highly effective people. Pocket Books. (1989)
• DeMarco, Tom et al. Adrenaline Junkies and Template Zombies. Understanding Patterns of Project Behavior. Dorset House Publishing, 2008
• Evans. Eric. Domain Driven Design. Tackling Complexity in the Heart of Software. Addison-Wesley, 2004.
• Fowler, Chad. The Passionate programmer. Pragmatic Bookshelf, 2009
• Pyster A., Turner R., Henry D., Lasfer L., Bernstein L.. “Master’s degrees in software engineering: an analysis of 28 university programs”. IEEE Software 26 (5): 94 – 101. (September / October 2009)
• Rico D.F., Sayani H.H., Sone S.. The business value of agile software methods:maximizing ROI with Just-in-Time Processes and Documentation. J.Ross (2009)