noemde bij het kerstdiner nog een software kwaliteit, namelijk terugleesbaarheid.
Ik ben het helemaal met de beste man eens. Deels is dat het gevolg van de 'rat race' om altijd snel te moeten zijn (deel markt, deels omdat de 'omgeving' snel verandert) deels is het botweg onkunde - en dat begint vaak al bij de opzet en vervolgens doorborduren op ellende.
Toch is er niks mis mee om zo nu en dan zelf eens de weg naar Rome te zoeken. Immers, als je nooit buiten de gebaande paden komt, dan kom je ook nooit verder dan 'het gemiddelde'. Toch is het daarbij belangrijk om het doel niet uit het oog te verliezen. Als 'iets nieuws proberen' het doel is: vooral proberen. Waarschijnlijk ga je op je m**l, maar je hebt een hoop geleerd en wellicht vind je een prima bruikbare weg.
Als de bestaande wegen het niet doen zoals voor jou noodzakelijk: vooral doen. Met de bestaande wegen kom je er blijkbaar niet.
Als je een stuk productie software uit de grond moet stampen waarbij 'de rest' al uitdaging genoeg biedt, dan pak je waar je dat kunt de gebaande weg.
zelf in assembly schrijven van een compleet OS
Timer interrupts zijn niet voorbehouden aan een OS. Daarnaast... assembly doe ik een hele enkele keer nog - en dan met een specifieke reden (doorgaans volkomen controle over de timing). Maar meestal is het gewoon C.
Onderhoudbaarheid is een van de belangrijkste aspecten van software implementatie
Doorgaans wel. Toch ontkom je niet altijd aan een stukje 'write-only' code. Doorgaans is dat performance en een enkele keer memory (8052, wat 'custom made' processortjes waar ik mee gewerkt heb) gerelateerd. De 'way to go' is doorgaans de 'interface' waterdicht documenteren en er voor zorgen dat dat stukje code gewoon werkt zonder rare bugs (ofwel: voorkom dat een ander er nog eens in moet duiken). Doorgaans is het compact en niet overdreven complex, beiden zijn dan goed te doen. (dat is een hoop 'doorgaans'
Ja, er zijn altijd situaties te verzinnen waarin het nou net niet op gaat. Verzin wat moois!).
De spreuk die me altijd is bijgebleven: Als architecten zouden bouwen als programmeurs, dan zou een enkele specht hele steden kunnen verwoesten.
De oorzaak zit doorgaans in het alleen maar 'functioneel' denken en vergeten dat er ook wel eens exceptions optreden. Bij de meeste projecten lijkt het al uitdagend genoeg te zijn om het functioneel een soort van werkend te krijgen. 'Robuust' is meestal een brug te ver.
Het kan overigens wel. Ik heb (had, ik doe het niet veel meer) eigenlijk in vrijwel alles wat ik gemaakt heb met 24/7 te maken: stilstand kost geld. Fouten in 'output' trouwens ook. En je wordt ervoor gebeld - volgens Murphy is dat altijd 's nachts. Je leert het snel af 