[OT] programmeren VS bruggen bouwen

[wasigh]

Zoals een aantal van jullie wel weten loop ik op dit moment stage bij een "kind-of" e-commerce bedrijf. Gister moest de site naar productie en zijn we met 4 man de hele tijd bezig geweest om de fouten eruit te halen. Mensen die gister op IRC waren weten hier alles van

Nadat alles draaide zijn we met het dev-team (1 Pool, 1 Zweed en 2 stagiares ) even de kroeg ingedoken (zoals het hoort )

Even het projct doorspreken en dan vooral de problemen die je tegenkomt bij een dergelijk project zoals code die ineens niet meer werkt. Geen flauw idee hebben of het uberhaupt werk etc.

Maar stel je nou eens voor dat mensen bruggen zou bouwen als programmeurs programma's:

Je krijgt dan bruggen waar mensen doorheen vallen en die dan "gereboot" worden.
Borden met: niet meer als 4 personen tegelijk op de brug

Op vragen of de brug af is: nou van deze kant lijkt het op een brug.

Programmeurs die over de brug lopen, lopen niet aan de rechterkant omdat ze weten dat het daar te zwak is.

Stenen die verdwijnen, waarvan niemand weet waar ze zijn gebleven.

Bij het bouwen wordt er midden in de brug begonnen, en er wordt 5 keer opnieuw begonnen.


Hoewel ik graag zou zeggen dat bedrijven stabiele software maken, weten waar ze bezig zijn, en een goede voorbeeld zijn van hoe het zou moeten. Moet ik helaas toegeven dat het niet zo is...

Maar het draait, het project is afgerond en ik ontken dat ik er iets mee te maken heb

[HenkS]

een brug gaat van de ene naar de andere kant, zijn dus niet veel mogelijkheden mee, zijn vaste berekeningen voor hoe hij gebouwd moet worden enz...


en een programma kan vele kanten op en er zijn dus ook veel meer manieren om fouten te krijgen, maar ja die fouten 'elimineren' is ook puur een kestie van ervaring denk ik.... (en een beetje logisch kunnen denken en gestructureerd bouwen, en eerst denken voor doen!)

[Scorpion]

Op woensdag 19 december 2001 10:08 schreef wasigh het volgende:
Mensen die gister op IRC waren weten hier alles van

Euhm, ik zit altijd op irc, maar wist hier niets van.

[Nielsz]

http://www.bridgebuilder.de/
Dat is gecombineerd

[D2k]

Op woensdag 19 december 2001 10:33 schreef Nielsz het volgende:
http://www.bridgebuilder.de/
Dat is gecombineerd

nee niet weeeeeeer

ik kan me nog een lange nacht herinneren met 5 of 6 man die aan het bruggen bouwen waren ergens in een garage........

[The End]

Hoe meer variabelen in het spel zijn hoe moeilijker het wordt.
Een brug bouwen is een ingewikkeld iets, maar er zijn vaste formules voor... Dus het aantal fouten wat gemaakt kan worden is veel kleiner.
Maaaarrrrrrrr wat gebeurd er als je een brug bouwt terwijl je de formules uitrekent d.m.v. een computerprogramma???

[L_Jinx]

Blijft inderdaad een bekend probleem. Maar ik moet zeggen als je het bouwen van een progamma net zo aanpakt als het bouwen van een brug, dus met een uitgebreid ontwerp enzo, dan wordt het wel minder gepruts.

Je "probleem" komt me in ieder geval erg bekend voor!

[chem]

mja, een brug is toch anders. Een brug is berekenbaar. Een softwareproduct, daar valt weinig aan te 'rekenen', behalve bv. performance etc.

[roelio]

aan een software product valt heel veel te berekenen, naast performance. Maar bepaalde zaken moeten ook getest worden, en dat is denk ik het probleem: het is ontzettend moeilijk en soms misschien niet eens mogelijk om een sluitende test te maken die alle fouten uitsluit.

[Crazy D]

Op woensdag 19 december 2001 10:52 schreef L_Jinx het volgende:
Blijft inderdaad een bekend probleem. Maar ik moet zeggen als je het bouwen van een progamma net zo aanpakt als het bouwen van een brug, dus met een uitgebreid ontwerp enzo, dan wordt het wel minder gepruts.

Ik denk dat dat iets is wat heel belangrijk is. Goed ontwerp, goed doordacht, zodat je niet 2 maanden later de halve code snel moet herbouwen omdat men bij nader inzien toch een veldje extra wilde. Veel van dat soort dingen (dat is vooral wat ik merk) had van te voren bij een goed ontwerp allang bedacht kunnen worden.

Op woensdag 19 december 2001 10:08 schreef wasigh het volgende:
Maar het draait, het project is afgerond en ik ontken dat ik er iets mee te maken heb

Dat zeg ik ook altijd, maar als enigste full time programmeur wordt dat toch lastig

[ebas]

Een brug bouwen is hetzelde als eenzelfde programma opnieuw en opnieuw bouwen, en steeds verbeteren. Ik denk dat toen een brug voor het eerste gebouwd werd, er ook wel iemand doorheen gezakt is. En kijk bijvoorbeeld naar die 'bug' die vroeger nog niet bekend was: Het resoneren van de brug door de wind. Die brug was ook ingestort.

[roelio]

een groot softwarepakket bouwen is gewoon ingewikkelder dan een brug bouwen (hoewel dat voor niet ingenieurs ook pittig is ), maar in principe is het precies hetzelfde!

[mvdejong]

Het probleem is dat een hoop teams de verschillende functies in een bouw-traject niet kunnen onderscheiden. Bij veel software wordt, zeg maar, de brug ontworpen door de lassers, of wordt het las-werk door de architect gedaan. En dat werkt lekker als je een bruggetje over de vijver in je tuin moet maken, maar houdt op als de brug de Golden Gate of de Firth of Forth moet overspannen.

Dus, je moet eerst je fasen onderscheiden, en dan kijken in hoeverre het verantwoord is om bepaalde fasen parallel te laten lopen en door dezelfde bemanning te laten uitvoeren.

Er zijn aardig wat manieren om te faseren, maar een suggestie :
- functioneel ontwerp : wat moet het doen, hierbij hoort dus ook de definitie van het user-interface, logisch datamodel (relaties tussen de tabellen);
- technische ontwerp : hoe moet dat gebeuren, dus algortimen, technisch datamodel, enz.
- programmeren;
- technisch testen (dus door mensen die goed weten hoe de programmatuur intern in elkaar steekt);
- functioneel testen (door mensen die GEEN goed inzicht in de structuur van de programmatuur hebben, maar wel waar het aan moet voldoen);
- gebruikers testen (hier wordt de kwaliteit van bijv. de user-interface getest);
- documentatie.

Eerste opmerking : de documentatie-fase is NIET de laatste fase in het project, want als je het zo plant, gebeurt het NOOIT.

Technisch ontwerp en programmeren kan vaak goed gecombineerd worden, maar het is bijvoorbeeld heel belangrijk dat de functionele testen niet door de programmeurs worden gedaan, omdat het als programmeur niet te vermijden is dat je de bepaalde dingen niet test, omdat je "weet" dat dat zo simpel is dat het niet fout kan.

Het verschil tussen de functionele testen en de gebruikers-testen is dat de functionele testen zich ook richten op de rand-gevallen en uitzonderingen van het systeem, terwijl de gebruikers-testen met name de dagelijkse praktijk testen. Hieruit komen bijvoorbeeld wijzigingen om dagelijkse handelingen te versimpelen ten koste van toenemende complexiteit van de minder frequente handelingen.

Op grote projecten voor externe klanten deden we vaak een secretaresse-test tussen functionele en gebruikers testen in. Voordat we de programmatuur aan de klant opleverden voor testen, lieten we wat administratieve medewerkers met de gebruikers-handleiding los op het test-systeem. Zoiets kan je weken werk schelen.

Ervaring : circa 15 jaar automatisering, waarvan de eerste 7-8 jaar met name in programmerings-klussen, met project-bemanningen van 1 tot 10-tallen.

[The End]

mvdejong,

Wat jij vertelt is dus wat heel anders. Een brug wordt niet eerst getest door er met een auto overheen te rijden en later met een vrachtwagen.
Misschien dat er bij een nieuw soort constructie eerst met een schaalmodel wordt getest, maar dat is bij een applicatie niet echt mogelijk.

[Verwijderd]

Het probleem is dat het vakgebied Formele Methoden binnen de informatietechnologie nog maar in de kinderschoenen staat. Vandaar dat correcte specificatiemethoden nog maar nauwelijks gebruikt worden binnen de ontwerpfase van een softwareproduct. Softwarebedrijven hebben nauwelijks IT'ers in dienst die zich gespecialiseerd hebben in deze richting en alleen bij zeer belangrijke projecten wordt de hulp in geroepen van Universiteiten om ontwerpen te controleren op hun correctheid.

[roelio]

Op woensdag 19 december 2001 12:44 schreef The End het volgende:
Wat jij vertelt is dus wat heel anders. Een brug wordt niet eerst getest door er met een auto overheen te rijden en later met een vrachtwagen.

ik denk dat het verhaal van mvdejong wel degelijk van toepassing is:

bij een brug is dmv. natuurkunde etc. wel te berekenen wat voor gewicht erop kan. Er zijn niet onwijs veel verschillende soorten bruggen, dus heb je aan een flinke stapel formules genoeg. Ook zijn de omgevingsfactoren goed vergelijkbaar. Maar tussen softwarepakketten is gewoon veel meer verschil, en de omgeving (bijvoorbeeld systemen) is iedere keer anders vandaar ook dat je niet met een boekje met formules aan kunt komen, maar de bouw en testmethodes etc. veel meer op maat gemaakt moeten worden.

[roelio]

Op woensdag 19 december 2001 12:47 schreef fladder het volgende:
Het probleem is dat het vakgebied Formele Methoden binnen de informatietechnologie nog maar in de kinderschoenen staat. Vandaar dat correcte specificatiemethoden nog maar nauwelijks gebruikt worden binnen de ontwerpfase van een softwareproduct. Softwarebedrijven hebben nauwelijks IT'ers in dienst die zich gespecialiseerd hebben in deze richting en alleen bij zeer belangrijke projecten wordt de hulp in geroepen van Universiteiten om ontwerpen te controleren op hun correctheid.

Ik vind dat ook niet verwonderlijk omdat ieder softwareproject in wezen zoveel verschilt dat het heel moeilijk is om een groepje universele methoden te definieren. Verder denk ik dat het eigenlijk een vak apart is (spec.methoden) en dat het daarom ook erg moeilijk is (vind ik) om als programmeur/... dit onderdeel ook goed te beheersen.

[Verwijderd]

Op woensdag 19 december 2001 12:51 schreef limoentje het volgende:
Ik vind dat ook niet verwonderlijk omdat ieder softwareproject in wezen zoveel verschilt dat het heel moeilijk is om een groepje universele methoden te definieren. Verder denk ik dat het eigenlijk een vak apart is (spec.methoden) en dat het daarom ook erg moeilijk is (vind ik) om als programmeur/... dit onderdeel ook goed te beheersen.

En daarom is het nodig om bij software 'welke niet mag falen' (denk aan spaceshuttles e.d ) een IT'er aan boord te hebben die dit wel beheerst. Want het is toch zonde dat een spaceshuttle tijdens de lanceerfase ontploft dankzij een ontwerp'foutje'

edit:
vergeef me als het niet een space shuttle was. de bijzonderheden van het verhaal staan me niet meer zo helder voor de geest

[Tim Schuhmacher]

Maar je kan het eigenlijk niet zo stellen als de topicstarter doet, want hij is programmeur (en geen bruggenbouwer) en weet dus hoe die zelf werkt. Van een bruggenbouwer weet je alleen het resultaat - een goede brug waar iedereen over heen kan. Hoe die dat bereikt heeft weet je niet.

Zo zal dan een gebruiker van de software ook naar het programma kijken.

[DroogKloot]

Het was wel een spaceshuttle (de Challenger) maar dat ongeluk had niets met een softwarefout te maken

[Verwijderd]

Op woensdag 19 december 2001 12:47 schreef limoentje het volgende:

[..]

ik denk dat het verhaal van mvdejong wel degelijk van toepassing is:

blabla

Precies, bij een brug kun je altijd dezelfde werkwijze gebruiken, tenminste ontwikkelwerkwijze dan. Bij een softwarepakket kan dit niet, omdat elk softwarepakket verschilt, qua kwaliteits- en kwantiteitseisen. Bij een brug is het de bedoeling dat je er over heen kan rijden, zonder dat je in het water valt, bij een software pakket is dit telkens verschillend, en soms is de kwaliteit het belangrijkste aspect, maar soms ook de kwantiteit of de levertijd. Vandaar dat een softwarepakket veel ingewikkelder is om te ontwikkelen.

[Verwijderd]

Op woensdag 19 december 2001 13:02 schreef Nephilin het volgende:
Het was wel een spaceshuttle (de Challenger) maar dat ongeluk had niets met een softwarefout te maken

Dan bedoel ik blijkbaar een andere ruimtevaartuig ..

Maargoed, ander voorbeeld, een veerboot die wegvaart met de laaddeuren nog open. Was ook zo'n softwarefout meen ik.

[Azecos]

En wat natuurlijk ook nog meeteld, een brug staat op 1 vaste ondergrond die nooit veranderd. Een programma moet op verschillende ondergronden (os`en) kunnen draaien en het liefst zelfs dan nog stabiel blijven. Probeer dat maar eens met een brug, die staat vast.

[ACM]

Volgens mij onderschatten jullie het bruggen bouwen gruwelijk...

Vooral omdat bij een brug _wel_ slachtoffers vallen als het niet goed bleek te werken en bij software niet (meestal niet, er zijn ook apps waar dat niet voor op gaat en die worden dan ook vele malen beter getest) worden die veel beter, veel stricter en veel serieuzer ontworpen.

Een brug zal waarschijnlijk niet na een week alvast als test-versie neergepoot worden
Die wordt helemaal doorgerekend, helemaal tot op het kleinste detail ontworpen (dus eigenlijk elk programma regel wordt gewoon mee ontworpen) en vervolgens zwaar overgedimensioneerd neergezet.


Bij allerlei serieuze realtime programmatuur wordt hetzelfde principe gevolgd. _Eerst_ "durven" garanderen dat het doet wat de bedoeling is en daarna pas in een real-life situatie plaatsen.
Bij Boing bijvoorbeeld, wordt _elke_ programma regel getest. _Elke_ functie van een chip wordt getest etc... De acceptatie van bijvoorbeeld "realtime java" duurt daardoor dan ook erg lang, boing is daar vast al mee bezig, maar ze testen de RTJVM dus nog wel even _helemaal_.

Dat doe je in een gewone programmeer omgeving niet, waardoor het veel meer lijkt te verschillen van bruggen bouwen dan irl.

[ACM]

Op woensdag 19 december 2001 13:12 schreef azecos het volgende:
Een programma moet op verschillende ondergronden (os`en) kunnen draaien en het liefst zelfs dan nog stabiel blijven.

Normaliter bouw je een programma (systeem eigenlijk) voor 1 omgeving. Dat er bijv. 5 verschillende OS-en in die omgeving zitten weet je van te voren...

Op woensdag 19 december 2001 12:53 schreef fladder het volgende:
En daarom is het nodig om bij software 'welke niet mag falen' (denk aan spaceshuttles e.d ) een IT'er aan boord te hebben die dit wel beheerst. Want het is toch zonde dat een spaceshuttle tijdens de lanceerfase ontploft dankzij een ontwerp'foutje'

Wees maar niet bang, dan kan je die IT-er beter niet aan boord hebben... Want dan is het alleen maar verspilde moeite (bot, maar waar).

Dergelijke software fouten kan je alleen maar opsporen door extreem goed te testen en liefst voorkomen door heel goed te ontwerpen.

[Verwijderd]

Op woensdag 19 december 2001 13:16 schreef ACM een hele lap tekst

Ik denk dat daar ook het grootste probleem in zit bij softwarepakketten, er wordt te weinig gedacht, en teveel gedaan. Als je kijkt naar een brug, dan denk ik dat het ontwikkeltraject (dus het uitdenken en uitekenen ed) veel langer duurt dan het bouwen zelf, terwijl dat bij de meeste softwarepakketten juist andersom is (dus niet bij alle!!). En daardoor moet er meer getest en aangepast worden, vandaar dat de eerste fase, de ...fase(ben het woord ff kwijt) waarin je dus gaat kijken wat de klant precies wilt en wat er ook daadwerkelijk haalbaar is heel belangrijk is, meestal wordt er gedacht dat het allemaal wel duidelijk is, zodat te snel verdergegaan wordt, waardoor achteraf blijkt dat er dus verkeerd geïmplementeerd is door verkeerd vooronderzoek (dat was het woord toch ).
Vandaar dat softwarepakketten veel ingewikkelder zijn, omdat er veel meer fouten kunnen ontstaan, door de vele trajecten, met de vele vertakkingen.

[Miki]

Oh oh, een ICT'er die over een civiel onderwerp gaat lullen...dat gaat altijd fout. Zelf ben ik nu grond, weg en waterbouwkundige, straks over een jaartje of 2 ben ik civiel technish ingenieur (als alles mee zit). Ik kan je 1 ding zeggen. Er komt een hoop maar dan ook een hoop meer bij kijken. Niet alleen standaard formules. Laten we beginnen met de fundering van een brug. Ja een paar palen heien zou je zeggen!! De bodem is opgebouwd uit verschillende lagen; prut, zand, klei en noem maar op. Voordat je gaat beginnen met heien moet je dus eerst een goede laag in de bodem vinden die de hele brug constructie kan dragen. Dit gebeurt d.m.v. sondeer machines die drukgevoelige conussen de grond in drukken. Hierdoor krijg je waarden die berekent moeten worden. Het vervelende kan zijn dat een meter verderop de waardes van de grond totaal anders zijn. Dus hier speelt ook een vervelende risico mee die nooit zeker is. Als we dan kijken naar de constructie zelf zijn we er ook nog niet. In wat voor omgeving hebben we te maken? In zee of in het zoetwater, de verkeers drukte, invloeden van moeder nartuur. Voorbeeld: als een brug in een vallei staat heb je maar 2 windrichtingen maar als ie in een opengebied staat al 4 hoofdrichtingen.
Ik kan wel een tijdje zo door gaan maar dat vult alleen maar onnodige bytes, zoals jullie zien zijn er oneindig veel zaken waarmee je rekening moet houden.
En die formules zijn relatief -> er zit altijd een veiligheids factor in om ervoor te zorgen dat onverwachtse zaken "op te vangen". Dit komt omdat het vak bruggenbouw meer uitgedokterd is, immers de romeinen waren al bezig met bruggenbouw in hun tijd. De eerste pc's datateren pas ergens rond de zestige jaren. Dus ik kan me voorstellen dat je zo een opmerking maakt. Over een 10 jaar hebben we pc's met 50 mischien wel 100 giga Hertz met een terra byte dimm'etje. En dan gaat de kwestie ook op dat de architectuur van nu standaard en relatief simpel is.

[Verwijderd]

Op woensdag 19 december 2001 13:17 schreef ACM het volgende:
Wees maar niet bang, dan kan je die IT-er beter niet aan boord hebben... Want dan is het alleen maar verspilde moeite (bot, maar waar).

Ik bedoelde dus wel tijdens de software-ontwikkelfase en aan boord van het team van softwareontwikkelaars...

[mvdejong]

Op woensdag 19 december 2001 12:44 schreef The End het volgende:
mvdejong,

Wat jij vertelt is dus wat heel anders. Een brug wordt niet eerst getest door er met een auto overheen te rijden en later met een vrachtwagen.
Misschien dat er bij een nieuw soort constructie eerst met een schaalmodel wordt getest, maar dat is bij een applicatie niet echt mogelijk.

O jawel.
Een brug wordt wel degelijk eerst met lichtere belastingen getest, daarna met zwaardere belastingen, en voor oplevering met een belasting die ver boven het gebruikelijke maximum ligt. Bij de spoorwegen sturen ze bijvoorbeeld als "oplevertest" een span van 4 of meer locomotieven de brug op, dat levert het hoogste tonnage per meter rails op, en ze meten dan ook vervorming en dergelijke om te kijken of dit binnen de berekende marges valt.

En voor software kan ook met een "schaalmodel" worden gewerkt.
Met name voor complexere gebruikers-interfaces wordt dit gedaan, er wordt dan een gebruikers-interface gebouwd waarachter alleen maar dummy-programmatuur ligt.

Maar, de constructie van een brug wordt achter het bureau doorgerekend op basis van alle natuurkundige wetten en de ervaringen van de ingenieurs-bureaus op het gebied van invloed van wind, water, temperatuurs-wisselingen. Op programmerings-gebied is dit een kwestie van je ontwerp goed doen.

[Verwijderd]

Op woensdag 19 december 2001 13:16 schreef ACM het volgende:
Bij allerlei serieuze realtime programmatuur wordt hetzelfde principe gevolgd. _Eerst_ "durven" garanderen dat het doet wat de bedoeling is en daarna pas in een real-life situatie plaatsen.
Bij Boing bijvoorbeeld, wordt _elke_ programma regel getest. _Elke_ functie van een chip wordt getest etc... De acceptatie van bijvoorbeeld "realtime java" duurt daardoor dan ook erg lang, boing is daar vast al mee bezig, maar ze testen de RTJVM dus nog wel even _helemaal_.

Jah, en dat testen gebeurt door de tandenfee! Code-auditing is iets waarvan iedere softwareproducent met de mond beleidt dat het gebeurt, maar waarvan hij weet dat het in de praktijk wel tegenvalt (net als documentatie). Zelfs als er getest wordt gebeurt dat niet "regel voor regel", QA test procedures en methodes als een "blackbox"; kijkt of start en stopcondities kloppen en er "netjes geabort" wordt bij ongeldige inputs. Daarnaast ben ik nog nooit een QA afdeling tegengekomen die zeker wist dat ze de definitieve productiecode zat te auditten, maar wel een hoop programmeurs die (bewust) andere codeversies naar de audits sluisden (geen XXX in de code).

[Crazy D]

Op woensdag 19 december 2001 13:03 schreef doniek het volgende:
Precies, bij een brug kun je altijd dezelfde werkwijze gebruiken, tenminste ontwikkelwerkwijze dan. Bij een softwarepakket kan dit niet, omdat elk softwarepakket verschilt, qua kwaliteits- en kwantiteitseisen.

Behalve dat uit een eerdere reactie al blijkt dat een brug ook iets meer is dan paal + plank + stukkie beton = brug, kun je imho bij software wel degelijk een stappenplan hebben. Levertijd, functionele eisen ed, zijn niet van belang (nou ja, wel natuurlijk, maar niet voor het idee van een stappenplan). Het komt uiteindelijk neer op ontwerpen, coden, testen, nog meer testen, uitleveren (erg kort samengevat). En dan is qua inhoud een functioneel ontwerp per programma anders, het idee en de structuur niet. En het idee is nou juist erg goed doordenken en ontwerpen wat het pakket moet kunnen en hoe het dat moet doen. En dan nog een keertje er goed over nadenken.
Wat ik merk bij sommige pakketten (en ook bij "grote" namen), is dat er een stukje opgezet wordt, en dan later moet er nog wat bij. Denk aan de Erasmusbrug. De basis wordt gebouwt, en halverwege komen ze op het idee dat dat ding (zwanehals? whatever) in het midden er op moet komen, en weer een paar maanden later bedenken ze dat er ook wat van die koorden aan moeten komen. Daar is bij het bouwen van de basis heen rekening mee gehouden. En dus zal je dat bij bruggen niet zo vaak tegenkomen. Die zwanehals wordt vantevoren bedacht, en daarna gaan ze pas bouwen.

Ik ben verder niet echt op de hoogte van verschillende "standaarden" om software te ontwerpen, maar ik ben er van overtuigd dat er wel een stappenplan is waarin het meeste wel goed doordacht is voordat er begonnen wordt met coden. En uiteraard kan er altijd wel een keer een aanpassing nodig zijn, maar als het goed is gaat dat vooral om kleine dingetjes en geen grote structurele aanpassingen (ik denk aan een groot boekhoud pakket, waarbij besloten is om debiteuren en crediteuren in 1 bestand samen te voegen, maar waardoor voor backwards compatibility weer views nodig zijn die de oude tabellen nabootsen. Vervolgens wordt er bedacht dat het debiteurnummer wel 10 posities kan gaan worden, en later weer 20, waardoor je nu een relatietabel hebt met 3 debiteurnummers (en ook 3 crediteurnummers, een deb kan immers ook een cred zijn) met 3 verschillende lengtes. Ja, ook nog eens zo slecht ontworpen dat een numeriek veld in een fixedlength char (rechts uitgelijnt) wordt opgeslagen . Imho zijn dat aanpassingen geweest, die als ze eerst hadden gedacht, en daarna pas waren begonnen met db ontwerpen en programmeren, niet nodig waren geweest).

[mvdejong]

Het probleem met de "mag niet falen" software is precies waar de meeste ontwerpers en programmeurs vroeger en tegenwoordig de fout in gaan.

Iedereen die zonder gedegen training (en dan nog ...) software gaat bouwen is volledig gefocusseerd op de functionaliteit van het systeem, dus wat het moet doen. Er is niets zo vervelend als fout-afhandeling (als je niet gelooft in de kwaliteit van de software).

Je moet allereerst denken welke fouten op kunnen treden (hoeveel programma's handelen een volle schijf bij data-opslag goed af ?) en vervolgens de juiste aanpak bedenken om dit goed af te handelen. Het gevolg is dat voor een kwalitatief goed systeem de fout-afhandeling meer dan de helft van de regels code beslaat, en dan krijg je ook het gezeur over geld en doorlooptijd. Bij projecten die betrekking hebben op militaire toepassingen, lucht- en ruimtevaart praten we tot 90 % van de code die fout-afhandeling doet.

Voorbeelden te over. Kijk maar naar alle buffer-overrun exploits van de laatste 2 jaar. Die fout zat er altijd in, maar niemand die zich er zorgen over maakte, want dat risico was te klein. Maar feitelijk gewoon onvoldoende nadenken over mogelijke problemen.

Uit mijn eigen praktijk : een magazijn met 2 kranen, elk een eigen gang met stellingen, en een gemeenschappelijke. Gedurende het traject kwam ik (als programmeur) met de opmerking dat niets in de code verhinderde dat beide kranen tegelijk dezelfde locatie in de gemeenschappelijke gang zouden toegewezen kregen. Ik droeg ook het concept van de oplossing aan. Maar, "het was onwaarschijnlijk" en we zaten al voorbij de oplever-datum, dus er werd niets aan gedaan. Onwaarschijnlijk, ja, een week na oplevering kon ik al naar de klant omdat een item in de stelling was geschoven, en een volgende ertegenaan, zodat het eerste item van 12 meter hoog op de grond stuiterde (gelukkig een mens-vrij magazijn).

[Janoz]

Op woensdag 19 december 2001 14:14 schreef mvdejong het volgende:
Uit mijn eigen praktijk : een magazijn met 2 kranen, elk een eigen gang met stellingen, en een gemeenschappelijke. Gedurende het traject kwam ik (als programmeur) met de opmerking dat niets in de code verhinderde dat beide kranen tegelijk dezelfde locatie in de gemeenschappelijke gang zouden toegewezen kregen. Ik droeg ook het concept van de oplossing aan. Maar, "het was onwaarschijnlijk" en we zaten al voorbij de oplever-datum, dus er werd niets aan gedaan. Onwaarschijnlijk, ja, een week na oplevering kon ik al naar de klant omdat een item in de stelling was geschoven, en een volgende ertegenaan, zodat het eerste item van 12 meter hoog op de grond stuiterde (gelukkig een mens-vrij magazijn).

Jammer dat IT-ers bij Murphy's law altijd aan "verdubbeling van computerkracht elke 18 maanden" denken in plaats van de veel belangrijkere regel voor alle IT oplossingen!

Op woensdag 19 december 2001 13:52 schreef Miki een verhaal over het echte bruggen bouwen

Helemaal gelijk.. Wat echter veel mensen vergeten is dat het voor de IT netzo geldt.. Bestuurders zien niet wat voor werk er allemaal achter de brug zit waar ze net overheen reden.. Software gebruikers zien niet wat voor enorm werk er eigenlijk achter dat simpel ogende stukje software (hoort) te zitten..

Op woensdag 19 december 2001 12:00 schreef chem het volgende:
mja, een brug is toch anders. Een brug is berekenbaar. Een softwareproduct, daar valt weinig aan te 'rekenen', behalve bv. performance etc.

Mwah.. aan software valt ook nog behoorlijk te rekenen hoor .. Heb zelf nog het vak "Programma correctheid" gevolgd waarin elke procedure wiskundig bewezen moest worden (pff)..

Op woensdag 19 december 2001 12:53 schreef fladder het volgende:

[..]

En daarom is het nodig om bij software 'welke niet mag falen' (denk aan spaceshuttles e.d ) een IT'er aan boord te hebben die dit wel beheerst. Want het is toch zonde dat een spaceshuttle tijdens de lanceerfase ontploft dankzij een ontwerp'foutje'

edit:
vergeef me als het niet een space shuttle was. de bijzonderheden van het verhaal staan me niet meer zo helder voor de geest

Was de Ariane 5.. die gebruikte software van de Ariane 4. De 5 is veel sneller waardoor de waarde voor de versnelling niet meer in de daarvoor gereserveerde geheugenruimte paste.. Aangezien de meest sugnificante bits wegvielen ging de versnelling plotseling erg schommelen. De boordcomputer dacht dat hij een mallfunction had, switchte over naar de backup computer en schakelde zichzelf uit.. Backup computer had precies hetzelfde en schakelde zich ook uit.. Stuurloze raket raakt uit balanc BOEM.. self destruct..

[ACM]

Op woensdag 19 december 2001 14:09 schreef mietje het volgende:

Ik denk dat ze bij Boing wel degelijk op die manier te werk gaan.
Toevallig had ik vorige week een lezing over Realtime java, waarbij onder andere ingegaan werd op integratie in levensbedreigende situaties.
Daar werd ons gemeld dat Boing al tijden bezig is realtime java te testen en dat ook pas over 5-10 jaar ofzo geintegreerd kan worden in hun systemen...

Hetzelfde geldt voor hun software, dat wordt _extreem_ goed getest (en of ze nou wel of niet letterlijk regel voor regel testen weet ik niet, maar het is wel een mooie omschrijving voor een dergelijke uitgebreide testserie)

[farlane]

Kennelijk zijn de overeenkomsten tussen bruggen bouwen en software maken groter dan je op het eerste ogenblik zou denken.

Misschien is het probleem wel dat de gemiddelde bruggenbouwer meer verstand van zaken heeft dan de gemiddelde softwaremaker?

Ik weet uit eigen ervaring dat er veel mensen zijn die software maken (iig in de industrieele sfeer, maar volgens mij gaat dit algemeen op), die geen verstand hebben van software maken, maar wel veel van het produkt dat ze automatiseren. Het resultaat is vaak een apparaat dat wel werkt, maar dat qua foutafhandeling/uitbreidbaarheid/onderhoudbaarheid een ramp is.

[Crazy D]

Op donderdag 20 december 2001 09:14 schreef farlane het volgende:
Misschien is het probleem wel dat de gemiddelde bruggenbouwer meer verstand van zaken heeft dan de gemiddelde softwaremaker?

Ik weet uit eigen ervaring dat er veel mensen zijn die software maken (iig in de industrieele sfeer, maar volgens mij gaat dit algemeen op), die geen verstand hebben van software maken, maar wel veel van het produkt dat ze automatiseren. Het resultaat is vaak een apparaat dat wel werkt, maar dat qua foutafhandeling/uitbreidbaarheid/onderhoudbaarheid een ramp is.

Zou best wel eens kunnen. Iig heeft een bruggenbouwer denk ik van zowel het ontwerpen als het bouwen verstand, terwijl programmeurs vaak alleen van programmeren verstand hebben, of idd van hetgeen wat er geautomatiseerd moet worden.
In de meest ideale situatie heb je dan ook een team van mensen die verstand hebben van programmeren, en mensen die verstand van het te automatiseren gebeuren hebben. Helaas is dit niet altijd mogelijk...