🚀 go-pugleaf

Pieter Philippaerts <Pieter@mentalis.org> wrote:
> Zo, dan moet je er maar eens enkele opnoemen... Als je aan een groot project
> begint zonder voorafgaand er eens deftig over na te denken en een structuur
> uit te bouwen loop je sowieso ergens vast en ga je grote delen moeten
> herschrijven (wat te vermijden is, natuurlijk).

Kijk, als je design reduceert tot 'er eens over nadenken'. Natuurlijk,
ik denk constant na over de dingen die ik ga programmeren. En ik
stop trouwens niet met nadenken een keer ik bezig ben.

Maar dat is niet meer te vergelijken met de design die je eerst
beschreef als een faze die 'langer duurt dan het programmeren zelf'.
Dan krijg ik inderdaad rose-achtige overengeneer nachtmerries.

>> Bv KDE en de linux kernel zijn voorbeelden waarbij design
>> en programmatie elkaar continu afwisselen.
> Maar er was dus wel degelijk een design! Het is evident dat je niet de ganse

Zowel bij KDE als bij de linux kernel was er slechts een ruw idee
van wat Linus wilde bereiken. Lees de befaamde Tanenbaum-Linus thread
erop na. Het verwijt was juist dat Linux amateuristisch was opgevat
en alle 'design' principes met de voeten trad. De eerste publieke
release van Linux kwam er na enkele maanden stevig doorwerken.
Ondetussen zijn ze al bijna goed 10 jaar met vele honderden om eraan
te programmeren. Veel tijd nam die design fase dus niet in beslag.

KDE is begonnen met een oproep in een paar newsgroupen en mensen die
zijn gaan brainstormen op een mailing list. Van de oorspronkelijke
'design' is nog slechts het doel overgebleven. KParts, een essentieel
-en succesvol- onderdeel van het framework, en dus een uitstekende
kandidaat voor zwaar designwerk, is ontstaan op 1 weekend, eerste
implementatie inbegrepen.

Gnome is ook zo begonnen en in het begin evolueerde het dan ook razend-
snel. Tot bepaalde mensen alleen nog maar aan het designen van nog
coolere dingen dachten en de zaak meer achteruit ging dan vooruit.
Ik dacht dat ze met Gnome 2.0 eindelijk terug wat voorang begonnen
te geven aan implementatie.

>> Natuurlijk moet je afspraken maken, maar als het uitzetten van de
>> krijtlijnen meer dan een beetje tijd inneemt wil dat zeggen dat er
>> iets grondigs mis is.
> Zo, dan moet jij me eens uitleggen hoe je een team van bijvoorbeeld 5000
> mensen (Windows2000 project) in vijf minuutjes kan uitleggen hoe ze code
> moeten schrijven die perfect met elkaar werkt. Ik ben ge�nteresseerd.

Grappig dat je net dat voorbeeld vermeldt. Gezien het hier om een
commerciele ontwikkeling ging was er uiteraard wat meer design en
review mee gemoeid. Maar het belangrijkste element om een team
van xxx programmeurs draaiende te houden is niet een rigiede,
voorafgemaakt design, maar een ontwikkelings-cultuur aangepast
aan het project en de programmeurs.

De belangrijkste hinderpalen in het development proces van Windows 3.51 
lagen in het totaal niet schaleerbaar zijn van hun build en test proces,
het belangrijkste design principe om dat beheersbaar te maken is
het onafhankelijk maken van onderdelen van elkaar. Kortom _minder_
design ipv _meer_. 

(Je hoeft het allemaal niet op mijn woord te neman:
http://www.usenix.org/events/usenix-win2000/invitedtalks/lucovsky_html)

Mijn standpunt kort samengevat : 
design tijdens implementatie : hoe meer hoe liever; voorafgaandelijke
design : hoe minder hoe beter.

cu bart

-- 
attp://www.irule.be/bvh/