🚀 go-pugleaf

Jaap Beetstra wrote:

> John Bokma wrote:
>> Jaap Beetstra wrote:
> 
>> Maar dan moet je de rest allemaal inpassen op wat reeds
>> geimplementeerd was.
> 
> Yep, geen probleem als je ontwerp goed is.

Dat kan niet goed zijn, want men is al begonnen met programmeren zonder dat 
de ontwerpfase afgerond is (begreep ik uit je eerdere posting).

> Zo niet: tijd om te refactoren. 

En loop je het risico dat er te veel tijd in het refactoren gaat zitten.

Ikzelf ga voor een minimalistische maar goede ontwerpfase. Uit ervaring 
weet ik dat ff ontwerpen, dan beginnen, en tijdens het code kloppen je 
ontwerp bijwerken niet fantastisch werkt.

>> Daarnaast, feedback is nogal lastig als er een
>> brokje af is (en het nog on the fly verzonnen is ook).
> 
> Tsja, das nou eenmaal vrij essentieel aan feedback: je krijgt het
> alleen over werk dat al gedaan is (anders was het feed-forward :-).
> Gelukkig is goed ontworpen software flexibel,

Ik heb dat nog nooit gezien, flexibele software. Altijd als je iets wilt 
wat er net niet inzit kan je of de boel omgooien, of een wrapper schrijven.

> en kun je nog voldoende bijschaven. 

Te vaak: terug naar de ontwerptafel gezien. Kijk b.v. maar eens naar de 
Java classes over de loop van de tijd. (Date class, Swing, enz). Als het zo 
simpel was was er wel 1 mega library geport naar elke programmeertaal.

>>> kon je het ontwerp bijwerken (aka refactoren), en de
>>> vervolgstappen in het project baseren op een juist ontwerp.
>>
>> Aangezien je geen idee hebt van wat het juiste ontwerp is (want dat
>> wordt on the fly verzonnen)....
> 
> En je weet wel wat 'het' juiste ontwerp is als je er zonder feedback
> een paar maanden over nadenkt?

Uit ervaring (21+ jaar) werkt eerst goed nadenken beter dan: laten we maar 
beginnen, we zien wel waar we stranden. In het laatste geval wordt er te 
vaak van alles bijverzonnen omdat de programmeur het een coole feature vind 
(of de manager). 

>>> Het prettige aan een iteratief proces vind ik dus dat je er sneller
>>> achter komt of ontwerp-beslissingen al-dan-niet goed uitpakken.
>>
>> Dat kan alleen als er een ontwerp-fase aan vooraf ging.
> 
> `Het` juiste ontwerp bestaat voor mij niet (slechte ontwerpen bestaan
> wel).

Het juiste ontwerp is er een die minimaal gezeur geeft, en bestaat dus wel 
degelijk. Een ontwerp is altijd beperkt tot de mogelijkheden. Dat er 
achteraf een beter is, tja, dat is normaal.

> Terwijl ik bezig ben met het ontwikkelen van de software, krijg
> ik meer inzicht in de wensen/doelen/omstandigheden van de klant,

Die wensen probeer ik altijd van te voren op papier te krijgen. Desnoods 
met schetsen en een prototype. Ik moet er niet aan denken dat ik tijdens 
het ontwikkelen een opdrachtgever heb die mij telkens gaat zitten bijsturen 
op van alles, of "John, kan dat 7 pixels naar rechts en in het rood?". Een 
GUI kan al gemaakt worden aan het begin, en daar hoef je nauwelijks voor te 
programmeren.

> en
> krijg ik een beter beeld van hoe de onderdelen van de software samen
> kunnen werken. Op basis daarvan stel ik het ontwerp steeds bij.

Ik moet er niet aan denken zo te moeten werken.

> Een ontwerp _fase_ is mij te abstract. Ontwerpen is voor mij een
> continu proces, gestuurd door concrete wensen.

Het grootste deel van die concrete wensen zijn van te voren al te krijgen.

> Dat zijn zowel
> functionele wensen [emailtje naar klant als event zus-en-zo optreedt],
> als meer beheersmatige wensen [mail-adres klant makkelijk te
> configureren], als meer technische wensen [geen afhankelijkheid
> specifieke database-server].

Die dingen kan je al verzinnen voor je een bit programmeerd. Ik moet er 
niet aan denken dat ik achteraf nog eventjes een "voer adres klant in" 
schermpje moet maken, omdat ik daar niet aan gedacht heb.

> Het best inzicht in al deze wensen heb ik
> op het moment dat ik met dat specifieke stukje functionaliteit bezig
> ben. 

En dat is naar mijn mening dus fout. Juist bovengenoemde zaken kan je *van 
te voren* bepalen.

> Dat betekent natuurlijk niet dat je als een idioot gaat zitten
> code-kloppen.

Zo klinkt het wel.

> Een halve dag naar het scherm turen en nadenken over een
> paar regels is geen uitzondering.

Ik doe dat liever niet achter het scherm, omdat dat dan roept om 
programmeren. Ik ga expres ergens anders zitten, met pen en papier :-D.

> Vaak is die tijd nog nuttig besteed ook.

Indien van te voren en zonder computer nog beter, is mijn jarenlange 
ervaring.

> Maar een week of langer op papier zitten te frobelen helpt mij
> niet. 

Wellicht omdat je dat zo aanvoelt, maar dat wil niet zeggen dat het waar 
is. Die week of langer op papier zitten frobelen kan jou ook misschien wel 
weken turen besparen. Achter het toetsenbord (is mijn ervaring) ga je vlug 
ff proberen.

> Maar dat kan voor jou anders liggen natuurlijk.

Ik gok dat ik geen uitzondering ben. Ja, ik weet dat programmeurs een hekel 
hebben aan de papierfase, ik ook. En het lijkt zo onproduktief, want je 
maakt geen regel code. Maar nogmaals, mijn ervaring, het bespaard. En 
aangezien ik fixed price voor mijzelf werk, heb ik daar onderzoek naar 
gedaan :-D En zelfs scripts van honderd regels komen vaak tot stand na wat 
op papier te krabbelen, al is het maar een uurtje.

>> In de bouw begint men ook direct met stenen metselen, want zo zien de
>> kopers tenminste direct wat voor kleur de buitenmuur wordt, en kunnen
>> ze alvast de kleur van hun naambordje en auto daarop afstemmen.
> 
> Een huis bouwen is het uitvoeren van een herhaalbaar proces.

Onzin. Kijk maar eens naar de fouten die er in de bouw gemaakt worden. 
Daarnaast worden er regelmatig nieuwe ontwerpen gemaakt, en nieuw 
bouwmateriaal gebruikt. Daarnaast spelen er nog vreselijk veel andere 
factoren (grond, weer, enz). 

> Programmeren is het definieren van een herhaalbaar proces. (vrij naar 
> http://c2.com/cgi/wiki?ProgrammingAintManufacturing ).

Geen zin om te kijken, maar als je jouw vrije quote daar uit kan halen is 
dat dus onzin. Bij veel produktieprocessen worden regelmatig nieuwe dingen 
geintroduceerd, en dus nieuwe fouten gemaakt. Het enige verschil is dat een 
auto, huis, e.d. niet op een binaire waarde hangt. Het grote verschil 
tussen software en materie.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html