🚀 go-pugleaf

<Bart.Vanhauwaert@nowhere.be> wrote in message
news:o1ecfa.i1b.ln@ns1.irule.be...
> Kijk, als je design reduceert tot 'er eens over nadenken'.

Ik heb geschreven: "er eens _deftig_ over nadenken". Als je me wil quoten,
doe het dan goed...
Samen met enkele andere mensen ben ik nu al 4 maand aan het nadenken over de
structuur van een project waar we binnenkort aan gaan beginnen te
programmeren; _dat_ is 'deftig nadenken'... (rustig de tijd nemen om zoveel
mogelijk design mogelijkheden af te lopen en de beste eruit te kiezen).

> Maar dat is niet meer te vergelijken met de design die je eerst
> beschreef als een faze die 'langer duurt dan het programmeren zelf'.

Ik heb nooit geschreven dat designen langer moet duren dan het programmeren
zelf... Het ruikt dus weer naar een mis-quote...

> Dan krijg ik inderdaad rose-achtige overengeneer nachtmerries.

Ik heb geen enkel idee vanwaar je die referentie naar Rational Rose haalt...
Ik gebruik dat ding helemaal niet.

> 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.

Oei, ik denk dat je de dingen een beetje begint dooreen te slaan en raad je
dus aan om die thread nog eens te herlezen. Torvalds heeft letterlijk
gezegd: "I'm not making overly many excuses about it though: it was a design
decision, ...". Hij heeft er dus wel degelijk over nagedacht en heeft
tijdens het designen bepaalde beslissingen genomen (die niet compatibel
waren met de idee�n van Tanenbaum, maar dat heeft niets te maken met deze
thread hier).

> 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.

Designs evolueren over de tijd, net zoals de code; denk je dat de design van
WindowsXP nog steeds dezelfde is als die van WindowsNT3.5?

> 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.

Je bedoelt natuurlijk dat op een weekend het design op computer is gezet,
nadat de ontwerpers er eerst al een hele tijd hadden zitten over na te
denken...

> 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.

Dat is niet het punt van een design: "een deftige implementatie maken".
Vandaar dat de bovenstaande gequote tekst op niet veel slaagt...

> > 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.

Zo, dan moet je me toch wel eens uitleggen waarom er een verschil is tussen
het designen van commerci�le en niet-commerci�le software...
[spoiler: er is geen verschil]

> 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.

En wat is een "een ontwikkelings-cultuur aangepast aan het project en de
programmeurs" dan precies? Dat de baas elke dag langskomt om te zeggen dat
ze goed bezig zijn? Dat er een citroengeur door het ventilatie systeem wordt
verspreid om de programmeurs productiever te maken? Ja, zo'n dingen gaan er
duidelijk voor zorgen dat de code van alle programmeurs opeens magisch
beginnen samen te werken...

> 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_.

LOL, heb je de bovenstaande tekst eigenlijk eens nagelezen voordat je hem
verstuurde? Je zegt hier dat het belangrijkste design principe 'geen design'
is.


Mvg,
Pieter Philippaerts