🚀 go-pugleaf

Pieter Philippaerts <Pieter@mentalis.org> wrote:
>> 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...

Je hebt gelijk, dat was iemand anders. Mijn excuses.

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

De voornaamste design decision van Linus was om niet veel te designen
op voorhand. En dat is ook wat ik het produktiefst vind.

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

Ja, maar wel tijdens dat ze aan het project aan het werken waren en
niet _ervoor_.

Ik heb niets tegen op voorhand eens deftig nadenken waaraan je
wil beginnen. Als jij dat design noemt is ons meningsverschil terug
te brengen tot een verschillend gebruik van terminologie. Met designen
bedoel ik een min of meer formeel proces waarbij er van uit gegaan
wordt dat alle beslissingen op voorhand genomen worden zodat de
implementantie triviaal wordt. Het is die instelling die ik verwerp.

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

In een commerciele opdracht wordt er meer van uitgegaan dat de programmeur
op ieder moment vervangbaar is/moet zijn. En dus nadruk op scherp
afgelijnde, gedocumenteerde API's op voorhand etc... Dat is bij
een niet-commercieel project niet zo. Je merkt dan ook dat in de
free software wereld interne documentatie ofwel onbestaande is,
ofwel achteraf geschreven wordt. Ik heb daar geen problemen mee,
maar het is een feit dat het anders is.

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

Dat je denkt de discussie te kunnen winnen door mijn woorden te
ridiculiseren zegt meer over jou dan over mij. Je kan natuurlijk
gewoon de link lezen die ik in ter ondersteuning meegaf over wat
een ontwikkelingscultuur nu juist inhoudt en hoe verandering
daarvan een impact had op de efficientie van de ontwikkelaars
van windows 2000.

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

Daar komt mijn standpunt inderdaad op neer, in acht genomen hoe ik
design definieer.

Volgens mij omschrijf jij design gewoon veel breder dan ik dat doe
en dan kan ik je wel volgen.

cu bart

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