[python-nl] crash-driven-development

Anton Vredegoor anton.vredegoor at gmail.com
Sun Sep 30 15:53:10 CEST 2012


On Sat, 29 Sep 2012 18:45:09 +0200
Marcel van den Elst <info at marutec.nl> wrote:

> De link tussen knuffelen door bedrijven en vrijdagavond en testcases 
> snap ik niet, maar ik sluit me van harte aan bij de gedachtengang
> over tests:

Het doet me plezier dat je tenminste een deel van mijn redenering hebt
kunnen volgen.
 
> Test *driven* development veronderstelt veel up-front knowledge over
> het probleem en de oplossing, en kan als te dogmatisch uitgevoerd
> snel leiden tot tunnelvisie en moeilijker afstappen van slechte
> ideeën of implementaties (want daar heb je dan al zoveel tests voor
> gemaakt...)

Er zitten ook wel goede kanten aan het schrijven van tests, in zoverre
men het gebruikt om verschillende betekenisvolle deeltaken van een
probleem op te lossen. Indien men dan alle subtaken die nodig zijn in
principe werkend heeft rest enkel nog ze tot een geheel samen te voegen.

Maar hier is nu precies waar het probleem om de hoek kan komen kijken
omdat men in een systeem zit dat verlangt dat men indicaties geeft over
de voortgang van een project. Maar dat veronderstelt dat men het
uiteindelijke bouwsel immers al in gedachten heeft anders is men immers
niet serieus bezig. Het kan echter zeer gemakkelijk voorkomen dat
bepaalde onderdelen, of liever gezegd het gebrek daaraan, het
noodzakelijk maken via een andere route te gaan, wat weer tot gevolg
kan hebben dat de totaaloplossing er heel anders uit gaat zien.

Dat neemt niet weg dat tegen de tijd dat men dingen op git wil zetten,
het wel prettig is als daar ook een serie testjes bijzitten die de
gebruikte functionaliteit illustreren.

> Ben zelf groot voorstander van wat ik crash-driven-development noem: 
> rapid prototyping, en voor dat wat moet blijven maar stuk blijkt te 
> zijn/gaan tests schrijven.

Het is jammer dat je er een naam voor gekozen hebt met een onprettige
associatie en ook dat nu de discussie onder die titel wordt voortgezet.
Ik heb zelf een voorkeur voor de term "Gestalt Driven Programming", om
aan te geven dat hier het geheel belangrijker is dan de delen, maar dat
zal wellicht bij velen associaties oproepen aan ouderwetse Duitse
psychoanalytische theorie.

> Er zal een stuk ideologieverschil in zitten en wellicht gaat de
> vlieger niet op in corporate omgevingen, maar het werkt wel erg
> prettig voor dingen waarvan je tevoren minder goed weet wat wel/niet
> werkt.

Goed dat je dit noemt, want ondanks dat ik al een tijdje probeer te
formuleren wat mij tegenstaat aan TDD haalde ik veel inspiratie uit dit
artikel uit de corporate omgeving:

http://www.paulgraham.com/growth.html

"""
What this means is that at any given time, the great majority of
startups will be working on something that's never going to go
anywhere, and yet glorifying their doomed efforts with the grandiose
title of "startup." 
"""

Ondanks dit ietwat negatieve citaat  denk ik toch dat het hier
aangeduide effect: dat de meeste activiteiten zinloos zijn maar dat dat
weer goed gemaakt wordt door die ene keer dat het gigantisch goed gaat,
ook opgaat voor programmeerwerk door individuen of kleine groepen
programmeurs.

Wellicht is het een probleem dat deze denkwijze als te ambitieus wordt
geacht voor eenvoudige programmeurs, ik sluit niet uit dat een
dergelijke mindset in een corporate omgeving belemmerend kan werken.

Een ander probleem wat ik zie in de vertaling van Graham's idee naar
het niveau van het individu of naar een kleine groep is dat hier de
mogelijkheid tot samenwerking en uitwisseling van ideeën veel
belangrijker is.

A.






More information about the Python-nl mailing list