a hacker using a typewriter in a dark forest
Prompt som skapat den AI-genererade bilden
Jag lärde mig på allvar att programmera i ”vuxen” ålder. Det fanns ju för fasen inga Commodore kvar när jag började bli lite medveten. Inga sådana där tidningar med hela program som skulle knappas in som alla äldre kodare tillber sina kodarkunskaper.
Jag kommer ihåg hur mytomspunna jag tyckte programmerare var. Hur kan de skapa en emulator som gör det det möjligt att spela gamla spel igen? (Nu vet jag). Hur kan de koda spel med grafik och interaktion? (Nu vet jag). Hur kan de koda små intellekt inuti maskin som startar och stoppar verkliga processer som tillverkar de varor vi behöver? (Nu vet jag).
Det finns fortfarande saker jag tycker är mytomspunnet. Hur fasen kan de ändra några av bitarna i en exe så den inte längre kräver cd skiva i läsaren? (Behöver lära mig Ghidra…). Hur kan de komma på exakt rätt bitar att skicka till den öppna porten på en VPN som gör att en virtuell tjuv är helt inne på ett annat företag?
I stridens hetta är det svårt för utvecklare att beskriva varför en till synes enkel ändring kräver stora omtag, när något annat som känns mycket svårt visade sig kunna implementeras på en förmiddag. Denna text är en filosofisk grund till diskussionen för hur framtidens mjukvara kan skapas på ett hållbart sätt.
Jag har tänkt mycket på vilket annat yrke som är mest likt systemutvecklare och min bästa liknelse är författare. Det finns så mycket olika författare. En del har en karriär i att skriva faktaböcker om det objektiva vi försöker inrama. Andra skapar hela fiktiva världar med helt påhittade innehåll eller efterforskade sammanblandningar från den verkliga världen. Vissa skriver bara biografier om andra människors liv. Böcker kan antingen skrivas av en person eller flera. Det beror lite på vad det är för typ av bok och vilka individer som finns till hands att skriva den.
Något som är lika mytomspunnet som en programmerare som skapar en bästsäljare helt själv är en hur en författare som skapar en hel värld i böcker med bara sin hjärna och tangentbord.
Vissa författare kan skriva olika genrer. Medans andra bara skriver samma typ av verklighets inspirerade thrillers igen och igen. Alla författare har säkert sitt egna arbetssätt som gjort de framgångsrika i sin produktion av verken. Jag kan tänka mig att en del vill skriva allt från start till slut medans andra gör de viktigaste delarna först för att sedan fylla på med passagerna emellan.
Nu börjar liknelserna mellan programmerare och författare.
Att vara agil på riktigt är att säga stopp vänta: ”jag är en författare av skönlitterära romantik pockets”. Skall jag skriva en faktabok om dinosaurier så behöver vissa anpassningar i arbetssättet göras. Skall jag också göra det ihop med några andra som var och en har en annan bakgrund som inte heller är relaterad med dinosaurier måste vi lära känna varandra.
Ibland kanske boken har påbörjats av någon men av någon anledning behöver en ny författare ta vid. Hur lätt tror du att det skulle vara att färdigställa en halvfärdig Sagan om ringen?
Om boken skall skrivas fort kan det vara en god ide att flera jobbar samtidigt. Men hur skall arbetet fördelas? Kan varje person skriva varsitt kapitel? Hur ser vi till att något som händer i ett kapitel inte blir motsägelsefullt senare i boken? Här måste alla medförfattare vara mycket överens från början hur slutresultatet skall se ut. Bäst är att hålla antalet författare så lågt som möjligt. Dock är det så klart negativt i bemärkelsen om något skulle hända en av författarna.
Ibland behöver vi lägga till ett kapitel i en mycket mycket gammal bok. Den ursprungliga författaren finns inte längre. Kapitlet skall såklart passa in obemärkt med befintlig historia och karaktärer. Vad är det för supermänniska som kan klara av det? Den nya författaren gör bäst i att lära sig så mycket den kan om den gamla boken först och försöka sätta sig in hur den första författaren tänkte när den skrev ursprungsverket. Inte lätt! Den nya författaren behöver mycket stöd och utrymme att rätta sina misstag innan den helt kan fylla ut skorna den gamla författaren lämnat över.
Each existing system is a DoS attack on you by dozens of people you may not even know; a booby-trapped palace of ticking complexity time-bombs planted years ahead of your involvement.
Three Laws of Software Complexity (or: why software engineers are always grumpy)
Hur skall andra personer runtomkring författarna kunna hjälpa dom i arbetet? Det är inte deras hjärnor som är fyllda av alla detaljer i boken som är sammankopplade med varandra på otaliga sätt. Det är detta som sätter nivån för kvaliteten på hela verket. Blir jättekonstigt om någon som inte är med och skriver boken bestämmer i till exempel vilken ordning saker skall skrivas i. Eller nekar någon att renskriva direkt när det är färskt i huvudet för att nästa kapitel måste påbörjas. Hur skall en av författarna a priori veta innan boken är påbörjad hur lång tid det kommer ta att skriva kapitel 23?
Det blir inte lätt för den nya författaren att få sin första (sedan innan tidsbestämd) uppgift som består i att: ”i kapitel 12, stycke 34, lägg till en bakgrunds förklaring till varför karaktär #13 överraskade med sina oväntade handlingar i kapitel 3 i formen av en inre monolog”. Vem är karaktär #13? Vad gjorde den i kapitel 3? Hur vet jag att förklaringen jag hittar på rimmar med bokens övriga känsla?
What is required is that the new programmer has the opportunity to work in close contact with the programmers who already possess the theory, so as to be able to become familiar with the place of the program in the wider context of the relevant real world situations and so as to acquire the knowledge of how the program works and how unusual program reactions and program modifications are handled within the program theory
Peter Naur – Programming as Theory Buildin
Snart kanske en av författarna är en AI som kan, bättre än alla andra människor, hålla hela utkastet av boken i huvudet samtidigt. Ber vi den då fylla på med lite egna meningar här och var så kan det nog bli riktigt bra.
Om man frågar en författare om en specifik dialog mellan två karaktärer i kapitel 7 så kanske inte hen kommer ihåg något om detta fast den själv har skrivit det och hela boken själv. Hen kan säkert friska upp minnet lite men måste då först läsa passagen själv och kanske också de kringliggande. Du gissade rätt, så här är det också för systemutvecklare.
Nobody can read the source code of Chrome. Not alone, not as a team. Humans don’t live long enough
Drowning in code: The ever-growing problem of ever-growing codebases
Saken görs oftast inte bättre av att hela boken (programmet) finns beskrivet i en annan form, på en annan plats, oftast benämnt som ”dokumentation”. Koden lär ändå behöva läsas av författaren för att kunna ge ett korrekt svar. Dokumentation kan istället beskriva varför bokens historia är uppbyggd på det sätt den är och anledningen till valen som gjorts. Detta hjälper nya författaren att plocka upp pennan och fortsätta i framtiden.
Programmerare kan vara olika bra på språk. Likt en författare som bara skriver sci-fi kanske en viss programmerare är bäst på system med mycket kartor och platsdata eller e-handel.
Varför står det då bara om massa tekniker i utvecklarannonser? Berätta om syftet med er bok istället. Skulle tro att det faktiskt inte är så många utvecklare som är petiga kring exakt vilket språk som används.
För en författare av barnböcker kan det såklart vara svårt att be den skriva en biografi om Bill gates. På samma sätt kan en senior utvecklare upplevas som långsam när den nu skall koda fakturalösningar om den tidigare endast jobbat med dataspel. Programmeringsspråket och all annan teknik är fortfarande det samma i mina tänkta exempel, men allt annat är förändrat, det är en helt ny bok. Ingen kan sätta sig direkt ner och skriva nästa mening även fast språket är känt.
Jag hoppas att med denna text beskriva hur det är som utvecklare att lyssna in visionerna från intressenter som sedan skall omvandlas till den bok de förväntar sig. Ibland är ”kraven” mycket detaljerade ner på specifika händelser som måste hände i ett visst skede i boken. Ibland är förfrågningarna mer målande. Det är inte helt lätt för intressenterna att veta hur detaljrikt det de säger är. Utvecklaren behöver kunna bolla tillbaka frågeställningar kring hur detaljer den kanske funnit efter läsningar av koden skall kunna passa ihop med andra delar av systemet som kanske inte ens uppenbart berodde på varandra.
Det blir svårt att planera för och säkra hållbarheten i verksamheten om så mycket hänger på få personer som känner till kodbasen intimt. Att AI kan hjälpa nya programmerare förstå en okänd mängd kod kan vara en del av lösningen. Mer AI inom systemutveckling kanske också ger en ”strömlinjeformande” effekt på världens kodbaser.
Utvecklare måste också skriva sin kod så den är läsbar av andra som kanske inte har samma bakgrundsinformation som fanns tillgänglig då koden initialt skrevs. Intressenter behöver något sätt att kunna hjälpa utvecklarna se till att detta efterföljs, hur det skulle kunna se ut i praktiken vet jag inte, mer processer och rutiner är inte lösningen. Koden skall också kunna vara förberedd på att i framtiden kunna flyttas runt och omformas utefter externa förändrade omständigheter.
Jag tror också yrket äntligen behöver mogna och etablera arbetssätt (heuristik?) som sedan inte tummas på. De skall finnas utanför varje hype-cyckel.
Heuristik är en metod, enkel procedur eller tumregel baserad på en kombination av empiriska observationer och obeprövade teorier som kan ge ofullständiga men för situationen tillräckliga och användbara svar på olika frågor eller kunskapsunderlag inför beslut
https://sv.wikipedia.org/wiki/Heuristik
Exempelvis behöver vi bestämma oss för om det skall finnas enhetstester eller inte. Sluta debattera om det och välj en lösning som alla framtidens projekt bara skall följa! En elektriker går inte bananas och bestämmer att den skall minsann välja en annan typ av kabel bara för lusten faller på.
Då kan utbildningar lära ut etablerad software engineering. Idag är det en mix av verktyg från arbetslivet och akademiska förhoppningar.