Utvecklare har all anledning att vara stolta. Vilka andra har till exempel makten att ta sig in i en databas och förändra verkligheten? Och ju mer världen förlitar sig på datorer, desto mer makt får utvecklare, skriver IDG News.

Men högmod går före fall. Den makt som utvecklare har är inte absolut. Ibland kan den vara skakig och det kommer sig ofta av att utvecklare gör antaganden som helt enkelt är felaktiga. Antaganden som ofta stämmer, men inte alltid.

Här är åtta exempel på saker som utvecklare inbillar sig är sanna, men inte alltid är det.

1. En fråga har ett svar

Tänk dig en databastabell vars kolumner är fyllda med värden. Antingen finns det ett värde eller så är värdet null, vilket gör det enkelt att få svar på databasfrågor.

Men ibland finns det mer än ett svar. Tänk dig en kolumn för telefonnummer. En person kanske har mer än ett nummer. Personen kanske bor på landet på helgerna. Sådant här brukar databasdesigners lösa med olika typer av relationer eller genom att använda en nosql-databas med en dokumentmodell, alltså att man klumpar ihop alla möjliga värden.

Läs också: Som årsringar i ett träd – så har företagens it-miljö växt under åren

Den senare varianten kan vara bättre, men även den har begränsningar. Ett nummer kanske bara gäller mellan klockan fyra och sex på eftermiddagen, till exempel. Och det kanske inte räcker med att ha ett alternativt nummer per dag. Vissa kanske gör undantag mellan sju och nio på morgonen. Och så vidare i all oändlighet.

Kort sagt. Det går sällan att täcka in alla möjliga situationer som kan uppstå.

2. Null är acceptabelt

Ibland har vissa utvecklare, främst C-programmerare, en känsla av att hälften av koden de skriver är till för att kontrollera om en pekare har värdet null. Det går att effektivisera tester av det i koden, men det uppstår ofta krångliga situationer.

Nullvärden i allmänhet leder till en massa problem i kod.

3. Mänskliga relationer kan beskrivas i kod

När samkönade äktenskap blev tillåtna i vissa delstater i USA så tyckte en del databasadministratörer att det var ett större problem än milleniumbuggen, som nästan paralyserade världen när man var tvungen att lägga till två siffror i årtal. En databasadministratör funderade på att designa 14 olika, allt mer tillåtande, databasscheman. Till slut kom han fram till att den enklaste lösningen vore att förbjuda äktenskap överhuvudtaget.

Men att hålla reda på vem som är gift med vem är bara en början på en problembeskrivning. Tänk dig att designa en databastabell för en skola, för att hålla reda på vem som får hämta ett barn vid dagens slut. Visst, de biologiska föräldrarna ligger bra till, men styvföräldrar? Äldre ”plastsyskon”? Det här handlar om viktiga ansvarsfrågor, så det måste bli rätt.

4. Tal är exakta

Tänk dig en skidort, att det är soligt och svalt. Allt verkar perfekt för att åka utför, men vissa av backarna är ändå stängda. Varför? För att det kan inträffa laviner i dem och det inte går att förutsäga med enkla numeriska värden som temperatur och luftfuktighet. Det finns mer komplicerade modeller för att förutsäga det, men de är inte exakta.

Så ibland stängs backar av för säkerhets skull.

It-branschens tilltro till tal blir bara starkare i takt med att begrepp som ”big data” blir mer populära. I verkligheten kan tal bara ange väldigt specifika saker. De är ofta användbara, men långt ifrån alltid helt tillförlitliga.

5. Vanligt språk är konsekvent

En slapp lösning som utvecklare ibland tar till är att slänga in en textruta (textfält) i ett formulär och låta användare skriva vad de vill. Eftersom innehållet ofta är avsett att tolkas av människor och inte av algoritmer så är det inte ett problem.

Problemen uppstår i stället när kod ska tolka text, till exempel förkortningar. Vad betyder till exempel ”St” i ett adressammanhang. Betyder till exempel “St. mossen” verkligen ”Sankt mossen”?

6. Tid är konsekvent

Visst flyter tiden på i ett konsekvent flöde. Problemet är att människan har strulat till det. Man kan till exempel anta att det går 24 timmar på ett dygn. Gör inte det, eller skriv åtminstone inte kod som gör det. Om man till exempel flyger från Stockholm till New Delhi kan det gå fler timmar på ett dygn.

Tidzoner är bara början. Sommartid är ett annat exempel.

För oss svenskar finns ett favoritexempel på tidsproblem: Veckonummer. Om man hade fått en krona för varje gång någon sagt ”det finns en veckonummerfunktion i Sql Server” så vore man rik vid det här laget. Problemet är att svenska veckonummer och Microsoftveckonummer är två helt olika saker.

Läs också: Så här får du nytta av Bash på Windows

7. Filer är konsekventa

Man kan tycka att en dator borde komma ihåg data. Man borde kunna återskapa bitar även om de representerar felaktig information. Men det är inte ens alltid det går.

Även om ”vanliga användare” förstår att olika program jobbar med olika filformat, och inte alltid hanterar filformat som andra program använder, så kan det vara ännu värre för en utvecklare. För att illustrera det här räcker det med att påminna om hur våra kära svenska tecken å, ä och ö fortfarande i dag, 2017, hanteras i vissa filer och databaser.

8. Vi har kontroll

Vi tror gärna att en dator utför de instruktioner vi ger till den. Och det stämmer, utom när det inte gör det.

Det är inte vi utvecklare som har makten, utan operativsystemet . Eller hypervisorn. Eller den lilla processorn i det lilla lagringskortet. Transistorerna i din dator lyder inte i första hand dig.