Libtiff, libtiff, libtiff, libtiff, libpng and libtiff

Jeg er persoligt ikke overrasket over at Huawei havde en håndfuld OpenSSL i deres projekt, for jeg har selv siddet på et projekt hvor man stødte på Libtiff næsten uanset hvor man kiggede.

Bortset, naturligvis, fra det ene sted i projektet hvor man brugte libpng til at lave billeder til debug, udvikleren havde nemlig ikke kunnet finde et sæt parametre til libtiff så xv(1) kunne forstå resultatet.

Conways lov siger lidt forsimplet, at software komme til at ligne de orignisationer der producerer den.

Vores Libtiff forurening skyldes at systemet var delt op i nogle naturlige funktioner, image-capture, OCR, ICR, keying, printing osv og hver af disse havde sin egen afdeling og sin egen kopi af Libtiff.

Eller ofte: Kopier af Libtiff, for hvis man havde brug for en nyere version var der ikke nogen process og ikke noget budget for at opgradere de gamle kunders kørende systemer, så det var ikke usædvanligt at Makefile valgte hvilken version af libtiff der skulle bruges, baseret på variablen "CUST".

Det kunne der siges meget mere om, men når konteksten var at "Configuration Management" gruppens dokumenterede process for at bygge systemet var at skrive "make clean" tre gange, derefter "make -k", derefter reboot af to maskiner, derefter "make -k" igen og til sidst "make" og brugte 3 uger på at opdage at build'et fejlede de nætter hvor en bestemt medarbejder slukkede sin arbejdsstation, var vores overforsyning af libtiff langt fra vores *største** problem.

Men det var et problem, ikke mindst når de forskellige funktioners kildetekst skulle bruge hinandens #includes og debugging var ofte en opdagelsesrejse, inkl. den obligatoriske vittighed: "Libtiff, I presume?"

Jeg er sikker på at dengang man byggede "Det nye kommunehospital" her i vores del af udkantsdanmark, har man beundret den flotte og systematiske arkitektur, der var gennemført helt ud til og med lægeboligerne.

Siden da er der bygget nyt en ti-tolv gange og det er naturligvis ikke bygget i samme arkitektur, materialer og håndværk, selvfølgelig ikke, hver gang har man naturligvis lavet "moderne økonomisk byggeri."

Slagelse Sygehus er hvad man i CorpSpeak ville kalde "Et heterogent system med nogle år på bagen."

Sådan er, eller rettere, sådan bliver virkeligheden med tiden, både for bygningskomplexer og IT systemer.

Men ligesom et spritnyt homogent system sagtens kan have graverende arkitektoniske fejl (Host! Rejsekortet! host!), kan et gammelt heterogent system have en fantastisk god arkitektur.

Det afhænger, selvindlysende, af om der er en arkitekt til at begynde med og hvor god vedkommende i givet fald er.

I IT er vi slemme til slet ikke at have arkitekter.

I mit gamle job plejede det at være ejer-chefen og han var god til det, men så solgte han firmaet til et stort industrikonglomerat som indsatte en overskydende mellemleder som ny direktør og da jobbet som arkitekt var ikke med i "Human Resources" regneark blev det ikke genbesat, hvilket var den direkte årsag til at købet gav underskud.

Huaweis mange kopier af OpenSSL rejser mange øjenbryn, inkl. mine, men det er ikke i sig selv en velegnet metrik at vurdere hverken software eller software-producerende organisationer på.

Men det kan og bør bruges som "auditing-taget" og mine spørgsmål til Huawai ville være:

  • Vidste Huawei hvor mange OpenSSL kopier de havde ?

  • Hvorledes håndteres & koordineres sikkerhedsopdateringer af dem ?

  • Hvad er de arkitektoniske argumenter for hver enkelt kopis existensberettigelse ?

  • Hvad er de arkitektoniske argumenter imod hver enkelt kopis existensberettigelse ?

  • Hvad er processen for at godkende tilføjelsen af eller fjernelsen af en ny kopi af OpenSSL ?

  • Kender medarbejderne den ?

Hvis man skal levere infrastruktur til et helt lands mobilnetværk, skal det ikke tage mere end 2 omstillinger før auditøren har den rigtige person i røret og ikke over 10 minutter for denne at give tilfredstillende svar der lukket emnet.

Sådan ser det ikke umiddelbart ud til at virke hos Huawei, hvilket bringer os tilbage til Conways Lov, der også kan udtrykkes som:

Vis mig din kildetekst og jeg skal fortælle dig din organisation virker.

phk

Kommentarer (3)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Povl H. Pedersen

fremfor single instance har som udgangspunkt ingen eksistensberettigelse.
Dog kan der være gamle dele af softwaren hvor alle udviklere er væk, og man føler ikke man kan justere til nye API kald / behaviour. Men det bør fixes.
Og minor versions hvor API er statisk bør man ikke have lov til at bruge andre versioner af end projektets.

Det er den gamle tankegang med at bruge en version x, og holde fast i den, indtil det har været så dyrt at der er en businesscase for at opgradere. Set fra et management perspektiv, så er det den absolut sundeste holdning. Set fra udviklerne og kunderne, så er det bare dumt.

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize