update voorstel na bespreking
This commit is contained in:
wgroeneveld
parent
43ba07bf20
commit
681c63c038
|
|
@ -42,46 +42,51 @@ De rode draad doorheen de subonderwerpen, **de context**, is van groot belang! "
|
|||
|
||||
#### 1. Productiviteit
|
||||
|
||||
Productiviteit manifesteert zich op twee manieren binnen software ontwikkeling:
|
||||
Productiviteit manifesteert zich op drie 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.
|
||||
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.
|
||||
|
||||
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%[^4] kan al voor een flinke besparing op jaarbasis zorgen.
|
||||
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?".
|
||||
|
||||
#### 2. Samenwerking & Coördinatie
|
||||
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.
|
||||
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. Begeleiding
|
||||
|
||||
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 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
|
||||
#### 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.
|
||||
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.
|
||||
|
||||
#### 5. Leren leren
|
||||
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.
|
||||
|
||||
<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?
|
||||
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?
|
||||
|
||||
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).
|
||||
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.
|
||||
|
||||
|
||||
#### 6. Software ontwikkeling: een organisch proces
|
||||
#### 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".
|
||||
|
||||
|
|
@ -93,14 +98,20 @@ De beschrijving van vereisten met de **natuurlijke taal** in code zorgt voor een
|
|||
|
||||
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
|
||||
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 ik 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 als een echte _polyglot_.
|
||||
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?
|
||||
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
|
||||
|
||||
|
|
@ -112,7 +123,6 @@ Dit sluit beter aan met de _agile proces_ dat ook bij Prato gebruikt wordt om sn
|
|||
|
||||
<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.
|
||||
|
|
@ -127,7 +137,7 @@ Academisch onderzoek kan een meerwaarde zijn voor de industrie gegeven de (techn
|
|||
|
||||
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+%[^4] betekenen. Die introductie gaat uiteraard meer werk zijn dan enkel het resultaat van dit werk voordragen: dat is nog maar het begin.
|
||||
Onderzoek rond productiviteit kan bijvoorbeeld direct geïntroduceerd worden en een kostenreductie van 1+%[^3] 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**
|
||||
|
||||
|
|
@ -182,36 +192,30 @@ Dit is de status van het huidig onderzoek in context van mijn voorstel:
|
|||
- [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)
|
||||
|
||||
#### 2. Rond Samenwerking
|
||||
#### 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)
|
||||
|
||||
#### 3. Rond Begeleiding
|
||||
|
||||
- [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)
|
||||
|
||||
#### 4. Rond Pragmatiek
|
||||
#### 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)
|
||||
|
||||
#### 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_ onder andere.
|
||||
- [What makes good research in Software Engineering](https://link.springer.com/article/10.1007/s10009-002-0083-4)
|
||||
|
||||
#### 6. Rond Software ontwikkeling als organisch proces
|
||||
#### 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)
|
||||
|
||||
#### 7. Rond Creativiteit
|
||||
#### 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)
|
||||
|
|
@ -222,5 +226,4 @@ Dit is de status van het huidig onderzoek in context van mijn voorstel:
|
|||
|
||||
[^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.
|
||||
[^4]: 1% is het subjectief aangenomen absoluut minimum.
|
||||
[^3]: 1% is het subjectief aangenomen absoluut minimum.
|
||||
|
|
|
|||
Loading…
Reference in New Issue