Re: Giv mig 20 mio
Og udover kunderne, er der jo næppe nogen, der behøver support.
Desværre, der er mange der behøver support. For eksempel: Hvis en flyvemaskine udraderer det IT-center hvor applikationen er i drift: Hvad skal nogen helt konkret gøre, trin for trin, for at bringe systemet til at fungere igen? Og: Hvordan kan en revisor bevise, at ingen transaktioner blev tabt? (Der er behov for manualer med nøje procedurer at skulle forfølge).
Support, er et resultat af, at udviklingsarbejdet ikke gøres godt nok. Hvis udviklingsarbejdet er gjort ordentligt, så er det robust - uanset at IT-centeret bombes. Typisk, vil IT-Centeret kun huse en underholdningsmaskine, så at alle ved, at HER står computeren, der huser hele danmarks bus og tog server. Meddens fakta er, at de relle computere, står placeret i hele landet, og at der skal bombes over 40 steder, for at sætte systemet ud. Ikke desto mindre, sættes oftest et par maskingeværs bevæbnede vagter, til at bevogte humor-serveren, så alle ved, at her er hele sikkerheden begravet. Meddens de rigtige servere, står ubemandede mange steder rundt i landet, og måske nogle få reserver i udlandet, så danskernes ruter kan gå over i historien, hvis hele landet skulle udslettes samtidigt at en kæmpe A-bombe.
Hvis et system laves rimeligt sikkert - og med en sædvanlig redundans - så vil det ikke være følsom overfor, at op til 2/3 af alle servere, der placeres forskellige steder, går ud af drift. Det er derfor ikke umiddelbart muligt, at bombe serverne. Kun "hovedserveren" der ikke har nogle forbindelser.
Man kan blive ved. Spørgsmål: Hvis IT-platformen bliver forældet, hvordan skal applikationen helt konkret overflyttes til en ny platform?
Det største problem, er måske at selve billet-automaterne forældes. Det er et helvedes arbejde, at gå rundt og skifte alle CPU'er i busser og på S-togs stationer. Derfor, vil man typisk undgå at anvende en CPU, men i stedet bruge en FPGA. Så er man sikker på, at tilstrækkeligt få, er i stand til at foretage opgradering, da systemet skal kodes i VHDL, og så vedbliver systemet at fungere pålideligt, og ens, for altid. Problemet er, at for mange kan programmere en PC platform, så den vil man normalt ikke kunne bruge. En PC-platform, er en hackers ejendom.
Eller: Hvordan skal et trafikselskab tilslutte sit IT-system, helt konkret? Og: Hvad skal de tilsluttede trafikselskaber gøre i deres IT-system, når systemet bliver opgraderet?
Undgå opgradering. Hvad skal det til for?
Hvis noget går galt, i grænsefladerne imellem systemet og enkelte trafikselskaber, hvem har ansvaret, bevisbyrden, skal betale?
Hvis noget går galt, så er det fordi, at noget er kodet forkert. Med andre ord - hvis systemet gøres korrekt fra start, så er der ikke brug for support penge. Support, er proportional med antal fejl i softwaren.
Det antal penge, som indtil nu, er gået til drift og vedligeholdelse, af et system, der ikke er i drift, tyder på, at det nok vil være billigere, at starte forfra, og udvikle alt fra bunden endnu engang. Det nuværende system, vil sandsynligvis aldrigt blive billigt, og kunne fungere uden support. Måske kræves endog, at en programmør til stadighed ændrer kode, for at undgå at eksplodere og slette alle busruter, og penge.
Eller: Hvordan skal ejeren af systemet holde øje med om der sker svindel imod systemet?
Svindel forekommer, fordi at svindlere ansættes som programmører. Og det er faktisk et stort problem - men problemet er størst, under selve udviklingen. Hvordan vil du sikre dig, at det ikke er en terrorist du ansætter, som forsøger at ødelægge software, og rejsekortet inde fra? Der kan være terrorister, både blandt programmører, og hos ledere, og direktører. Er systemet lavet af ærlige mennesker, så er svinde ukendt, og umuligt.
Man opdager i denne art af projekter, at en udvikling af operative planer er nødvendigt for at kunne sætte systemet i drift, og, man opdager også, at fundamentet hele tiden skrider under projektets elementer, fordi teknologierne udvikler sig hastigt, og fordi truslerne om svindel imod systemet gør ditto.
Teknologierne ændrer sig ikke. Du kan nemt anvende forældet teknologi, så er du sikker på, det ikke forældes, og ikke behøver udskiftning. Faktisk, er forældet teknologi, det mest sikre valg. Du får mere pålidelige programmører og ingeniører, hvis du kræver de skal kode noget forældet teknologi, med begrænset hastighed og hukommelse, end hvis du søger dem, der kan programmere de senest nye systemer, og hele tiden ønsker nyt, og større, mere ram, og flere CPU'er.
Sandsynligvis, i sådanne projekter, behøver projektgruppen at omgøre arkitekturen adskillige gange undervejs, indtil alle behov er opfyldt, og da har taxameteret rullet i mange flere måneder end oprindeligt forventet, hos mange flere mennesker end forventet, og fra mange flere faglige professioner end forventet. Typiske amatører, før projektstart, forestiller sig at løsningen bliver "et lille regneark, indstoppet i en personlig computer, og så vil det på en eller anden måde fungere i hele landet."
En ingeniør, vil næppe tro løsningen er et regneark. Men, hvis DSB kan levere en prisstruktur som regneark, så er det da interessant at se på.
Et regneark har en elendig beregningshastighed, og der kan ikke garanteres svartid, og lagerforbrug. Samtidigt, anvender du systemer, som du vil have problem, med at bevise pålideligheden af. Du skal altid, før du starter, undersøger om hardwaren har tilstrækkelig høj kvalitet, om operativsystem har tilstrækkelig høj kvalitet osv. Det betyder, at du skal undersøge alle systemers lagerforbrug, og om de har memory leaks. Er der fejl i systemet, er det bedre at gøre uden, og eventuelt kode helt uden operativsystem, hvis der ikke kan findes et fungerende. Der findes industrielle operativsystemer, der burde fungere. Men skal noget fungere, bygges det på komponenter som fungerer. Og de skal ikke kun fungere, man skal også have overblik over dem, så man er sikker på, at de ikke går ind i en ikke fungerende tilstand, eller har en hacker bagdør. Det betyder, at man reelt skal kunne overskue hele softwaren, eller have kendskab til, og kunne sikre, at softwaren er bygget på måder, så softwaren er 100% sikker, og ikke har fejl. Som eksempel, må ikke være muligt, at der kan være placeret en bagdør, eller andet kriminelt i softwaren. Selve måden, som udviklingen sker på, skal ske så det ikke kan gøres, selvom der ansættes dygtige personer, der har til opgave at indføre sådan software.
At udvikle et sikkert system, er som regel det besværlige - for der kommer nemt såvel ledere, som programmører ind i systemet, der har noget helt andet som skjult hensigt, og kan man ikke håndtere det, så ødelægges systemet, og forsynes ofte med hacker bagdøre.
Man ved ikke, fordi man på forhånd ikke har fantasi til at forestille sig det, at alene administrative krav fra skattevæsener er et kæmpemæssigt projekt i sig selv, at kunne opfylde dem. Samtidig blomstrer ansvarløse ideer fra selvsamme amatører undervejs i projektet, krav om at det færdige system, allerede i 2. generation af systemet, også skal kunne fungere via mobiltelefoner af enhver type ... Krav, der næppe nogensinde vil blive opfyldt, men som allerede fra begyndelsen i 1. generation af projektet vil plage udviklingsfolkene, at skulle tage hensyn til en mangfoldighed af fremtidige krav. Hvad nu, for eksempel, hvis Norge viser sig at købe en kopi af systemet? "Konklusion: Vi behøver at have os et sprog-modul i systemet, så det bliver nemt at ændre på noget i diverse lande." Imens, er der folk i projektet der funderer over, om de måske burde tage kontakt til Google, om projektet på en eller anden ukendt måde vil kunne overspringe en hæk af udviklingsomkostninger, anvende noget som er standard. Deraf et spørgsmål: Hvilke standarder at satse på? Dette fører så til udlandsrejser, besøg på IT-messer, for at gætte sig til fremtidens standarder inden for fx telekommunikation. Samt: "Hvilke teknologier skal vi satse på for at forhindre piratkopiering og snedige måder at narre vort realtidssystem?"
Formålet er ikke at narre et realtidssystem, til at ikke svare i realtid...
En advokat i projektgruppen vil på et tidspunkt spørge: Overholder projektet EUs krav om beskyttelse af personlige data?
Det koster altid et par milliarder, hvis der går advokater i det.
I midten af alt dette sidder der måske tre programmører, mennesker der undrer sig over at deres lille kode-projekt er blevet til en beskæftigelse af hundredevis af mennesker i årevis. På samme tid, evigt og altid, foregår der ting og sager på Christiansborg, politikere der træffer beslutninger, fuldstændig uden at tænke på de usynlige systemæssige konsekvenser. Som betyder, at man bør undre sig over, at vi overhovedet har nogle offentlige systemer der fungerer.
Og endnu mere, så undrer de samme tre programmører sig over, at efter der nu er blevet ansat højtlønnede eksperter, og at der er hundreder af programmører - så bliver svartiderne sløvere, og antallet af fejl øges.
Jeg husker Opera - engang var det faktisk en god browser, og den hurtigste på markedet. Dengang var der 5 programmører. Og de lavede en browser, der var ligeså god - og bedre - end microsofts mange hundrerede udviklere. Så fik Opera ansat nogle højtydende eksperter, og vupti - så blev det ligeså dårligt som så meget andet. Pludseligt, måtte jeg sande, at de havde udskiftet deres hurtige sorteringsalgoritmer med noget der lignede bobbelsort. Så jeg sluttede med at bruge Opera, fordi sorteringen af mails, tog 20 dage - og det på mit gamle system, blev gjort på et halvt sekund. Og så gik jeg tilbage til den gamle opera. De mange nye personer, kunne kun ødelægge produktet, og kendte ikke anden sortering end bobbelsort. Som de sikkert også mente var meget mere overskueligt, end den som den erstattede, og som sandsynligvis var dårlig, barnlig, og totalt håbløs, uoverskueligt, og som de på ingen måder vil overtage ansvaret for. Så jo, intet andet var bedre, end at indkode den nyeste bobbelsort. Og så var Opera pludseligt mange gange flere penge værd. Og lavet af de førende programmører.
