thesis voorstel added

content/essays/over-entropie.md

@@ -0,0 +1,50 @@
+---
+title: 'Over entropie'
+date: '2018-05-18'
+subtitle: Hoe gaan wij om met chaos?
+published: false
+---
+
+Filosofie kan gezien worden als een __poging__ om __dingen__ rondom de mensheid te definiëren. Ik noem het een __poging__, en geen manier, omdat we al duizenden jaren kritiek aan het geven zijn op elkaars definities. Ik noem het __dingen__, en niet zichtbare dingen, omdat juist ongrijpbare dingen ons zo sterk intrigeren dat we ook de nood voelen om daar een theoretische vorm aan te koppelen. 
+
+Ons bewustzijn produceert veel prachtige wetenschapstakken maar ook veel angsten. Dé grootste angst van de mensheid moet dan wel een doodsangst voor chaos zijn. Welke pogingen ondernemen wij dagelijks om die chaos in te tomen:
+
+* Het gras moet afgemaaid zijn. De tuin moet er immers netjes bij liggen. Mails moeten weggewerkt worden. De afwas moet gedaan zijn. De keuken moet er immers ook netjes bij liggen. (**Wegwerken**)
+* Boeken horen in de boekenkast. Auto's horen in de parking. Liefst mooi in een rijtje, in een op voorhand opgelegde manier "gesorteerd". (**Groeperen**)
+* Pijn hoort benoemd te worden ("het zal wel buikpijn zijn, waarschijnlijk van die vis van gisteren"). De aanwezigheid van objecten en mensen in een bepaalde omgeving moet een plaats gegeven worden. ("Het is normaal dat deze persoon bij ons in de straat komt rond deze tijd, het is de postbode.") (**Verklaren**)
+
+Als er aan één of meer van deze voorwaarden niet voldaan wordt stijt onze stress waarde onverbiddelijk. Om met de grote hoeveelheid aan onzekerheid te kunnen leven verzonnen wij manieren om hier mee om te gaan: onzekerheid wegwerken, onzekerheid groeperen en vooral: onzekerheid verklaren. Deze voorwaarden zijn allemaal varianten van **controle**.
+
+### Onzekerheid wegwerken en groeperen
+
+Veel dingen groeperen onder één gezamelijke noemer geeft minder dingen om mee om te gaan. Wegwerken en groeperen is daarom hetzelfde. Vuile was laten rondslingeren in de slaapkamer, in de sofa en op de keukenkast geeft meer prikkels dan vuile was op één plaats: de linnenmand. [Cognitieve overload](https://en.wikipedia.org/wiki/Cognitive_load) treedt op wanneer ons brein met te veel tegelijkertijd te maken krijgt. Dit is wetenschappelijk (empirisch) bewezen en neem ik aan voor waar, niet alleen omdat het voor mijzelf geldt, maar omdat het eenvoudig te extrapoleren is naar iedereen. Wat dan met adrenaline junkies? Onbewuste prikkels zijn ook prikkels: niemand is bezig met zijn boodschappenlijstje, e-mails en aandelen tijdens een vrije val. 
+
+Een opgeruimd huis betekent ook een opgeruimd innerlijk. "Meer controle over je leven? Begin met opruimen!" luidt een slogan over schoonmaken. Dit kunnen we veralgemenen naar de volgende stelling:
+
+> Een opgeruimde buitenwereld betekent ook een opgeruimde innerlijke wereld.
+
+Mattheüs 23:26 draait de stelling echter om: <em>"Gij blinde Farizeer, reinig eerst wat binnen in den drinkbeker en den schotel is, opdat ook het buitenste derzelve rein worde"</em>. En daar kan ik wel reden in vinden, net als vele Stoïcijnen. De onzekerheid die we zo neurotisch willen wegwerken is immers slechts een schaduw van ons eigen bewustzijn. Meer hierover later in onzekerheid laten voor wat het is.
+
+
+### Onzekerheid verklaren
+
+
+### Onzekerheid laten voor wat het is
+
+In een poging de nood tot controle los te laten kunnen we ook gewoon meer open staan voor onzekerheid in ons leven. In plaats van ons op een bepaalde manier te kleden omdat we reacties vrezen van anderen, kunnen we ook gewoon onze schouders ophalen. 
+
+#### Minder wegwerken en groeperen
+
+> Een opgeruimde innerlijke wereld vermindert de stress van een onopgeruimde buitenwereld.
+
+Hoe goed ik ook mijn best doe, het zal me nooit lukken om "een opgeruimde innerlijke wereld is een opgeruimde buitenwereld" naar waarde te kunnen schatten. De rommel van de buitenwereld blijft bestaan, ik stoor me er gewoon minder aan. 
+
+Tot op welke hoogte moeten we ons minder storen aan rommel? De balans opzoeken tussen opruimen en onopgeruimd laten is moeilijk en vooral ook subjectief. De neuroot in ons gaat 
+
+#### Minder verklaren
+
+In hoeverre is verklaren hetzelfde als oordelen? Een oordeel vellen gebeurt zo snel dat we het zelf bijna nooit door hebben. Systeem 1 (het snelle, onderbewuste, primitieve brein) van Daniel Kahneman oordeelt in minder dan één oogwenk gebaseerd op een complex aantal parameters waarvan zowel huidige zintuigen als voorgaande geregistreerde gebeurtenissen deel uitmaken. Het goede nieuws is dat we blijkbaar wel in staat kunnen zijn om dit (gedeeltelijk) te overschrijven met Systeem 2 (het trage, beredenerende brein), voordat het gevolg van de handelingen van systeem 1 de volledige greep krijgt over ons bewustzijn. 
+
+> Doe je oordeel weg, en weg is je gevoel, "ik ben benadeeld". - Marcus Aurelius
+
+De Stoïcijnce (verklaring van) oordelen zoekt het in het innerlijke, en niet in de wereld rondom ons. Waarom willen we een onbekende persoon die mogelijks als "dreigend" gezien kan worden door Systeem 1 onmiddellijk kunnen classificeren door te proberen verklaren waarom deze persoon in onze nabijheid is? Om het aantal onbekende variabelen te kunnen reduceren en ons stress niveau te laten zakken. De makkelijkste verklaring is een verklaring buiten onszelf. Die chauffeur rijdt slecht "want het is een Johnny". Criteria? Volkswagen, petje, zonnebril. Die chauffeur rijdt slecht "want het is weer een vrouw". Doe je oordeel weg, en wet is je gevoel, ik ben benadeeld. 

content/proposal.md

@@ -0,0 +1,206 @@
+---
+title: Ph.D. Thesis voorstel
+---
+
+## Het onderwerp
+
+> 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. 
+
+Dat 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. 
+
+<center>
+    <img src="/img/sweng_prob.png">
+</center>
+
+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?_
+
+Vandaar dat ik bovenstaande vraag wil ombuigen naar een doctoraatsvoorstel:
+
+> **The industrial requirements of a modern software engineer.**
+
+De woorden in de titel verklarend:
+
+1. **Industrial**: Ik wil het hebben over software die in de industrie gemaakt wordt, waar ik altijd een deel van heb uitgemaakt. Het moet concreet toepasbaar zijn. Ik wil nauw samenwerken met bedrijven, niet enkel met een onderwijsinstelling.
+2. **Requirements**: de link naar wat ontwikkelteams en developers missen, de vraag waaruit ik ben vertrokken.
+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.
+4. **Software engineer**: met een insteek vanuit de _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. 
+
+## De inhoud
+
+Wat valt er allemaal onder die zogenaamde vereisten? Ik wil fundamenteel onderzoek verrichten naar verschillende vereisten die allemaal één ding gemeen hebben, namelijk het bovenstaand onderwerp. Als we terugdenken aan de vraag "wat missen we", onderscheiden we[^2] een aantal belangrijke **subonderwerpen**.
+
+De rode draad doorheen de subonderwerpen, **de context**, is van groot belang! "Samenwerking" en "creativiteit" kan in een volledig ander daglicht gesteld worden als we niet spreken over software ingenieurs maar bijvoorbeeld maatschappelijk werk. Dat neemt niet weg dat principes uiteraard overlappen. 
+
+#### 1. Productiviteit
+
+Productiviteit manifesteert zich op twee manieren binnen software ontwikkeling:
+
+1. In het beheren van _tools_. Shortcuts vanbuiten kennen van uw geliefde IDE.
+2. In het _metafysische_. Strategiëen voor het overwinnen van afleiding.  
+
+Het is verbazingwekkend hoeveel ontwikkelaars nog steeds niet blind kunnen typen. 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. 
+
+#### 2. Samenwerking & Coördinatie
+
+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 worden "samen" en "werken" feitelijk betekenen als ze in één woord gebruikt worden. Bijgevolg kunnen wij niet verwachten dat dit in teams vanzelf goed komt. 
+
+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.
+
+#### 3. Begeleiding
+
+Een gebrek aan een goed _mentor model_ kan vreselijke gevolgen hebben voor de continuïteit van een software project. Begeleiding is van crutiaal belang om op dezelfde golflengte te zitten met een minimale inspanning. 
+
+Hoe leer ik iemand iets bij?[^3] Hoe presenteer ik mijn bevindingen? Hoe overwin ik weigerachtige houdingen van collega's om open te staan voor nieuwe ideeën? 
+
+#### 4. 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 gestandardiseerd moet worden.
+
+#### 5. Leren leren
+
+<center>
+    <img src="/img/frameworks.jpg">
+</center>
+
+De focus leggen op het _concept_ in plaats van het _framework_ is 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? 
+
+Een ander aspect van het "hoe" van het leren is in de juiste stemming geraken. 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).
+
+
+#### 6. Software ontwikkeling: 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".
+
+<center>
+    <img src="/img/wtfm.jpg"/>
+</center>
+
+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? 
+
+#### 7. 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 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? 
+
+## 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.
+
+<img src="/img/agile.png"/>
+
+
+## De toepasbaarheid
+
+Een industriëel getint onderzoek zonder directe toepasbaarheid voelt maar slap aan. Als we kijken naar de evolutie van tools, technieken en praktijken in de software industrie is het des te belangrijk dat iets zo snel mogelijk concrete resultaten oplevert. 
+
+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.
+
+### A. In de industrie
+
+Academisch onderzoek is leuk voor de industrie gegeven de (technische) gerichtheid van het onderwerp. Desondanks de absractere insteek van het voorstel mik ik op de volgende toepasbaarheid binnen bedrijven:
+
+#### 1. Als **concreet** smeermiddel voor teams
+
+Het resultaat van onderzoek naar de bovenstaande subonderwerpen kan concreet ingezet worden in ontwikkelteams, gegeven de flexibele manier waarop deze thesis tot stand kan komen. 
+
+Onderzoek rond productiviteit kan bijvoorbeeld direct geïntroduceerd worden en een kostenreductie van 1+% betekenen. Die introductie gaat uiteraard meer werk zijn dan enkel het resultaat van dit werk voordragen: dat is nog maar het begin.
+
+#### 2. Als leidraad voor een **Groeimodel**
+
+Als we de vraag waaruit ik ben vertrokken kunnen beantwoorden, kunnen we ook onze (sprekend vanuit mijn standpunt als werknemer van Prato) 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". 
+
+Zie ook het [PREFER Project](http://preferproject.eu/): _Professional Roles and Employability of Future EngineeRs_.
+
+#### 3. Als leidraad voor het **Selectieproces**
+
+Als we de vraag waaruit ik ben vertrokken kunnen beantwoorden, kunnen we ook de aanwerving van nieuwe ontwikkelaars hierop afstemmen. Het subjectief buikgevoel of algehele gebrek aan uniforme testen wordt vervangen door een heldere blik op de vereisten van een moderne ingenieur. 
+
+### B. Didactiek
+
+#### 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):
+
+> **LEUVEN ENGINEERING & SCIENCE EDUCATION CENTER** - A community of researchers and practicioners contributing to the advancement of education in the Science, Engineering & Technology group.<br/>
+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:
+
+#### 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)
+
+#### 2. Rond Samenwerking
+
+- [Complex group decision making in agile projets](https://ieeexplore.ieee.org/document/7958489/)
+
+#### 3. Rond Begeleiding
+
+#### 4. Rond Pragmatiek
+
+#### 5. Rond Leren leren
+
+- [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 etc
+
+#### 6. Rond Software ontwikkeling als organisch proces
+
+- [Theorizing about software development practices](https://www.sciencedirect.com/science/article/pii/S0167642314005449#fg0010)
+
+#### 7. 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)
+
+&nbsp;
+
+[^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]: In context van concrete software ontwikkeling natuurlijk.