230 lines
20 KiB
Markdown
230 lines
20 KiB
Markdown
---
|
|
title: A Ph.D. Thesis Proposal
|
|
date: '2018-06-04'
|
|
subtitle: Bridging the gap between software development requirements in the industry and eudcations in the academia
|
|
tags:
|
|
- phd
|
|
published: true
|
|
categories:
|
|
- education
|
|
aliases:
|
|
- /proposal/
|
|
- /post/phd-proposal/
|
|
---
|
|
|
|
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[^1] tegenwoordig?
|
|
|
|
Vanuit die vraag ben ik vertrokken.
|
|
|
|
Als software ingenieur met meer dan een [decennium ervaring](/about) 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.
|
|
3. **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.
|
|
4. **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[^2] een aantal belangrijke **deelvragen**:
|
|
|
|
#### 1. Productiviteit
|
|
|
|
Productiviteit manifesteert zich op drie manieren binnen software ontwikkeling:
|
|
|
|
1. In het beheren van ondersteunende _tools_. <br/>Bijvoorbeeld shortcuts vanbuiten kennen van uw geliefde IDE of blind kunnen typen.
|
|
2. In efficiëntere codeertechnieken. <br/>Bijvoorbeeld door het sneller herkennen en toepassen van patronen (zie ook Pragmatiek).
|
|
3. In het _metafysische_. <br/>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%[^3] 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.<br/>
|
|
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](https://www.ted.com/talks/mihaly_csikszentmihalyi_on_flow), Deep Work van [Cal Newport](https://www.ted.com/talks/cal_newport_why_you_should_quit_social_media) en een Growth Mindset van [Carol Dweck](https://www.ted.com/talks/carol_dweck_the_power_of_believing_that_you_can_improve).
|
|
|
|
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](https://en.wikipedia.org/wiki/Peopleware:_Productive_Projects_and_Teams) is dit iets waar bedrijven altijd het meeste budget in snoeien. 80%[^2] 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.<br/>
|
|
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](https://www.happysmarts.com/) 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](https://angularjs.org/) en [React](https://reactjs.org/) 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](https://nl.wikipedia.org/wiki/Broken_windows_theory) 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](https://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627) 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](https://en.wikipedia.org/wiki/Design_Patterns)" 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](http://www.prato.be) en deels lesgever aan [KULeuven](http://www.kuleuven.be), 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+%[^3]. 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[^4] 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. <br/>
|
|
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](https://set.kuleuven.be/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](http://www.inf.usi.ch/jazayeri/) werk als [The Education of a Software Engineer](http://www.inf.usi.ch/jazayeri/docs/papers/educationofSEASE.pdf)
|
|
- [A rational design process: how and why to fake it](http://users.ece.utexas.edu/~perry/education/SE-Intro/fakeit.pdf)
|
|
|
|
#### 1. Rond Productiviteit
|
|
|
|
- [André Meyer's Ph.D. research rond productiviteit](http://www.andre-meyer.ch/category/research/)
|
|
- [Google Research "how developers search for code"](https://research.google.com/pubs/pub43835.html)
|
|
- [A Systematic Review of Productivity Factors in Software Development](https://arxiv.org/abs/1801.06475)
|
|
- [L. Hatton: The Chimera of Software Quality](https://pdfs.semanticscholar.org/03e0/a475e5c2e39fd1f834acc4fbf5fee49467e3.pdf)
|
|
|
|
#### 2. Rond Samenwerking & Begeleiding
|
|
|
|
- [Complex group decision making in agile projets](https://ieeexplore.ieee.org/document/7958489/)
|
|
- [Non-technical individual skills are weakly connected to the maturity of agile practices
|
|
](https://www.sciencedirect.com/science/article/pii/S0950584918300223)
|
|
- [Group developmental psychology and software development performance](https://www.gu.se/english/research/publication/?publicationId=262631)
|
|
- [The Big Effects of Short-term Efforts: Mentorship and Code Integration in Open Source Scientific Software](https://openresearchsoftware.metajnl.com/articles/10.5334/jors.bc/)
|
|
- [A Mentorship Framework for Work Integrated Learning in Software Development](https://link.springer.com/chapter/10.1007/978-94-017-9115-1_26)
|
|
|
|
#### 3. Rond Pragmatiek
|
|
|
|
- [On the relation between unit testing and code quality](https://www.gu.se/english/research/publication/?publicationId=262633)
|
|
- [Pragmatic software engineering for computational science](https://www.researchgate.net/publication/291754462_Pragmatic_software_engineering_for_computational_science)
|
|
- [The Research-practice gap](https://www.jnd.org/dn.mss/the_research-practice_gap_1.html)
|
|
- [Over-engineering enterprise architecture and business competitiveness](https://www.infosys.com/consulting/architecture-services/white-papers/Documents/engineering-enterprise-architecture.pdf)
|
|
- [Learning research](https://www.esrale.org/): 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](https://link.springer.com/article/10.1007/s10009-002-0083-4)
|
|
|
|
#### 4. Rond Software ontwikkeling als organisch proces
|
|
|
|
- [Theorizing about software development practices](https://www.sciencedirect.com/science/article/pii/S0167642314005449#fg0010)
|
|
- [Lucas Gren's Ph.D. research rond agile software engineering](https://www.gu.se/english/about_the_university/staff/?languageId=100001&userId=xgrelu&userName=Lucas%20Gren)
|
|
|
|
#### 5. Rond Creativiteit
|
|
|
|
- [Creativity research: implications for teaching, learning and thinking](https://www.emeraldinsight.com/doi/abs/10.1108/00907320010359623)
|
|
- [The cognitive neuroscience of creativity](https://link.springer.com/article/10.3758/BF03196731)
|
|
- [Assessing the Work Environment for Creativity](https://journals.aom.org/doi/abs/10.5465/256995)
|
|
- [How Would You Move Mount Fuji?: How the World's Smartest Companies Select the Most Creative Thinkers](https://books.google.co.uk/books/about/How_Would_You_Move_Mount_Fuji.html?id=9yzUtgAACAAJ&redir_esc=y)
|
|
|
|
|
|
|
|
[^1]: De woorden 'programmeur', 'ontwikkelaar', en 'software ingenieur' worden hier door elkaar gebruikt, ondanks hun wezenlijke verschillen.
|
|
[^2]: Dit is een afgeleide uit eigen ervaring en moet onderzocht worden.
|
|
[^3]: 1% is het subjectief aangenomen absoluut minimum.
|
|
[^4]: Zie ook het [PREFER Project](http://preferproject.eu/): _Professional Roles and Employability of Future EngineeRs_. |