Zo af en toe mag ik ook eens docenten introduceren in de wondere wereld van 'free open source software (foss)'. Ik ben dan altijd erg geïnteresseerd in de vakken die zij geven en hoe zij dit doen en met welke middelen. Wat me erg verbaast is dat algemeen foss niet of heel erg weinig gebruik wordt in het onderwijs. Ik denk dat dit voor de programmeervakken een behoorlijk gemis is.
Iemand die software schrijft moet je vooral geen programmeur noemen. Dit is tegenwoordig een belediging. Men noemt zichzelf een 'software engineer' en gelijk hebben ze. Alhoewel er nog geen exacte definitie is van de 'software engineer' gaat men ervan uit dat een 'software engineer' zich bezig houdt met het ontwerpen, ontwikkelen, testen en evalueren van de software. Een 'software engineer' doet dus veel meer dan alleen programmeren.
De meeste mbo, hbo en wo ict-opleidingen bieden één of meerdere vakken omtrent het vakgebied 'software engineering'. In dit vakgebied gaat het over het algemeen om het ontwerpen, implementeren en onderhouden van software. Tijdens één of meerdere vakken leer je een programmeertaal (meestal Java of .Net), wat ontwikkeltools te gebruiken (IDE's ), wat ontwikkelmethodieken toe te passen (bijvoorbeeld agile development ) en moet je projectmatig werken (bijvoorbeeld volgens Prince2 ). Algemeen begint men dan vanaf 'scratch' (zonder bestaande code of met alleen een skelet) een softwareproduct te bouwen en dit heeft naar mijn mening een aantal beperkingen:
– Het komt in de praktijk nog maar zelden voor dat men vanaf 'scratch' begint. Wanneer je moet voortborduren op bestaande code is het belangrijk dat je andermans code kan begrijpen en dit leer je tijdens je studie alleen op basis van de code van je medestudenten in je projectgroep en daardoor naar mijn mening maar zeer beperkt. Daarnaast wordt er vaak van je verwacht dat je je kan conformeren aan een coding-stijl die door het bedrijf wordt opgelegd. Dit kan een behoorlijke drempel zijn als je gewend bent om alleen maar in de schoolstijl te programmeren.
– Het gebruik van hulpmiddelen zoals revisiebeheer, projectmanagement en debug-tooling wordt als nutteloze overhead ervaren. Dit komt omdat voor kleine projecten de feitelijk uit te voeren werkzaamheden voor het product niet opwegen tegen de administratieve handelingen.
– Beheer van software wordt niet behandeld. Dit omvat het oplossen van bugs, verbeteren van de software ten behoeve van de prestaties en het aanpassen van de software aan nieuwe eisen. Belangrijk hierbij is dat de wijzigingen zonder regressie van het bestaande softwareproduct worden doorgevoerd. Hierbij is testen zeer belangrijk en vooral het testen van de bestaande code. Dit laatste wordt dus niet gedaan.
– Beperkt releasemanagement. Projecten waarin vele wijzigingen worden doorgevoerd en afhankelijk zijn van vele andere componenten vereisen nogal wat beheer rondom het uitgeven van een nieuwe versie. Denk hierbij aan het gebruik van software van derden dat nog in betafase verkeert. Moet je dan je release uitstellen? Of ga je zelf de betasoftware uitgeven? Of vervangen door iets anders? Dit soort kwesties zijn maar beperkt aan de orde wanneer je met kleine groepen werkt aan een relatief klein project dat vooral op zichzelf staat.
Ik kan me dan ook vinden in de kritiek van menig werkgever over het niveau van de opgeleide ict'er. De net afgestudeerden zijn te 'theoretisch' of niet 'streetwise' genoeg. Foss biedt hier dan een mooie kans om bovenstaande beperkingen enigzins te verhelpen. In plaats van telkens vanaf 'scratch' te beginnen, zouden de vakken ook zo ingericht kunnen worden dat ze voortborduren op de resultaten van voorgaande jaren.
Ik begrijp dat dit de inrichting van de curricula een stuk complexer maakt, maar er kan naar mijn mening heel veel inspiratie worden opgedaan bij foss-projecten. Voor de technische kant kan men de infrastructuren van foss-projecten zelfs geheel overnemen aangezien de meeste foss-projecten op hun beurt weer volledig gebruik maken van foss.
Ook kan ik me voorstellen dat het lastig is om een project te verzinnen dat leuk is voor studenten en over meerdere jaren kan worden gebruikt. Ook hier kan foss uitkomst bieden doordat men binnen de opleiding van een of meerdere foss-projecten een branche kan maken en intern kan beheren. Op deze branche kunnen de studenten dan bugs oplossen en nieuwe wensen van gebruikers implementeren. Studenten kunnen dan het hele spelletje van een foss-project naspelen zonder dat ze daarbij moeten deelnemen aan het project. Het zou natuurlijk wel erg mooi zijn als de studenten participeren in foss-projecten, maar ik ben het eens met de kritiek dat dit voor beginnende 'software engineers' wellicht te hoog gegrepen is. Hoewel het voor de studenten extra motiverend kan werken als er de mogelijkheid bestaat dat hun software opgenomen wordt in een foss-project.
“Ook kan ik me voorstellen dat het lastig is om een project te verzinnen dat leuk is voor studenten en over meerdere jaren kan worden gebruikt.”
1. Waarom zou je de scholen projecten laten verzinnen?.
Ik denk dat de studenten van vandaag de dag ZELF intelligent genoeg zijn om met nuttige – en vooral zinnige projecten uit de realiteit te komen als lesmateriaal, studie project.
2. De uitdaging voor “iedereen die zich docent durft te noemen” zit ‘m dan in het STOPPEN MET HERSENSPOELEN VAN ZIJN LEERLINGEN en zichzelf te transformeren naar
– een FACILITATOR voor de benodigde leermiddelen,
– een COACH van de leerlingen naar ZELFSTANDIGHEID,
– OPEN STAAN om zelf ook eens iets hiervan op te steken.
3. De tijden dat de “lera(a)r(es)”, “docent(e)”, “meester(es)” een ware inhoudelijke meester in het vak was, ligt al lang en breed achter ons. Dit word keer op keer bewijzen door vele klachten over de kwaliteit van het (ict) onderwijs vanuit het bedrijfsleven!
Can we change? Yes we can!
Hoog tijd dat dit algemeen maatschappelijk erkend gaat worden, de “leraar”, “docent” van zijn heilige “Pabo troon” afkomt en afdaalt tussen de leerlingen.
Dat de “docent” zichzelf op zijn minst gelijkwaardig!! gaat opstellen aan zijn studenten, of zelfs compleet dienstverlenend aan zijn, haar studenten. Daar leert de docent zelf ook weer van 😉
Weg met de “Pabo en leerbevoegheid”
Iedereen die zelf wil en kennis over kan dragen zou imo een leraar, docent moeten kunnen worden. Weg met dat hele “lesbevoegdheid geleuter”, want als je “lesbevoegdheid” hebt wil nog niet zeggen dat je je vak inhoudelijk snapt! Dit blokkeert “the natural flow of knowlegde fro the open source to the willing students”.
Kijken en doen:
In de vrije natuur leren “mensch en dier” ook door het principe “duidelijk voordoen, succesvol kopieren en een positieve stimulatie” Waarom kan dit principe niet in het onderwijs? Nu worden leerlingen alleen maar dom gehouden.
Open Source is the only way to go:
De Open Source gedachten, community, het principe leent zich daar uitstekend voor. Leren via de broncode van een ander, is “the only way to go” (i.p.v. je hoofd laten storten met nutteloze theorie, zonder enige directe referentie naar de praktijk)
Onderwijs…Het kan anders, het MOET anders:
– Teaching by doing
– Teaching by example
– Training hands-on-keyboard
met n vleugje theorie om de samenhang te kunnen zien!
Rule #1 van de Hacker Ethic:
http://en.wikipedia.org/wiki/Hacker_ethic
“Access to computers—and anything which might teach you something about the way the world works—should be unlimited and total. Always yield to the Hands-On Imperative!”
Wil je zelf meer lezen over de eerste echte open-source ict-leraren? dan is dit boek een must 😉
Steven Levy
“Hackers heroes of the modern computer revolution”
http://www.stevenlevy.com/index.php/other-books/hackers
The only true and authentic way of ict education!.
En dit is een docent informatica???
Een docent informatica die niet weet hoe een boomstructuur in elkaar zit of wat root-rechten zijn…
Op wat voor instelling mag die wel les geven?
– Hans Paijmans (docent informatica).