
Skriv en IC4 bog!
Så kom vi endelig til det punkt hvor det kom frem at IC4 projektets problemer, stort set uden undtagelse, kommer fra de mere eller mindre indlejrede computere.
Hvordan får vi en eller flere af de involverede til at at skrive en bog om IC4 projektets computer problemer, så den dyrekøbte lærdom ikke går tabt ?
For vi er da ude på at blive klogere, er vi ikke ?
phk
PS: I ved godt at DSB lavede præcist den samme fadæse med IC3 i sin tid ?
Selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (6)
Ja, IC3 var også en fest hvad det angik - så vidt jeg husker foregik styringen af gearkasserne via en app på en Windows 95, der så i det første års tid ganske ofte skulle genstartes et par gange undervejs på en tur fra Århus til København. Der var mange interessante forsinkelser på den konto.
IC4 bærer på mange punkter præg af at have fejl i de samme undersystemer som gav problemer med IC3. Det er utroligt så meget tid man kan spilde på ikke at købe og tilpasse hyldevarer.
Det ville være ret imponerende, hvis styringen af gearkasserne på IC3 foregik via en Windows 95-app, da de første tog blev leveret til DSB i 1989 - med 20 måneders forsinkelse.
Det har ikke nødvendigvis alt sammen noget med togsoftware at gøre, men jeg må konstatere, at det er muligt at grave skandalehistorier op om stort set alle DSB's leverancer af "lange toge" i nyere tid:
IC3-tog (leveret af Scandia): http://ing.dk/artikel/6729-ic3-daarligt-styret
IR4-tog (leveret af ABB): http://ing.dk/artikel/24594-nu-kan-ic3-koere-sammen-med-ir4
http://ing.dk/artikel/9927-ekstraregning-paa-vej-for-ir4-tog
Øresunds-tog (leveret af AdTranz): http://ing.dk/artikel/32269-oeresundstog-volder-problemer
http://ing.dk/artikel/40664-dsb-nulstiller-29-oeresundstog
Ingen tvivl om, at PHKs forslag om at skrive en bog om problemerne med IC4, meeeeen... Hvornår kan vi forvente den udkommer og kan vi forvente at den er læsbar til den tid?
jeg tænker bare på, at vi nok igen og igen og igen og igen og igen.... og igen vil opleve, at forfatteren/forfatterne vil udskyde udgivelsen :)
Ofte, er svært for programmører, teknikkere, og andre der arbejder med problemerne, at skrive en bog samtidigt med de udvikler. Skal beskrives klimaet omkring udviklingen, problemerne osv. så er nødvendigt med en ekstern forfatter, der følger teamet i tykt og tyndt. Måske var en idé, at PH melder sig, som forfatter?
Der er vel ingen som er interesserede i at få opklaret hvad der gik galt/hvad man bør gøre anderledes næste gang?
For i samme øjeblik man kan fastslå bare nogenlunde præcist hvad der ikke spiller sammen, så har man jo også udpeget en direkte/indirekte synder?
Og det er jeg ret overbevist om at ingen af parterne i projektet kan have nogen som helst interesse i.
En semi-defekt software som skal kildes under maven konstant for at holdes i luften, er et ret udbredt levebrød. (og du skal ikke bare komme her og flytte osten)
I bilens tidlige barndom skulle man også have mekanikeren siddende ved siden af føreren og bl.a. holde øje med smøringen af motoren i sådan nogle glasrør. Der er man da kommet lidt videre al den stund at du snart kan køre 20-30.000 km. før den skal se en mekaniker.
IT er vel efterhånden også nået lidt videre?

