The following Ph.D. proposal has been tailored to act as a clarification for colleagues and professors, hence it's written in Dutch. The English abstract will follow later. The thesis subject:

The disparity between industrial requirements and classic education of modern software engineering.

De probleemstelling

Wat missen ontwikkelteams en developers¹ tegenwoordig?

Vanuit die vraag ben ik vertrokken.

Als software ingenieur met meer dan een decennium ervaring heb ik een grote interesse ontwikkeld in de manier waarop software tot stand komt. Ik heb een stevige technische achtergrond met een voorliefde om die kennis te delen die zich uit in een actieve rol als coach en lesgever.

Het traditioneel coachen en lesgeven brengt echter niet altijd even veel op. Dat kan natuurlijk aan mij liggen (de manier waarop), aan het de stof die ik wil overbrengen (het onderwerp) of aan de interesse van het doelpubliek (de ontvanger). Bij veel teams waar ik de afgelopen jaren tijd in heb doorgebracht is het moeilijk om iedereen op dezelfde golflengte te krijgen.

Ik begon mij af te vragen hoe ik het probleem zou kunnen identificeren en hier iets concreet rond doen. De vraag werd een meta-vraag: in plaats van te vragen wat te leren begon ik te vragen hoe het leren te leren. Dus: wat zien we over het hoofd wanneer we toegeven dat software schrijven niet altijd gesmeerd loopt?

Aan industriële eisen van moderne software engineers wordt vaak niet voldaan. De alsmaar groeiende nood aan informatici verergert dit probleem slechts: het voorzetzel "goede" is compleet verdwenen in die nood. De schuld geven aan een gebrek van een goede opleiding lijkt erg kortzichtig. Vandaar dat ik bovenstaande vraag wil ombuigen naar een doctoraatsvoorstel:

De ongelijkhheid tussen industriële vereisten en klassieke opleidingen van moderne software ingenieurs.

Op die manier formuleer ik de probleemstelling met persoonlijke inbreng in context van coaching in de industrie en in context van doceren in de onderwijsinstelling.

De woorden in de (Engelstalige) titel verklarend:

0. Disparity: De vraag waaruit ik ben vertrokken, afgebakend en doelgericht op klassieke opleidingen.
1. Industrial requirements: Ik wil het hebben over software die in de industrie gemaakt wordt - de industrie waar ik een integraal deel van uitmaak. Het moet concreet toepasbaar zijn. Ik wil nauw samenwerken met bedrijven, niet enkel met een onderwijsinstelling.
2. Software engineer: met een insteek vanuit de praktische engineering hoek, niet de theoretische computerwetenschappen hoek. In de industrie noemen we onszelf alemaal graag 'ingenieur', maar dat gaat verder dan enkel het technische programmeerwerk.
3. Modern: Het doctoraat moet actueel zijn, in de tegenwoordige tijd. Zelfs al zou het onderzoek jaren duren, daarna moet het nog van toepassing zijn. In de ontwikkelwereld verandert alles bliksemsnel. Ik wil mij focussen op concepten, niet op frameworks die vervangen worden, en zo een blijvende impact maken.

De doelstelling

Voordat we die ongelijkheid uit de weg kunnen ruimen moeten we een andere vraag stellen: wat valt er allemaal onder die zogenaamde industriële vereisten? Die eisen kunnen we langs diverse opleidingen plaatsen om een kritische blik te werpen op de inhoud ervan. Als we terugdenken aan de vraag "wat missen we", onderscheiden we² een aantal belangrijke deelvragen:

1. Productiviteit

Productiviteit manifesteert zich op drie manieren binnen software ontwikkeling:

1. In het beheren van ondersteunende tools.
   Bijvoorbeeld shortcuts vanbuiten kennen van uw geliefde IDE of blind kunnen typen.
2. In efficiëntere codeertechnieken.
   Bijvoorbeeld door het sneller herkennen en toepassen van patronen (zie ook Pragmatiek).
3. In het metafysische.
   Bijvoorbeeld strategiëen voor het overwinnen van afleiding of het beter richten van je sterktes.

Zonder een bewustwordingsproces op gang te brengen gaat dit niet beteren. Een simpele productiviteitswinst van 1%³ kan al voor een flinke besparing op jaarbasis zorgen. Ondersteunende tools winnen en verliezen snel aan populariteit waarbij kennis van specifiek ingebouwde hulpmiddelen snel irrelevant worden. Die kennis kan echter omgezet worden naar een bewustwording van hun bestaan zodat men ook in de toekomstige tools efficiënt kan werken.
Een goede ingenieur is een luie ingenieur die zich constant afvraagt "kan ik hier meer uit halen met minder moeite?".

Een ander aspect van metafysische productiviteit is het zoeken naarde juiste stemming. Daarmee bedoel ik Flow van Mihaly Csikszentmihalyi, Deep Work van Cal Newport en een Growth Mindset van Carol Dweck.

De nodige aandacht dient gegeven te worden aan kwantificeerbaarheid van deze productiviteit binnen software engineering om een correct formeel onderzoek te kunnen uitvoeren.

2. Samenwerking & Begeleiding: Software maak je niet alleen

Desondanks bekende boeken als "PeopleWare: Productive Projects and Teams" van Tom DeMarco is dit iets waar bedrijven altijd het meeste budget in snoeien. 80%² van de ontwikkelproblemen zijn mens-gerelateerd.

Scholen laten studenten vaak samenwerken aan projecten maar vergeten uit te leggen wat de woorden "samen" en "werken" feitelijk betekenen als ze in één woord gebruikt worden. Bijgevolg kunnen wij niet verwachten dat dit in teams vanzelf goed komt.

In de industrie wordt binnen eXtreme Programming vaak het pair programming principe toegepast: met twee personen aan één computer ontwikkelen. De ervaring leert mij dat dit een zeer efficiënte techniek kan zijn om op korte termijn iedereen op dezelfde golflengte te krijgen. Het kan echter ook een recept voor een ramp zijn als geen van beiden toegevingen kan doen.

Een gebrek aan een goed mentor model kan vreselijke gevolgen hebben voor de continuïteit van een software project. Begeleiding is van cruciaal belang om op collega's één lijn te brengen met een minimale inspanning.

Wij hebben vaak de behoefte om volledige controle te hebben en dat is makkelijk terug te vinden in code. Elkaar volledig vertrouwen kan alleen maar als iedereen weet wat de vereisten van een moderne ingenieur zijn en zich daar achter schaart. Wantrouwen moet omgebogen worden naar slim vertrouwen.
Ik wil mij hier richten op een mens-gerichte oplossing die los staat van project ontwikkelingsmethodologieën die komen en gaan als scrum en kanban.

3. Pragmatiek: Het belangrijke van het onbelangrijke onderscheiden

Verstandsverslaving is jammer genoeg een erg aanstekelijke ziekte onder software ingenieurs, en volgens Raj Raghunathan ook een doodzonde van geluk. Het verschil tussen een goede en een heel goede software ingenieur is weten wanneer te stoppen met engineering.

We wensen immers technologie te gebruiken om iets (het domein) uit te drukken, en niet om iets te gebruiken om technologie te tonen. Soberheid is een deugd die dringend in de software industrie gestandaardiseerd moet worden.

Dit probleem beperkt zich echter niet binnen de software ingenieurs maar komt ook terug bij ingenieurs in het algemeen. Ik merk uit mijn ervaring als lesgever dat studenten opdrachten vaak te goed willen doen, en uit mijn ervaring als technische coach dat collega ontwikkelaars dit nog steeds niet hebben afgeleerd.

De focus leggen op het concept in plaats van het framework is echter makkelijk gezegd: hoe doe je dat? Waarom zijn hogescholen zo gebrand op praktische voordelen van frameworks die na 2 jaar toch niet meer actueel zijn? Waarom zijn universiteiten zo gebrand op theoretische concepten zonder een praktisch voorbeeld aan te halen?

Ik wil op zoek gaan naar een goede cocktail van het conceptuele met het praktische. Het is momenteel een moeilijk te definiëren en moeilijk te beheersen kunst om op het juiste moment die grens te trekken. Het beoordelen van Frameworks zoals Angular en React zou kunnen betekenen dat hier gewoon concepten uit overgenomen kunnen worden zonder zich te moeten toeleggen op een volledig nieuw systeem.

4. Software ontwikkeling als een organisch proces

De metafoor die zegt dat software ontwikkelen een beetje zoals tuinieren is sluit mooi aan met mijn idee. Maar wanneer beslis je om takken weg te knippen en bomen bij te planten? Op welke manier druk je je dan uit? Het "groeien" van software wordt altijd ondersteund door test-driven development, zoals het groeien van bomen wordt ondersteund door organische meststoffen. Op die manier reduceer je drastisch het mythische "aantal WTFs per minuut".

De beschrijving van vereisten met de natuurlijke taal in code zorgt voor een belangrijke bijdrage tot onderhoudbaarheid. Concepten die van belang zijn voor je product (zoals een vacature, sollicitatie of contract) moeten dezelfde dingen betekenen in de code zelf. Ik wil hier Domain-Driven Design aanraken, maar er niet helemaal in mee gaan.

Ook Veranderbaarheid of agility is een alsmaar belangrijker onderdeel van software ontwerp dat ook in deze categorie past. Technologieën volgen elkaar in een moordend tempo op: moet je dat altijd volgen?

De criminologische broken windows theorie die stelt dat omgevingen die vuil zijn, meer vuil aantrekken, is jammer genoeg ook van toepassing bij software ontwikkeling. Net als bij het tuinieren zakt de moed je in de schoenen bij het tegenkomen van een groot overwoekerd stuk legacy code.

Buiten Growing Object-Oriented Software, Guided by Tests van Steve Freeman ontbreekt eender welke vorm van een formeel model om software ontwikkeling te benaderen als een organisch proces waar ik met dit voorstel een verschil in kan maken.

5. Creativiteit

Iets creëren vereist altijd een zekere vorm van creativiteit. Patronen leren herkennen maakt het mogelijk om deze toe te passen op andere projecten. Die patronen kunnen een aantal dingen zijn:

1. Letterlijke design patterns zoals de "Gang of Four" ze aanbiedt.
2. Concepten lenen van verschillende programmeertalen en bibliotheken als een echte polyglot.

Over creativiteit hoor je bitter weinig als software ontwikkelaar en dat is een gemiste kans. Het is zelfs een kerndeel van het beroep, als dagelijkse scheppers van virtuele werelden. Hoe bevorderen grote bedrijven als Google de creativiteit van hun techneuten?

Computerwetenschappen is een van de weinige concrete wetenschappen die zich niet moet houden aan de fysieke wetten van onze wereld zoals zwaartekracht. De enige beperking binnen dit domein is je eigen creativiteit! Ik ben ervan overtuigd dat hier meer aandacht aan besteed moet worden.

De manier waarop

Moderne software moet bestand zijn tegen frequente wijzigingen in de vereisten door onder andere grillen van de klant. Daarom kiest men tegenwoordig voor een iteratieve methode die in staat stelt om regelmatig wijzigingen door te voeren zonder jaren nodig te hebben om één groot pakket te realiseren.

Dit concept wil ik graag doortrekken in dit doctoraatsvoorstel. In plaats van een monografie te schrijven die pas na een (heel) aantal jaren af is, zou ik het iteratief willen aanpakken door een collectie van opeenvolgende artikels te schrijven in context van het algehele onderwerp. Deze papers worden op het einde van de rit één mooi geheel door middel van een voorwoord en conclusie.

Dit sluit beter aan met de agile proces dat ook bij Prato gebruikt wordt om sneller feedback te kunnen verzamelen en ook sneller een meerwaarde te kunnen bieden.

De toepasbaarheid

Een industriëel getint onderzoek zonder directe toepasbaarheid voelt maar slap aan. Voor mij persoonlijk, als deels software ontwikkelaar bij Prato en deels lesgever aan KULeuven, is het voornaam dat de toepasbaarheid van het voorstel zowel in de industrie als in de onderwijsinstelling mogelijk is. Ik zou daarom ook nauw willen samenwerken met beide partijen. Die disparity of ongelijkheid in de titel van het voorstel vormt een brug tussen deze beide werelden.

A. Industriële toepasbaarheid

De bewustwording van industriële eisen stelt ons in staat om aan zelfontplooiing te doen als individuele ontwikkelaar en als ontwikkelteam. Concrete resultaten van het onderzoek kan de manier waarop opleidingen tot stand komen aanscherpen, ook binnen een bedrijf.

Onderzoek rond productiviteit kan bijvoorbeeld direct geïntroduceerd worden als een kostenreductie van 1+%³. Die introductie gaat uiteraard meer werk zijn dan enkel het resultaat van dit werk voordragen: dat is nog maar het begin.

Als we de vraag waaruit ik ben vertrokken kunnen beantwoorden, kunnen we ook onze (sprekend vanuit mijn standpunt als technische coach) ontwikkelaars laten zien waar men naar toe kan groeien. Dit kan zelfs gebruikt worden als officieel groeimodel voor ingenieurs, in plaats van archaïsche classificaties van functiedefinities als "junior", "senior" en "architect".

Ook de aanwerving en inzetbaarheid⁴ van nieuwe ontwikkelaars kan hierop afstemd worden. Het subjectief buikgevoel of algehele gebrek aan uniforme testen wordt vervangen door een heldere blik op de vereisten van een moderne ingenieur.

B. Didactische toepasbaarheid

A. Als curriculum wijziging

Kijken we naar een professioneel bachelorprogramma als toegepaste informatica, dan onderscheiden we vakken in ongeveer deze groepen:

• Syntactiek (Java, .NET, PHP, ... "essentials")
• Techniek (Netwerken, OS, ...)
• Analytiek (Problem solving, business, ...)

Merk op hoe weinig van bovenstaande subonderwerpen hieronder vallen. Af en toe verschijnt er een vak "communicatie" onder de laatste groep. Los van de gebrekkige inhoud is dat zeker een stap in de goede richting.

Kijken we naar een academisch masterprogramma als computerwetenschappen of (industriële) ingenieurswetenschappen, dan onderscheiden we de volgende extra groepen:

• Technische Concepten (Algoritmes, datastructuren, ...)
• Functionele Concepten (Wiskunde, natuurkunde)

Deze grondlaag kan voor een uitmuntend inzicht zorgen van een toekomstige software ingenieur. Het probleem is dat niemand een student uitlegt waarom concepten en leren leren belangrijk zijn. Levensbeschouwing om toekomstige samenwerking en inzicht in elkaars denken te bevorderen wordt totaal achterwege gelaten in exacte wetenschapsrichtingen als deze.
Een curriculum wijziging die meer toegespitst is naar de noden van de industrie kan dus zeker geen kwaad, ook al komen niet alle afgestudeerde studenten uiteindelijk in die sector waar ik mij nu tot richt terecht.

Een concreet voorbeeld: het vak "Software ontwerp in Java" leert studenten het ontwerpen software aan met behulp van Java als taal. In werkelijkheid moeten studenten teveel syntactiek leren en verbasteren ze het vak naar "Java". Het belangrijkste valt dus tevergeefs weg.

B. Als deel van LESEC

Dit voorstel past perfect binnen de onderzoeksgroep LESEC:

A community of researchers and practicioners contributing to the advancement of education in the Science, Engineering & Technology group. This includes R&D and consultancy activities, and the establishment of a network for cooperation and the exchange of experiences.

Huidig onderzoek

Er is reeds huidig academisch onderzoek ondernomen in de aparte subonderwerpen. Het is iets moeilijker om bestaande wetenschappelijke artikels terug te vinden rond het overkoepelende onderwerp. Typisch wordt een vraag als "wat missen we nog in de dev teams?" empirisch beantwoord door vallen en opstaan in de bedrijven zelf.

Dit is de status van het huidig onderzoek in context van mijn voorstel:

A. Rond het curriculum van software engineers

• Mehdi Jazayeri's werk als The Education of a Software Engineer
• A rational design process: how and why to fake it

1. Rond Productiviteit

• André Meyer's Ph.D. research rond productiviteit
• Google Research "how developers search for code"
• A Systematic Review of Productivity Factors in Software Development
• L. Hatton: The Chimera of Software Quality

2. Rond Samenwerking & Begeleiding

• Complex group decision making in agile projets
• Non-technical individual skills are weakly connected to the maturity of agile practices
• Group developmental psychology and software development performance
• The Big Effects of Short-term Efforts: Mentorship and Code Integration in Open Source Scientific Software
• A Mentorship Framework for Work Integrated Learning in Software Development

3. Rond Pragmatiek

• On the relation between unit testing and code quality
• Pragmatic software engineering for computational science
• The Research-practice gap
• Over-engineering enterprise architecture and business competitiveness
• Learning research: en de toepasbaarheid op sw.eng. Hoe leren we? Welke manieren zijn goed om teams dingen bij te leren? Brown bags VS random meetings VS coding schools VS ... Microlearning onder andere.
• What makes good research in Software Engineering

4. Rond Software ontwikkeling als organisch proces

• Theorizing about software development practices
• Lucas Gren's Ph.D. research rond agile software engineering

5. Rond Creativiteit

• Creativity research: implications for teaching, learning and thinking
• The cognitive neuroscience of creativity
• Assessing the Work Environment for Creativity
• How Would You Move Mount Fuji?: How the World's Smartest Companies Select the Most Creative Thinkers