A refactoring tale

mandag den 17. juni 2024

My approach towards refactoring may have changed over time, possibly because my experiences influence my thought patterns. I also like to tell myself that it’s because I see things in a different light. There’s also a difference in my patterns when I code for money versus when I don’t. There’s a time perspective and an implicit speed factor involved.

When I wrote the software for this blog, there was some source code that I found irritating to look at. However, I knew it didn't matter much to change it since I would be the only user of the software. One of the perks of writing and using your own software extensively is that you can change it when you feel the need arises.

I had a switch statement that I felt was in the way and saw as a potential candidate for a cleaner implementation. Objectively, there's nothing wrong with it—it’s correct and should be easy to understand even for first-time readers of the code.

It’s a central part of a module that deals with parsing comments from one format to a stronger type, into memory, for later use.

I must emphasize that I’m not going into implementation details, and there are plenty of possible fingers to point—point away—but it doesn’t matter much how the code looks one way or the other. It’s the path to a better place that’s interesting.

One of the most interesting aspects of writing software you use over time is revisiting certain elements that you later find nuanced, with my mind searching for a recognition of why it ended up that way. Not because the result is incorrect or not accurate, but simply because I can’t remember it.

In that way, refactoring is also a cognitive challenge. It’s an exercise in wanting to improve something despite a lack of resonance somewhere in the brain.

I write software without perfectionism or delving into the complex or fancy. I know that if I write it correctly the first time, the opportunities to understand and change the code will arise more easily over time. But this is also somewhat dangerous because, even though I might be wiser today than I was yesterday when I look at things with fresh or new eyes, it doesn’t mean the same state will apply over time. I risk changing something that was simple enough into something that is no longer simple enough.

Someone once said that simple code is fast code. This had little to do with clock cycles and more to do with the mental burden of understanding and reading something complex.

So, I have this switch statement I want to get rid of. Today, when I try to write some code differently, I first isolate the situation. I do this by branching out or copying the code into another project environment. From there, I write code until I find my approach too complicated for what the baseline offered. This is on purpose.

As a solo programmer for some software, this is an arrogant stance, and I’m fully aware of it. It’s rare to be alone in deciding something, so I must be careful not to become too single-minded in my approach to how I think things should be. But they need to be easy for me to understand. It’s a quality point for me that I can write some code, come back several months later, and immediately understand why I did something in a certain way. But even that tends to change.

So, I extract the code and place it in a space by itself, and from there, I write some code. My first iteration is a rough draft, a sense of warming up to the possibilities for the refactoring, a mind-activating excersise. What do you want here? Try this. Tighten the screw here. Where does it end?

I write comments for myself to make the history visible for me at a later point. A reference point. It works for me. I like reading comments on thought process during refactoring.

Initially, I thought I would remove the switch statement and make it possible to iterate in a slightly smarter way, so I wrote something over a few hours and then studied the immediate history of the code. But the end result was not good.

I continued my journey. The next experiment I did was with a Dictionary holding an Action. One of the side effects of this code is that it doesn’t change other parts of the code—tests, for example—except for the original switch statement I wanted to remove. I also introduced the Dictionary. Again, the code is commented so I can come back and look at the experiment later.

I take my time, I think. I wonder sometimes, would someone pay for this in a professional setting? The time taken.

But I’m still not completely satisfied. Even though I actually think it’s a fine approach, I’m not sure now. So, I try again.

Now, I move over to a pattern that I consider both well-known and suitable for the purpose, and which I find a possible candidate for improving the code’s condition through refactoring. But there are always trade-offs. I get a bit more code. It’s a bit more complex to read and understand — I might be able to improve that a little. However, I get a better alignment between some structures and new opportunities in the future that might make some things a bit easier. The future is such a fuckery to deal with while programming, so I am by default very hesitant.

I now have three experiments. None of them are really good. None of them are necessary at all to better the correctness of the code. So why would I refator this code ? That has become the real excersise of this thought-process.

I am left with a few experiments that I can study a bit closer and use them to nurture my own arrogance about what I think looks best. If it's more suistainable than the original implementation is of course always a debate. Likeminded and all that. No measurements available.

This is also an excersise and good opportunity to get better at approaching something that seemed like "opionated" and "offensive" code but perhaps wasn’t as bad as it initially appeared. Trying to better something without needing to change it is one the greatest possiblities of programming, becuase unlike in the psysical world, you can throw out all you want without leaving a stain anywhere.

One thing is certain for me. It takes time for me to create what gives, for me, the best results. And I haven’t even touched on what it means to achieve good results, but it’s definitely a rewarding exercise to refactor slowly and in multiple iterations.

And I am alone in this, not part of team where I know I must be a lot more than a singular-minded, arrogant, opinionated programmer with me own small codebase no one gives any notice. But it still feels great!

Complexity Costs Thinking

fredag den 14. juni 2024

I have been pondering on a few context-aware abilities when applying complexity, solving small and larger tasks and what my thought processing is in those situations. I find it an interesting process, balancing complexity while not leaning towards to much cleverness, also catering to a lower common denominator. I'm not sure if my phrasing is entirely accurate, but I'll leave it for now.

My experience tells me that in any field or any task at hand, the expected up-front complexity simultaneously increases the price and costs - monetary, mentally or environmental - either initially or over time. This might seem like a no-brainer, but the question I also want to ask myself is what positive side effects reduced complexity offers.

These are just examples from my own mind, based on where some of my energy has been channeled the last couple of weeks. Take some from your own life.

Since this is about the thought process around complexity the reason for reiterating "easier" should be self-documenting for the reader.

Of course there are a lot of underlying things here that I'm fully aware exist - for instance, fiberglass doesn't grow on trees as wood does, it is a mixture of different other possible complex compontents and therefore there is some kind of cost involved. Or that nuclear power is a more stable base-load technology because it works even when the sun isn't shining or the wind isn't blowing. Fully aware that nuclear offers more concerns in different aspects. But I think you understand what I'm trying to say.

"It is easier" naturally also applies to software. Just as its stubborn sibling "it's better" does.

I find it important, at least for myself, not to view increased complexity as a stamp of higher quality. Quite the opposite, in fact. Just as I don't find myself creating a better outcome by using more complex technology, exclusive ingredients for cooking, or titanium as the boats lanterns.

Again, I am fully aware I use the word "better" here, which in reality has nothing to do with complexity or any of the words antonyms. The point being sometimes you cannot avoid complexity but I do all that I can, with the boundaries given, to minimize it. So unless I am 100% aware of why I need to apply complexity I try hard not to be pressured by its side-effects. I also usually find myself paying a higher price for this applied complexity although it might seem easier and better at first glance.

Everything comes with trade-offs. Is the relative price right ?

Therefore, getting the balance right is also important. In other words, I need to be meticulous about the question of why complexity should not be introduced at a given time, in a given state or context. The thing is that I find it easier to introduce complexity, more so than removing it. I am very conscious of this and try to be aware of whether it stems from experience or another internal or external pressure somehow.

Why do you add complexity ? To introduce simplicity ? Do you know the cost of its abstractions ?

Try using your own statements and try to reflect upon what their "costs" are up-front, and what their relative price is over time. Also what they give back to you. Also in an up-front and over time manner. And don't measure it not only on a monetary level but also on the cognitive, organizational, environmental and social level, etc.

Is it really that different from:

What is the cohesion ?

I find these things also to have a high cohesion with the underlying understanding of an expected outcome. Now I might be approaching something that has to do with knowing, a certainty to why something has to be, or can be, done a certain way. Personally I don't like to guess. I like to be prepared. That goes for when I am cooking, sailing and especially when writing software someone else is paying for.

I can apply my preparation by knowing why I am doing something.

These things are all about knowing. Not guessing. Knowing why I am doing something or knowing why not to do something. They are about collecting as close to facts as possible before I approach them as tasks. How you collect your facts is up to you but there are plenty of cords to pull in any given situation. Collecting evidence and data points, documentating them, is key.

It will slow me down, but I would rather spent my time doing things I know why I am doing than guessing why I am doing.

Another subject which is an offspring of my internal discussion is pace. The software industry seems obsessed with pace - lead time, cycle time, deployments, builds and so forth. That's all dandy. But I find it more interesting being obsessed with the measurement on correctness of an outcome.

Am I doing the right things ? On what basis ? Why do I know this ? Most cases of why in a professional setting are likely of monetary and competing character, and that is perhaps how the world works. But I truly believe quality does not come from a faster pace, but from knowing why.

Pace can help us in many different ways, also as supporting pillar in validating the why. I need to be fast at validating the why, but I cannot be faster than the constraints. Being fast is not a quality in software.

I might be fast, somewhat and sometimes clever, and I perhaps have applied the right amount of complexity. But at the same time I might have done all of this without knowing for what reasons. I make lots of poor reasoning but they are almost always based on not understanding why. And understanding the why is often time consuming and will take you places you didn't think of initially.

At least in my book, reversing something is harder than its introduction. So for me it answers the question about knowing why you are applying possible complexities to places where it is not needed. And anything that is not needed, complex or not, is still not needed.

You can use these questions as a guiding stick for your own questions of reflection. My point only being, with this piece of text, that if you don't know why you are doing something, it's hard to justify the time spent, the money used, the relative cost, the human efforts etc. Don't just do things, understand why they are done.

Du bliver også dine omgivelser.

onsdag den 1. maj 2024

Jeg vågner flere iskolde morgener i træk. Lungerne er fyldt med den kølige luft fra det svagt åbne vindue. Jeg tager mig lige lidt sammen og hiver lamellerne fra, og kigger ud. Det er januar eller februar. De fleste menneskers frygt. Alle sæsoner kan noget. I løbet af et øjeblik fornemmer jeg, om tiden er rigtig til at give det en chance. Det har jeg glædet mig til. Det har jeg ventet på.

Der er korte øjeblikke, en tidlig søndag morgen, hvor byens indre er næsten perfekt. Lyset skal stå rigtigt i tonerne af orange, blå og rød. Det er mit billede. Det er et naturligt punkt i tiden, hvor det står stille. Ellers er det ligegyldigt. Forspildt chance. Det gør det i januar og februar. Det er som at blive forelsket i et billede. Det giver mig en mulighed for at være der, i noget intet menneske kan skabe.

Lige før solen bryder helt igennem fra frostklare nætter og ind i barndommens lys. Der hvor rotationen af jorden samler kræfter og sætter solen på en stav af guld i mund. Bygningerne er forladte, og det emmer af ensomhed. Håndværkernes århundredes arbejde står klart her. Gaderne er tomme, og menneskets udeblivelse er som en gave, og som på lige præcis i denne time kan nydes som en sjældenhed.

Jeg står derinde ved springvandet og ser henover et af byens tårne. Duggen svitser sig af tagryggen, alt er stille, selvom der lige triller en taxa roligt igennem nede ved kanalerne. Solens varme stråler, som det eneste varme i årstiden, strejfer vinduerne, hvor mennesket sover inde bagved. Heldigvis er de ikke ude endnu. Heldigvis kan jeg få dette øjeblik for mig selv. Der er noget foranderligt ved det hver gang. Også kan jeg stå her og nyde det i de ti minutter, det tager, før billedet er malet, og kollektivet er ude og søge efter nyt.

Noget af det bedste arbejde, jeg har lavet, er sket smukke steder i verden. Ikke i isolation, men i omringelsen af naturens gaver. Det er omdannelsen af omgivelsernes energi. Ned i fingrene, op ad halsen, ud i læberne, ud af munden og ind igen. Som en balance bliver jeg rolig og tilsmiles netop af omgivelserne. Naturens gaver. Naturens egen virksomhed. Så tænder jeg computeren.

Nu sidder jeg i en bjerglandsby. Spiste ficattola og lardo i går. Med kold rødvin. De grønne forårsbakker sveder allerede af morgensolen og slår sig blødt og fortsætter så langt øjet rækker. De ryster også nattefrosten af dynen. Hundene gør inde ved naboen, og to køer tygger tålmodigt på noget. Kvinderne trisser rundt i stueetagen med grin og søvndrukne stemmer, som slanger sig langs murene, og glæden breder sig sammen med kaffens syrlige duft.

Skodderne fra vinduet, den metertykke stenmur, det ældgamle og tonstunge skrivebord venter bare endnu et menneskes store tanker. Det er forventningsfuldt. Ikke ligesom åbne kontorlandskaber, glorificerede papirnussere og de samme enige ord.

Det er placeret med intelligens. Det tager et helt rum. Der er ingen, som har placeret det op ad muren eller væk fra den høje kip. Det er placeret, så omgivelserne, når jeg kigger ud af de store vinduer, giver mig alt den tryghed og skønhed, der kan optages af det rigtige menneske, som bor inde i mig selv.

Nogle gange bliver omgivelserne eller indtrykket for meget. Så må jeg slukke. Tage tilløb. Få styr på omgivelserne og de skønheder, de naturligt bidrager med. Studere dem og lade dem indøve sine tendenser. Jeg ved udmærket godt, det er ikke dem, som skal ændre sig. Det er mig. Det er mig, som skal åbnes op og blive modtagelig. Det kan tage flere dage at vænne mig til det, og alt imens står computeren og blinker af mig i håb om, at det er i dag, vi skal i gang.

Som et utålmodigt redskab, der på et tidspunkt vil så langt ind i mig, suge mig ind i sine umådelige tidsskrifter af kildekode, skrevet af andre mennesker, som ligesom mig, søger efter de bedste omgivelser for deres kreative og lykkelige ønsker om at kreere, og yde sit til at hjælpe mig med at skubbe videre.

Vi skal lave noget, siger den til mig. Sæt mig i gang. Få din tålmodighed til at vige. Bare tryk lidt på mig og se om der kommer noget ud. Den er grim, når den står her, tænker jeg. En død ting, der er komplet ubrugelig uden et menneske. Den har ikke en chance i disse omgivelser. Børstet stål og plastik, var det virkelig det bedste, de kunne finde på? Når jeg har det sådan med den, så ved jeg, jeg ikke er klar endnu. Så må jeg vente. Jeg ved præcis, hvorfor jeg er her, det skal måles i den målestok, ikke maskinens.

Noget tid efter sidder jeg på en bænk af træ, i en hytte på en strand, ved det nordlige Stillehav. Det er eftermiddag, og det har været roligt hele dagen. Kokosnødder og krabbeskjold har bare aldrig rigtig været mig. Det er da hyggeligt. Men det er for nemt. Havet bruser op, og himlen bliver mere mørk af storm. Formationerne i skyerne er som dommedagsmalerier, der ville portrættere et skibsforlis, en engel på vej i krig, eller mennesker, der tror mere på sig selv frem for solidaritet. Her passer det godt ind. Nu sker der noget. Lad det bryde ud for fuld skrue.

Jeg føler det komme til mig, imens jeg står der og vågner. En løsning. Jeg taber tiden. Den er mere simpel, end jeg havde forventet, den ville være. Så pisker det ned fra oven, og sandet dufter anderledes friskt nu. Det blander sig med maden fra den anden side af vejen, men jeg fejer det væk igen. Havet lægger sig et øjeblik, og det er, som om alt bare går fuldstændigt i stå. Det bliver med ét køligere, og varmen forsvinder med ét fra huden.

Alle de dage med streger på notesblokken tynger mig ikke længere. Tænder for maskinen. Ind i systemet, gransker det lidt, nærmest kirurgisk ved jeg præcis, hvor jeg skal hen. Min hukommelse har klarsyn. Også sker der bare ting, som ingen kan måle eller forstå. Gnisterne sprænger fra kommandolinjen, sletter lidt, ind her, ud der, videre. Og jeg bliver herinde, indtil udmattelsen er fuldkommen, og løsningen findes, men også syntes noget, der har taget et øjeblik, hvor virkeligheden er, at den har taget mere fra mig, end jeg synes, den er værd.

Vi kører igennem et landskab, hvor de laver Sauternes. Efterårssolen sover lur i markerne, og vi er på vej mod vest. Ud til vandet. Ud til Biscayen. Vi har en gammel sag af en Citroen, fire døre og heldigvis noget manuelt at trykke og trække i. Jeg ville kunne skifte både motor og radio i den her. Jeg har for længst gennemskuet idiotien - klasse er ikke noget, der følger med - og digitalt finder jeg også sjæleforladt. Det sluger allerede rigeligt af mig. Jeg kan ikke stole på mig selv, når jeg ikke kan kigge ud over skærmen.

Da jeg om aftenen træder ind i byen, er der svampe, som gror ud af væggene. Sorte svampe. De dufter som cognacen, de har liggende under jorden. En sideeffekt. En sikkerhedsrisiko. En fejlende test. En økonomi. Kan jeg købe en god brandert her, tak?

Nede om læ, ombord på Karma, er lyset tændt fra et par lamper. Lugerne lukker en lille smule månelys ind. Det er messinglamper, og deres lys er mere guligt end hvidt. Kortbordet har været min arbejdsplads i nogle dage nu, konfiguration af diverse, log ind, log ud. Duften af lak, lyden af fald mod masterne, det rolige vand om morgenen og fyrets brummen har alt sammen været mit udgangspunkt. Det jeg ikke selv har været magthaver over, har givet mig mere magt over mig selv. Jeg har lavet noget godt arbejde her, tænker jeg. Omgivelserne har igen dannet billedet for mig. Jeg har kunnet placere mig i det og bruge det til de rigtige ting.

Monotomt, men brugbart. Jeg er kommet igennem den ene udfordring efter den anden. Som perler på en snor. Som fuldt hus med et sildefang. Et par sjuser om aftenen og ti timers søvn. Der er altid bekymringer, men cirklen er ved at være fuldendt for denne gang. Konsekvenserne af vores afmagt og manglende stillingstagen til, hvad vi ellers kunne have bedret tiden med, snævrer sig naturligvis bare mere ind. Men nu, da dagene er gået, og tiden er væk til at gøre det om.

Som en afslutning, en sløjfe på vores færd, deler vi et par flasker vin fra området. Spiser noget svine-rillettes på brød, bager et spidskål i ovnen og taler sagte om strategierne for, hvordan vi kan takle de næste udfordringer. Andre menneskers konstante ønsker fra os andre er som en rekursiv funktion.

Du behøver ikke mere, siger jeg til ham. Kaptajnen og min gode ven. Næsten alt det, vi har lavet her, er godt. Den friske luft. Solen. Vandet. Miljøet. Resultaterne. Hvad mere vil du have, spørger jeg ham? Han svarer med et grin og en åbenlys bevidsthed om, at der altid er mere. Mere. Mere. Mere. Jeg giver ham ret og ser lidt rundt i det svenske kvalitetsbyg, som er blevet for dyrt at bygge i dag, fordi de færreste har tid til at bruge det, det koster. Hovedet har låst sig fast på et facit, og nu er det bare at finde de næste muligheder, der kan sætte stregen under det.

Energien er forsvundet ud af tankerne. Computeren har overtaget. Informationer som en brandhane uden lås. Tasterne bliver ved med at klapre, og menneskene er i modsætning til om vinteren på gaden. Frem og tilbage. Det er blevet sommer, og vejret er fantastisk, men der er ikke mere ro af den grund. Alt er stadig en mulighed. Som om det ikke kan gå hurtigt nok, at skulle slutte spillet uden at vide, hvornår det starter. Vi er også tilbage. Tilbage i møllen. Tilbage i maskinen. Tilbage i tilbage. De omgivelser, som ikke giver os det bedste, vi er, men som uden at lægge mærke til det, bliver en del af.

Vi kigger på hinanden og ved godt, vi ikke kan lære nogen noget af det, vi selv har fundet ud af. Det er vi nødt til at have for os selv. Som en hemmelighed, der ikke er hemmelig. Men med bevidstheden om, at minderne ikke er noget, som kan trænes af maskinen. Eller gengives i bøger, som ikke er skrevet af os selv. Og det smiler vi af og glæder os over, at inden alt for længe, så er vi afsted igen.

Stavekontrol er svært. Børnene vil hellere spille. Jaro, Hamming, Damerau og Levenshtein.

onsdag den 24. april 2024

"Ordet 'sykel' på dansk oversættes til 'le'. Det er en gammeldags term for en type håndredskab, specifikt en lille sigd, der blev brugt til at klippe korn eller græs." - Hilsen ChatGPT.

I et forsøg på at afhjælpe en ung drengs udfordringer med at stave, tænkte jeg, at det samtidig ville være en fornuftig udfordring at lære noget om strengalgoritmer. Dette kommer delvist fra nogle samtaler omkring spisebordet om aftenen, hvor drengene udviser stor interesse for, hvordan en computer i virkeligheden fungerer.

De forstår – ligesom størstedelen af menneskeheden – ikke, hvorfor det skal være så svært at programmere et spil eller en bot, der kan spille WoW for dem, så de kan læne sig tilbage og senere nyde profiten af deres profilsignifikans – og også købe de sko og biler, de ser på TikTok og hører om i raptekster fra Biggie Smalls eller bare fra TV2s Fantastiske Toyota.

Ak, der kan være frustrerende at acceptere, at nogetr er svært når det fremstår nærmest lige foran en.

De fleste af os tager vel for givet, hvilken hjælp vi egentlig får, når vores computer udøver stavekontrol for os. Hvordan kan det gå til, at en computer forstår, at når vi forsøger at stave til "cykelhjelm", men i stedet taster "cykelhjælm", at noget inden i maskinen "forstår", at "æ" skal være et "e".

Hvis du ikke er blandt den sjældne race af algoritmedesignere eller på anden vis har studeret grundlæggende "computer science" – jeg har ikke – så er du måske også forundret over, hvordan en algoritme bærer sig ad. Vi er ofte ikke eksponeret direkte for algoritmens muligheder; de er ofte pakket væk fra os, ligesom når du åbner Word og staver forkert – du ser ikke direkte, hvordan et BK-tree eller et Bloom-filter fungerer på skærmen. Det er abstraheret væk fra dig, så du ikke skal bekymre dig. Medmindre du naturligvis ikke kan lade være.

Min logik er anderledes end din, og sådan er det at være menneske. Vi anskuer udfordringer forskelligt, nogle mere end andre. Men heldigvis er der mennesker, som har fundet gode løsninger på fælles udfordringer, så vi ikke selv behøver at tænke alt for længe over dem, medmindre – igen – at vi synes, de på en eller anden måde fortjener noget opmærksomhed.

At beskæftige sig med "Tokenization", hvor vi har med mere tekst at gøre, og faktisk også noget kontekst, end blot et enkelt ord, har jeg ikke beskæftiget mig med her. Men det gør nødvendigvis ikke udfordringen mindre.

Prøv i stedet at få din logik til at forstå, hvad der skal ske inde i et computer-program, når du har stavet "sykeljælm" og ikke "cykelhjelm". Vores egen hjerne staver det korrekt, hvorfor mon ?

Vi ved begge godt (medmindre vi lider af ordblindhed), hvad det korrekte ord er; "cykelhjelm". Men hvordan ville vi ændre ordet til det rigtige ud fra den forkerte sekvens ("sykeljælm")? En computer kender ikke på forhånd ordets korrekthed, så den er nødt til at gætte sig frem ud fra den sekvens, den har fået at arbejde med. "Sykeljælm", tænker computeren, hvad gør jeg nu? Hvilke ord "minder" ordet om?

Vi er ude over, at ordet er korrekt. Så når computeren slår op i ordbogen, hvor alle danske ord er stavet korrekt, finder den ikke noget. Øv! Så langt, så godt, så vi skal have fat i en eller anden algoritme for, hvordan ordet kan "transformeres" indtil noget, vi kan genkende.

Efter et par omgange med vores favoritsøgemaskine kan vi blandt andet finde en fremragende post af Peter Norvig, men vi finder også hurtigt ud af, at for at kunne arbejde med vores forkerte sekvens "sykeljælm" skal vi over i noget "distance ensarthed" i forhold til, hvor meget en sekvens minder om en anden sekvens. Jeg kunne godt have sat mig ned og brugt en masse tid på at gøre som Peter Norvig, men jeg ville aldrig have nået et lignende resultat af den simple grund, at min viden omkring emnet er for lille og jeg tvivler egentlig også på, at jeg er ligeså smart.

Jeg brugte rundt regnet et par dage på at læse op på, hvordan de mest gængse "distance ensarthed" algoritmer fungerer, og det er som alt muligt andet i programmering: trade-offs omkring performance, kompleksitet og tid. Jeg kan efterhånden forstå, at det på ingen måde er nemt eller ukompliceret at bygge software, som kan udøve en stavekontrol, som du for eksempel finder i Word.

Wikipedia siger om "Edit Distance": "In computational linguistics and computer science, edit distance is a string metric, i.e., a way of quantifying how dissimilar two strings (e.g., words) are to one another, that is measured by counting the minimum number of operations required to transform one string into the other."

Jeg bider her mærke i "measured by counting the minimum number of operations". Hvis vi bruger det i vores eget eksempel her, kan vi måske finde ud af, hvor meget forskel der er på "sykeljælm" og "cykelhjelm".

En tilsyneladende velkendt "edit distance" algoritme er Levenshteins, som i helt korte træk lyder: "The Levenshtein distance between two words is the minimum number of single-character edits (insertions, deletions, or substitutions) required to change one word into the other."

Læg mærke til, hvordan og ud fra hvad algoritmen arbejder: (insertions, deletions, or substitutions).

Så hvis vi lige prøver at bruge den algoritme, og lige for en stund leger, vi kender den korrekte sekvens "cykelhjelm", så vil algoritmen fortælle os, at de to sekvenser har en "edit distance" på 3, fordi det kræver tre ændringer til inputsekvensen at ændre den til den korrekte sekvens.

Input: sykeljælm. Test imod: cykelhjelm.

(1 insertion, 2 substitutions, 0 deletions).

Det er som sagt tre ændringer.

Jeg forsøgte initielt også med Hamming-distance algoritmen men opdagede hurtigt, at den forventer, at de to sekvenser er af samme længde, hvilket vi ikke kan garantere.

Der er en enkelt ting ved den oprindelige Levenshtein distance algoritme, som vi potentielt godt kunne tage højde for, og det er det, der kaldes "transpositions". Det betyder, at algoritmen også forsøger at bytte om på hver karakter i en given sekvens. Wikipedia beskriver kompleksiteten heraf således: "Adding transpositions adds significant complexity. The difference between the two algorithms consists in that the optimal string alignment algorithm computes the number of edit operations needed to make the strings equal under the condition that no substring is edited more than once, whereas the second one presents no such restriction."

Frederick J. Damerau bliver beskrevet på Wikipedia: "In his seminal paper, Damerau stated that in an investigation of spelling errors for an information-retrieval system, more than 80% were a result of a single error of one of the four types."

Derfor findes der en Damerau–Levenshtein distance algoritme, som er en udvidelse af den oprindelige Levenshtein distance algoritme, men som også tager højde for "transpositions". Initiativt ville jeg helst lave en løsning, der kunne stave bedst muligt på baggrund af betydningsbærende danske ord, altså ikke ord som f.eks. "hvad", "hvem", "stop" eller "kat", men mere ord som "kokkeskole", "psykolog", "lærerinde". Jeg har dog ikke testet simple ord med nogen af disse algoritmer.

Vores eksempel med "sykeljælm" og "cykelhjelm" ændrer ikke ved antallet af ændringer. Det er stadig 3 ved brugen af Damerau–Levenshtein.

Hvis det ikke allerede er faldet dig ind, så handler det om at have så få ændringer som muligt for at kunne kvalificere de bedste gæt på, hvilket ord der er korrekt.

Lad os løbe igennem et par forskellige tests, hvor vi bruger en given kandidat og en liste med ca. 650.000 danske ord.

Levenshtein resultat med sekvensen "sykel":

Fair nok, det er jo et gæt. Men jeg tænker allerede helt stille og roligt, vi måske kan bruge det resultat og gøre det bedre. Måske.

Vi prøver lige med Damerau-Levenshtein og "sykel". Giver samme resultat.

I begge tilfælde, med hver af vores valgte algoritmer, er resultatet 1.

Hvad nu hvis vi antager et øjeblik, at når resultatet er 1, så forsøger vi at kvalificere vores gæt på baggrund af antallet af korrekte karakterer i sekvensen "sykel" sammenlignet med antallet af karakterer i de sekvenser, som vores valgte algoritme har foreslået.

Så "sykel" vil altså minde mere om "cykel" fordi de to sekvenser deler 4 karakterer. Det er en naiv tilgang og vil ikke fungere særlig godt i praksis, men vi kan altid kassere resultatet, såfremt ensartetheden ikke er over en vis procentdel. Jeg forsøgte også at give resultatet af Levenshtein algoritmen til en Jaro algoritme, men her fik jeg "skel, cykel, sekel" tilbage.

Inden jeg gik i gang med at kigge på udfordringen, vidste jeg godt, at det ikke ville være let at lave. Og jeg er fuldstændig klar over, at jeg kun lige har dyppet min storetå i streng-distance algoritmerne, så min læring har været ret fundamental og relativt ny. Men det er præcis derfor, disse ting er gode og lærerige at begive sig ud i.

Til min forbavselse, bliver "sykel" til "sekel" i min version af Word.

Koden til mine eksperimenter finder du her.

Lad min AI ringe til din AI.

tirsdag den 16. april 2024

Jeg beskæftiger mig faktisk sjældent med de popkulturelle facetter af min branche, men jeg går da op i massefænomener, fordi jeg finder psykologien og incitamenterne bag dem interessante, og hvordan disse fænomener har det med at påvirke en form for konsensus selvom denne er baseret på noget jeg ikke helt kan kvalificere.

Jeg vil godt tage på mig at jeg ikke er særlig klog og jeg vil også acceptere, at mit sind vil gøre meget for at forsvare sig selv omkring det faktum, fordi ellers ville jeg pludselig føle mig mindre værd og det kan menneskets hjerne ikke rigtig lide.

Disse forhold inden i mig gælder ikke bare teknologi, det gælder også politik, sejlads og kultur.

Hvis man virkelig gerne vil forstå noget, er det min holdning, at den bedste mulighed er, at man skal forsøge at ændre det, man ønsker at forstå. Det er for eksempel sådan, store dele af videnskaben fungerer: Man tester sine hypoteser, validerer sine resultater og derefter undersøger man, om de understøttes af uafhængig evidens og om de fører til nye verificerbare teorier eller love.

Det har de fleste naturligvis hverken tid eller mod på. Min ringe formodning må være at vi nok havde været et lidt andet sted, og brugt vores samlede kollektive energi en smule anderledes, havde vi været bedre udviklet som mennesker. Men det er vi ikke. Og det er en af skuffelserne ved menneskesheden. Og det er den øjensynelige og fuldstændigt klare retning vi tager - se historien gentage sig selv overalt du kigger hen - som langt inden vi vælger den retning ikke bare er fjollet og dum, men ikke uden for forventningen af hvad vi rent faktisk formår.

Heldigvis findes der mennesker som er klogere end mig og dig, og som har viet dele af deres liv til at studere en vis form for progression, og hvordan vi kommer videre fra et stadie til et andet. Det er f.eks. sådan noget som videnskabskvinder og mænd går op i. Det skal vi andre mindre begavede naturligvis støtte op omkring fordi uden dem var vi mindre end vi er idag.

Bevares, der findes selvfølgelig også masser af pseudo-videnskabsfolk og holdninger fra disse, som er meget nemmere at forstå end det de rigtige vidensskabsfolk kommunikere, fordi pseudo-videnskabfolket formår at kommunikerer omkring noget komplekst, der er i virkeligheden er endnu mere komplekst end også de forstår.

Jeg er ikke engang klog til at være pseudo-videnskabsmand, til tider ikke engang menneskelig, så i må nøjes med min ringe holdning.

Men heldigvis kan jeg læse. Og historiebøgerne kan naturligvis også give os en masse indsigt.

Leon Festinger skriver i sin bog fra 1957 "A Theory of Cognitive Dissonance" bl.a. således:

“A man with a conviction is a hard man to change. Tell him you disagree and he turns away. Show him facts or figures and he questions your sources. Appeal to logic and he fails to see your point.”

Forståelsen af AI er i min optik et glimrende eksempel på Leon Festingers udsagn. Her har vi muligvis med et massefænomen at gøre, hvor det er gætterier, gentagelser og menneskets forunderlige tro på, at når vi har oplevet noget progression et sted, så må den da også fortsætte i nogenlunde samme hastighed som den allerede har været fremskyndet med (Læs kapitel 10, "The Role of Social Support: Data on Mass Phenomena").

Lokkefugle og NP-hard udfordringer.

(Hvis et problem er NP-hard, tyder det generelt på, at der ikke er nogen kendt effektiv måde at finde en løsning, der fungerer for alle mulige tilfælde. Dette gør disse problemer særligt udfordrende og betydningsfulde i forskning, da løsning af dem eller endda forbedring af, hvordan vi griber dem an, kan have stor indvirkning på forskellige områder inden for videnskab og engineering.)

Iris van Rooij er "Professor of Computational Cognitive Science" hos Radboud Universitet i Nijmegen, og har bl.a. været forfatter til nogle interessante artikler, som tager udgangspunkt i spændet mellem det menneskelige kognitive og den nutidige teknologiske fremdrift omkring såkaldt AI.

Denne artikel "Reclaiming AI as a theoretical tool for cognitive science" har mere end et par indsigtsfulde forklaringer, som forsøger at gøre et par ting rimelig tydelige for dem, der befinder sig i Leon Festingers psykologiske teori omkring "Show him facts or figures and he questions your sources".

Men lad mig alligevel bruge noget tid på at fremføre et par ting fra Iris' forfatterskab.

"...This means that any factual AI systems created in the short-run are at best decoys. When we think these systems capture something deep about ourselves and our thinking, we induce distorted and impoverished images of ourselves and our cognition."

Nå for pokker, så vores ringe kognitive forståelse af hvad der foregår spejler sig i de systemer vi bygger. Who would have thought.

Jeg kan sagtens forstå, folk falder på halen over en statistisk model, der gætter på, hvad den skal svare på et spørgsmål. Det er nemt, det går stærkt, det giver et resultat. Det taler også direkte ind i tidsånden, hvor kvantitet – som ihverfald er udbredt og trives fint i den professionelle teknologiindustri – er vigtigere end at skabe fundamentalt stabile innovationer samt organisationer, der kan leve i mange år.

Inden jeg fortsætter ud af den kvantitets-tangent, så er her et uddrag fra Iris' medforfatterskab fra artiklen ovenover. Du læser sikkert ikke artiklen, fordi du mener du allerede har styr på det, men prøv at læse den, den er god.

alt text

Jeg siger ikke Iris har ret. Jeg siger bare at nogle videnskabspersoner har brugt tid på at validere nogle hypoteser og deres resultater ser interessante ud.

Jeg har mennesker omkring mig, som arbejder for virksomheder, der på en eller anden måde forsøger at retfærdiggøre brugen af millioner af kroner på, at AI skal gøre deres eller deres kunders forretning mere værdifuld. Jeg har bare ikke set skyggen af pålidelighed, hvad deres indsats angår.

Men lige præcis det handler ikke så meget om AI, det handler nok mere om, at "Software stadigvæk bliver bygget på antagelser, anekdoter, idolisering og af hierarkiets prestige."

Nogle af os ved godt, problemet ikke er AI.

Peter Hunt Welch har skrevet en sjov, men også rammende rigtig essay med titlen "AI is not the problem".

"...Even if 50,000 of us just got fired, there are tech entrepreneurs pouring out of Stanford ready to borrow money from their parents and develop fresh methodologies for tanking the economy. With few bumps, the last two decades have enshrined software engineering as the career immune to the cataclysmic shocks it creates in the world at large."

Han fortsætter

"ChatGPT was the first hint of a crack in the fortress. Could we, too, be devalued due to technology? No."

Og herefter fortæller Peter så hvorfor han ikke tror på, at os der er professionelle IT-folk bliver arbejdsløse; "Actual use of ChatGPT for articles or essays or code will produce more of the content that made its output subpar, and achieve little besides accelerating the homogenization of mediocrity."

Middelmådighed er udmærket strategi hvis du skal brute-force dig igennem. Personligt tvivler jeg bare på at det er innovation der er gemt i den.

Det er først i afsnittet omkring DALL-E, han folder sig lidt mere ud i en retning, jeg holder af, fordi jeg heller ikke kan se mig fri for den kognitive dissonans, og hans evne til at overbevise mig, acceptere jeg som en brist i min egen psykologiske verden.

"Computers have been generating art in some fashion for ages, but now it looks like human art. I never worried about this in terms of art because art is about expression and communication. It is inextricably bound up in the history and philosophy of itself and what it means to be human."

Og næste paragraf synes jeg endnu mere om.

"Unfortunately, there’s that certain sector of the population for whom art is a commodity for shallow consumption, accompanied by an industry happy to sell at scale. In this context, art is not expression: art is packaging. Nobody wants to pay premium fees for packaging, and now nobody will."

Prøv at tage den en gang til også erstat "art" med det, du laver.

"Unfortunately, there’s that certain sector of the population for whom MUSIC is a commodity for shallow consumption, accompanied by an industry happy to sell at scale. In this context, MUSIC is not expression: MUSIC is packaging. Nobody wants to pay premium fees for packaging, and now nobody will."

Det udsagn gælder også programmøren, forfatteren, fotografen, psykologen, lægen, kokken, pornostjernen, politikeren, din hund og den studerende. Og ikke mindst dine børn. Hvis du ikke står for noget, er det nemt at falde for det meste. Kvaliteten får ikke lov at spirre i et rum hvor presset for kvantitet er størst.

Og I en verden, der helliger sig kvantitet og hurtige løsninger, er der mere på spil, end vi lige skulle tro. Men som jeg skrev tidligere, som mennesker er vi kollektivt ikke kloge nok til acceptere vores egne begrænsninger.

"Suppose an individual believes something with a whole heart; suppose further a commitment to this belief, suppose irrevocable actions have been taken because of it; finally, suppose evidence, unequivocal and undeniable evidence, that the belief is wrong: what will happen?" - Leon Festinger, A Social and Psychological Study of a Modern Group that Predicted the Destruction of the World.

Polpetta compileren på stranden i Mondello.

tirsdag den 2. april 2024

Vi var ankommet til Palermo om aftenen. Det var sensommer. Det dunkle orange gadelys drev af murene, de sprækkede brune og grå facader, udhakket og solmørnede, fortalte hemmeligheder fra de sidste århundreder. Varmen imellem dem var intens. Lige fra arbejdsfolkets stemme til kvindernes diskussioner på de små balkoner. Der hænger altid tingeltangel fra de skide vinduer, tænkte jeg, og den stakkels jomfru syntes ikke at kunne få fred fra en andens jomfrus øjne.

Hotellet, vi var tjekket ind på, var bestyret og drevet af nigerianske bådflygtninge. De var drevet i land på Lampedusa og derfra fundet til Sicilien. Det var et æstetisk flot hotel, men en forretning. Æstetik og forretning. Det harmonerer sjældent, men de rige kan ikke se forskel.

Bådflygtningene talte bedre italiensk end dem, der var født med italiensk i passet. De var blevet stolte italienere. Mon ikke, tænkte jeg, at det kræver en naturlig intelligens og et dygtigt menneske i den anden ende at lykkedes. Historien på Sicilien er, at der altid har været mange forskellige religioner og baggrunde. Historien oppe nordpå er, de er bange for forandringen. Et dygtigt menneske i den anden ende.

De fik mig til at føle mig mere fattig. Lysende øjne kiggede på mig, og jeg vidste godt, at jeg et eller andet sted ikke var i stand til at fremføre den samme bevisbyrde som de bar rundt på.

Og de var ikke engang blevet sindssyge. Sikke en bedrift, tænkte jeg. De fortjente det pludseligt mere end os andre. Når du aldrig har mistet noget, sagde jeg til min kompagnon, bliver du aldrig i stand til rigtig at vide, hvad du har.

Jeg ringede til Matteo og fortalte om vores ankomst og hvor vi var i byen. Jeg bad ham stille, når han havde muligheden, fordi som sagnet går, er ethvert sted mere værd med en lokal som dirigent. Det gjorde han så, som et italiensk urværk gør bedst. Så vi gik bare selv ud i aftenen.

Vi forlod hotellet og vandrede mod Monte di Pietà. Duft af sandsten og en fortagende varme blandet med høje stemmer og kropslige fagter. Hestevogne og blæseorkestre var ved at lukke aftensolen helt ned, og temperaturen føltes mere bleg. Vi havde været i solen i flere måneder ombord på Rubin, så vi mærkede kulden fra de varme dage på samme måde som de indfødte. Sejladsen hertil havde været helt rolig, og de små øjeblikke for sig selv var stadig den vigtigste valuta. Scirocco-vinden, bevares.

Nu sad vi her under et Peroni-telt og drak Marsala, og jeg glædede mig over grunden til, vi faktisk var ankommet. Når man er på ferie, under institutionen, i de 7 uger man nu råder over, udebliver de lærerige stunder. Der skal mindst 2 måneder non-stop til for at nærme sig en fordybning. Ikke så underligt, de dumme bliver dummere, og de kloge bliver klogere.

Historien havde udspillet sig nogle år forinden, længere nordpå. Vi kom altid nordpå i enten maj eller september, når de værste ryk af turister var overstået, når havnepriserne var overkommelige. Vi er ikke fattige, men vi har bare ingen penge.

På et vinotek ved navn Nebraska lidt udenfor Camaiore sad vi og spiste og drak kold rødvin.

Her gik historien iblandt nogle tidligere italienske kolleger - som jeg havde hjulpet med nogle knap så dogmatiske tekniske ceremonier, og jeg havde forsøgt at lære dem en smule om processernes kontekst i forbindelse med, hvor i et software-forløb man befinder sig. Det var alt sammen i forbindelse med et stykke software til en industri-protokol og endnu en abstraktion ovenpå en ligegyldig innovation, der i sidste ende alligevel handlede om konkurrence og hverken solidaritet eller samarbejde.

Men på stranden i Mondello, lidt udenfor Palermo, fandtes en restaurantejer, som grillede blæksprutter på åben ild, og hvis søn havde lavet restaurantens "kasseapparat". Noget med en egenudviklet compiler og et lille sprog, som efterfølgende gjorde det muligt at afvikle et program ovenpå en Intel 4040-chip. Han havde i hvert fald opkaldt compileren "Polpetta" efter sin mor (man kan ikke hedde Polpetta). Ingen vidste, hvad drengen hed. Men faren hed Piero.

Historien var god. Den blev også fortalt godt. Det hører sig alligevel til sjældenhederne, tænkte jeg, at nogen kan fortælle historier om tekniske bedrifter, uden at fortælleren selv finder fortællingen værende noget af det vigtigste andre skal begaves med. Folk og deres arbejde, tænkte jeg, de er begravet i lyserødt fór, men hvis de kiggede op, bare et par dage, se, at der faktisk også var verdner af azurblåt.

Den aften sad vi med cikaderne på repeat på Nebraska i Camaiore, efter en tur på den offentlige strand ude bagved pinjeskoven i Viareggio. Jeg var kommet på Nebraska, siden jeg havde været lille barn, og nu var det Stefano og ikke den gamle ejer Giuseppe, der fortalte historier. Giuseppe havde smidt folk ud, hvis de stillede for mange spørgsmål til mulighederne eller ville have salt til maden.

Historien om restauranten i Mondello, der var blevet kendt af de lokale for et "kasseapparat", som kunne prutte om prisen, men mindst ligeså meget for drengen, som havde bygget den. Noget med, at den betalende gæst selv skulle stå med maskinen i hånden og taste de priser, som stod på regningen, og dernæst kunne selvsamme trykke på en tast, som enten ville få maskinen til at forøge eller mindske prisen. Og alt sammen ville ske, fordi en ung drengs bedrifter og hans ungdommelige udvikling af en compiler til en chip. Drengens far havde været så glad for sønnens passion og hans iver, at den absolut måtte bruges i restauranten.

Jeg vågnede lidt op igen. Fysisk i Palermo.

Vi bestilte mere vin oppe fra vulkanen. Den har et udtryk af splittelse og menneskets ubetydelige vandren i naturen, når du står oppe i højderne og ser den forstenede lava, der tårner sig op over dig. Fuldstændig sort. Men Nerello Mascalese er alt andet end det. Masser af liv. Tænk nogle gaver at få fra sådan et sted. Gaver, man kan drikke.

Matteo var ankommet og havde fundet ud af, at vi skulle mod havnen og spise kalvetunge og derefter spille kort på den anden side af gaden. Ovre hos de gamle. "Fantastisk," sagde vi alle til hinanden og gik smilende hånd i hånd ned mod vandet.

Piero stod i hjørnet af ude-køkkenet på hjørnet af Via Delfini og flåede blæksprutter. Der var mange blæksprutter. De er klogere end de fleste mennesker, tænkte jeg. Derinde bagved vidste jeg, Polpetta eksisterede et sted, og jeg begyndte pludseligt at lide et afsavn til mine sene aftentimer, imens Paul Oakenfold fulgte mig derind, derind i flowet af programmeringens uendelige muligheder.

I arbejdet var mulighederne skiftet ud med mennesker, der vitterligt troede, de gjorde en forskel, med tusinder af linjer for betaling til lige at kunne klare tusinde mere, og som aldrig fik den samme fløjelsbehandling som den ægte kærlighed i kvaliteten udsprunget fra ens bedste energi.

Mondello var en skøn og på visse områder, en rå strand. Vi havde fire år forinden været der med Claudio og hans mor, som hverken røg eller drak, men som inden vi forlod sandet og vandet, både havde cigaretter i lommen og var blevet halvberuset. Vi havde uden, vi vidste det, gået forbi det sted, jeg nu så frem til at få en bid af. Mondello havde, ligesom bådflygtningene og historien fra Nebraska, taget røven på mig.

Da jeg endelig mødte Gianni, drengen der med sine computer-fingre havde bygget det, jeg gerne vil se, sker det på baggrund af en telefonopringning, som jeg ikke har set komme. Men Matteo har - fordi jeg har talt om det mere end en gang i nostalgiske vendinger - fundet ud af, hvor og hvem drengen er, og han har med lille portion armod i stemmen indvilget i at vise sit "kasseapparat" frem for os fremmede interesserede.

Gianni er 15 år gammel, og han har været begravet i sin computer, siden han var 8 år, fortæller han. Han har interesseret sig for den hemmelige verden inde under skærmen, siden jeg første gang tændte den, og som alle os, der har forvildet sig ind i en verden, som de færreste forstår, forstår jeg udmærket, hvor han kommer fra, selvom der er over 20 års aldersforskel på os.

Gianni fortalte mig med en lille undren, at han ikke erindrede, hvorfor det blev en Intel 4040-chip, men at han som 12-årig, i forbindelse med en ferie, havde fundet et "kit" hos en tjekkisk computerforretning, som også kom med hardwaren omkring en regnemaskine; display, knapper osv.

Også havde han fundet instruktionssættet for chippen knap så udfordrende - han viste mig den patinerede fysiske manual - men bestemt ikke nemt, og forsøget med at programmere mere komplekse ting havde fejlet for ham pga., mente han, antallet af bits til rådighed gjorde større operationer mere besværlige, end hvis han havde brugt en 8-bit chip. Så det var "bare" blevet til en simpel regnemaskine i begyndelsen.

Efter noget tid med hans nye regnemaskine begyndte Gianni at kede sig og besluttede sig for at udfordre foretagende og derfor bygge et lille sprog (DSL) og dertil en compiler i C og Python. Han kaldte compileren Polpetta efter en af hans mors søndagsretter, og navnet var netop opstået, fordi hun med stolthed havde serveret "Polpette al sugo alla siciliana" en sen aften, hvor hans udfordringer med programmeringen havde gjort ham tosset. Hans mors aftensmad havde reddet hans humør.

Gianni fortalte mig med hans teenage-jomfruelighed, at den afmagt, når noget ikke fungerede, ville holde ham vågen om natten og gøre ham kort for hovedet. Muligvis ud af hensyn til husfreden fandt hans far det morsomt, at hans program på det tidspunkt ikke kunne regne rigtigt, og så en mulighed i at bruge genstanden i restauranten, når betalingen fra gæsten skulle falde. Derfor endte Giannis "kasseapparat" hos restaurant Piero, og dens til tider finurlige resultater havde også underholdt gæsterne på restauranten, når der skulle betales.

Vi sad i Giannis fars restaurant, og jeg lyttede naturligvis til hans vidunderlige historie. Det er passionen, tænkte jeg, drømmen og ønskerne om at kunne omsætte tanker til virkelighed, der gør, at man lytter mere til nogle mennesker end andre. Rigdommen kan forsvinde med alderen, fordi forventningen æder sig ind fra noget, du ikke selv kan kontrollere - medmindre du er opmærksom på det fra begyndelsen.

Når det kommer fra unge mennesker, tænkte jeg, kan misundelsen opstå, fordi tiden i rummet er ubalanceret, og de har statistisk mere tid tilbage end en selv. Det er afgjort et forbilledligt mentalt maleri af, hvor stolt jeg bliver på de unges vegne - den sult Gianni havde - men samtidig også muligheden for at forberede dem på, hvor mange ligegyldigheder der venter dem fra en anden verden. Så min eneste anke til Gianni var, at han skulle passe på sin passion og lade den drive ham, men passe på, når andre ville have del i den for en afgift, der ikke harmonerede med den rigdom, den virkelig gav ham. Så hellere gå tiggergang, fortalte jeg ham.

Vi takkede derpå alle på restauranten for en formidabel aften og især for det minde til livet, vi var blevet beriget med. Vi skulle afsted ombord på Rubin nogle dage efter, og vi havde mere end en ting, der skulle forberedes inden. Da vi forlod Sicilien og sejlede af det Tyrrhenske hav op mod Ligurien, vidste jeg, at vores historie ville passe godt ind, når vi endnu engang stod på Nebraska lidt nord for Viareggio, i Camaiore. Det var der, vi satte kursen mod.

Lighed på arbejdspladsen.

tirsdag den 12. marts 2024

Alan Kay er citeret for at have sagt: "Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future—it’s living in the present. I think the same is true for most people who write code for money. They have no idea where their culture came from—and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made."

Se bort fra Alan Kay's kommentar omkring det at skrive kode. Tænk i et større perspektiv.

Det er et slående udsagn, som jeg har tænkt over i flere år, og som belaster min evne til selv at forbedre omstændighederne, men som også presser min egen solidaritet omkring det, at være samarbejdsvillig i mit professionelle virke.

Mine næsten 25 års erfaring peger, for mig, udelukkende på, at den manglende progression - at år efter år helliger vi os til hurtigere og billigere resultater - handler mere om, hvordan vores institutioner er indrettet, end om at det er mennesket som ikke ønsker at samarbejde eller opnå en følelse af tryghed og lighed.

Der er ikke meget ro eller tid til samarbejde når omdrejningspunktet for success er forankret omkring individualisme og konkurrence. Så hvordan kan en institution forvente, at mennesker kan udtænke innovation, finde på gode løsninger sammen med andre, og bruge tid til fordybelse når timeglasset konstant bliver mindre? Det er svært at få øje på en umiddelbar positiv retning der afviger, fra en eller anden form for menneskelig tragedie.

Det er naturligvis ikke kun i min egen branche tingene forholder sig således. Og historien gentager sig selv. Politik. Krig. Langbrug. Fiskeri. Uddannelser. Og alt det andet du selv kan komme i tanke om.

Mennesket bliver ikke klogere fordi tiden går, det er der ingen evidens for, så hvis man gentager sig selv forbliver man i gentagelsen.

I Nancy G. Levesons bog "Engineering a Safer World" skriver hun bla. om luftfarten: "The average time to translate a basic technical discovery into a commercial product in the early part of this century was thirty years. Today, our technologies get to market in two or three years and may be obsolete in five. We no longer have the luxury of carefully testing systems and designs to understand all the potential behaviours and risks before commercial or scientific use."

Se hvordan det er gået med Boeing. Se hvordan de mennesker der har viet sit professionelle virke se det smuldre fordi omdrejningspunktet er hurtigere og billigere. Det dør folk af.

Se på dit eget professionelle virke. Hvor er innovationen til en bedre og mere tryg verden?

Alt skal altså gå hurtigere. Og til hvilken pris? Og hvordan står man af, samtidig med at man skal overleve?

Vi har indrettet os på en måde, hvor solidariteten og samarbejdsvilligheden ikke blot handler mere om selviscenesættelse og grådidhed, men hos langt de fleste mennesker udløser det en psykologisk forsvarsmekanisme, som bunder i overlevelse.

Du har ikke mulighed for at ændre noget i den virkelighed der hersker udenfor dit eget ansvar - og end ikke der kan vi føle os helt trygge - men du kan forsøge at klare dig eller tilpasse dig. Det er bare ikke progression.

Jeg tror, det, hr. Kay siger, samtidig har en dyb korrelation til bl.a. udbrændthed og sorg hos mennesker. Der findes en form for overgivelse. Vi forsøger hele tiden at klare og tilpasse os. Men vi forbedrer os ikke rigtig, og jo mere vi distancerer os fra solidariteten og ligheden des værre bliver det desværre.

Alan Kay siger i en anden forbindelse: "...there's no concept of progress in our genes...we have an enormous set of genetic apparatus to make us good copers. Anything happens to us, we can find a way of being resilient...and adapting to it. We're copers and adapters...so when we come up against difficulties, our tendency is to cope with these difficulties. It's like working for a company, go into a company and the company seems sort of screwed up. Maybe you can quit, you can cope, but your chances of actually changing the company are very low because nobody will listen to reason."

Så folk lytter ikke rigtigt. Men hvorfor skulle de også det når andre ikke lytter til dem?

Individualisterne bekæmper hinanden i køen til den samme success. Hvis du står af der, bliver du efterladt med en følelse af, at du har misforstået konceptet, udefra set. Presset er enormt hos de mennesker der har købt ind i det dér.

Det avler samtidigt en kultur af mennesker, som ikke føler sig inkluderet eller beriget, og uden de samme chancer for at gøre den forskel, de i virkeligheden rummer og ønsker, fordi institutionen er bygget, som den er.

Og lige netop ulighed er så meget på tale i disse år. Ulighed mellem mænd og kvinder. Ulighed mellem mennesker. Hvad med uligheden på arbejdspladsen?

Der, hvor de fleste voksne mennesker bygger deres identitet og bliver en del af det institutionelle sammenkog, hvor netop hurtige og billige resultater belønnes, men hvor du også bliver målt og vejet på, om du er i overensstemmelse med institutionens værdier, og hvor det former dig som menneske, fordi indoktrineringen er sket fyldest. Det kræver jo ikke ligefrem en ph.d. for at gennemskue, at den lighed kun eksisterer, hvis du ikke forsøger at ændre den.

...maybe you can quit, you can cope, but your chances of actually changing the company are very low because nobody will listen to reason..."

Det er ikke relevant om du er mand eller kvinde. Hvis du ikke tilpasser dig det som institutionerne forventer - som har intet at gøre med solidaritet eller lighed - så kan du bare tage bagdøren.

Så hvis du tror dit professionelle liv er demokratisk og dine chancer er lig andres, så tager du altså fejl. Men du skal jo klare dig, og hellere dig en de andre ik'.

Myten om "det er bare et arbejde" hører ingen steder hjemme, fordi det er på det selv samme arbejde forventningen fra andre ikke handler om lighed. Fordi hvis det virkelig var lighed man søgte så gjorde man netop institutionerne mere solidariske. Problemet er bare at det ikke harmonere med den verden vi har indrettet.

"The important thing is not to stop questioning. Curiosity has its own reason for existing. One cannot help but be in awe when she contemplates the mysteries of eternity, of life, of the marvelous structure of reality. It is enough if one tries merely to comprehend a little of this mystery every day." - Albert Einstein

En note til mig selv ligsom til dig er, at man skal passe på med, hvad man tror på. Det kunne jo være, det var forkert.

Microservices udstiller organisationens kommunikationsstrukturer, hvilket medfører, at enhver svaghed og styrke i den, bliver synlig.

søndag den 11. februar 2024

Microservices er en ubarmhjertig arkitektur.

Ikke kun fordi den stiller andre krav til de teknologiske aspekter der differentierer den fra den traditionelle organisations systemudvikling.

Men i højere grad fordi den udstiller organisationens design men samtidig forventer klarhed over, hvor de enkelte services er forankret, i hvilke teams.

Microservices er blevet udskammet og rost, ligeligt. Udskammet af teknologister fordi designet ikke kan stå alene, teknologisk. Rost fordi, organisationen der rent faktisk formår at ændre kommunikationsstrukturene imellem deres teams, også er dem som får mere ud af designet end blot en teknologisk edge.

Microservices primære succes-parameter handler næsten udelukkende om hvordan kommunikationen flyder i organisationen, ift. hvordan kontrol og forankring placeres.

Microservices repræsenterer således et udfordrende paradigme, primært fordi grundlaget for succes i høj grad ikke blot afhænger af teknologisk professionalisme, men i større graf afhænger af de udøvende teams autonomi i organisationen.

Derfor er nødvendigheden eksplicit omkring hvordan organisationens kommunikation flyder.

Dette er jeg personligt overbevist om er et must, selv for meget små organisationer.

Et system er en helhed sammensat af flere dele. Forstil dig vi ser systemet med udgangspunkt i software eller andre menneskeskabte ting.

Hver af disse dele er designet, udviklet og bygget et eller andet sted i en organisation, og højst sandsynligt omkring et domæne, noget viden og erfaring.

Og hver eneste menneske som er involveret i denne process vil blive kognitivt påvirket ved at indgå i dets arbejde.

Gestalt refererer til en helhed bestående af flere enkelte dele. Helheden betragtes som større end summen af de enkelte dele, der danner gestalten. For eksempel er en rytme mere end summen af de enkelte slag, og en melodi er mere end summen af de enkelte toner. Kilde

Selv en lille del i et system kan have stor betydning. Ofte bruger jeg en analogi omkring en motor. En motor er et system bestående af mindre helheder, som igen består af mindre dele.


Her er en brændstofsdysse. Det kan vi betragte som en helhed. Den udgør et facit som er brugbart hos andre helheder og givetvis i forbindelse med andre systemer. Den er samtidig opdelt og samlet af mindre dele.


Motorens mange dele handler rent teknisk om at lade den indgå i samarbejdet med andre dele og sammen udgøre en enhed - en mindre enhed - men som samtidig kan spille en rolle i en større helhed af et system (en motor f.eks.).

Men om helheden af en brændstofsdysse sidder i en diesel-generator, en græsslåmaskine eller en industri-ovn er ikke systemets ansvar at bestemme. Omverdenen må altså også beslutte hvor en helhed i deres eget system, giver mening - men de bestemme over helheden.


En af mine egne maskiner set fra siden; luftindtag, vandpumpe, starter-motor, manifold etc. Brændstofdysserne sidder forbundet på hver det som ligner omvendte "U'er".

Hver lille del samarbejder til at blive noget større, som potentielt igen bliver til noget endnu mere.

Men det er også her, vi kan begynde at betvivle vores hidtidige opfattelse af helheden af systemet som værende forkert.

Hvis vi antager, at den enkelte del kun bør indgå i én systematisk sammenhæng, hvorfor skulle vi så ikke integrere delen fuldstændig i helheden? Hvad er fordelen ved at bygge noget som kan "leve" i en anden sammenhæng ?

Se på motoren og overvej så at jeg ikke kan skifte vandpumpen (den lille bronze del nederest til venstre) uden at jeg også skal skifte hele blokken.

Vandpumpen suger vand ind. Og pumper vand videre. Det er ansvaret for den helhed. Det er dens facit. Hvordan resten af motoren bruger vandet er vandpumpen hverken interesseret eler ansvarlig for.

Vandpumpen på billedet kan f.eks bruges på motorer af Nanni, Volvo Penta, Perkins og Mercedes.

Vi kan altså opfatte vores services som egne helheder. Det er selvfølgelig ikke et krav. Vi kan også betrage dem som værende interne dele som i sidste ende udgør en helhed.

Om helheden kan anvendes - ikke kun af ét system - men også i og af flere andre, er det som gør helheden i stand til at differentiere sig, og ikke have en nær relation/kobling til andet software.

Dette svarer dog ikke på spørgsmålet om, hvorfor microservices kan være et fordelagtigt design. Men det fører os måske lidt nærmere til erkendelsen af, at en del, som kan fungere som en helhed - se på brændstofsdyssen - kan udvikles uden at skulle forholde sig nært til hvordan andre helheder eller systemer. Og hvis man ikke skal forholde sig til det så er det mindre at fylde hovedet op med.

Untitled (10)

Herover er der dele som udgør enhender.

Untitled (11)

Helhederne bliver måske en del af to forskellige systemer.

Forestil dig det sådan, at hvis virksomheder, som fremstiller dæk til biler, også var nødt til at designe og udvikle aksler og undervogne for at få deres dæk til at passe på bilen, ville det så være fordelagtigt ? Næppe.

Det er ikke ligefrem en subjektiv antagelse jeg fremfører, at jo mindre kompleksitet mennesket behøver at forholde sig til, desto større er sandsynligheden for at ens hjerne har en bedre chance for danne overblik og tænke mere klart.

Når en organisation beder sine ansatte om at bygge et system, sker der ofte det, at de ansatte starter med at forsøge at forstå helheden omkring systemet.

The human mind is incredibly averse to uncertainty and ambiguity; from an early age, we respond to uncertainty or lack of clarity by spontaneously generating plausible explanations. What’s more, we hold on to these invented explanations as having intrinsic value of their own. Once we have them, we don’t like to let them go. Kilde

I begyndelsen kan det muligvis være nemt nok, fordi systemet endnu ikke er stort nok til at skabe betydelige kognitive udfordringer for medlemmerne. Men hvis du har bygget software længe nok, i teams af mere end én person (og selv da er det svært, når tingene vokser), så opstår der pludselig alle mulige udfordringer, som faktisk har meget lidt at gøre med teknologi. Derimod meget at gøre om organisation, deraf kommunikationen også ganske enkelt psykologien hos mennesket.

Untitled (13)

Kruglanski conceptualizes our need for cognitive closure as consisting of two major stages, seizing and freezing. In the first stage, we are driven by urgency, or the need to reach closure quickly: we “seize” whatever information we can, without necessarily taking the time to verify it as we otherwise would. In the second stage, we are driven by permanence, or the need to preserve that closure for as long as possible: we “freeze” our knowledge and do what we can to safeguard it. (So, for instance, we support policies or arguments that validate our initial view). And once we’ve frozen? Our confidence increases apace. Kilde

Vi skal derfor designe systemer omkring, at en del eller en helhed bør forblive tilstrækkeligt lille, således at både systemet, organisationen, teamet og den enkelte person kan rumme det. Ja det er meget at bede om.

Her kan vi, istedet for at betragte de største kasser som helheder for deres bærende dele, også betragte dem som værende teams, med et ansvar for helheden og dets bærende dele. Hver farvet kasse er nu et team der bygger det som farven har ansvar for.

Untitled (10)

Små helheder er ofte tæt knyttet til noget, der har større betydning end den enkelte helhed selv.

Når man bygger noget, der skal kunne fungere afkoblet, men samtidig interagere med andre helheder og systemer, skal denne helhed altså kunne bidrage med mere end bare at være en helhed for sig selv.

Jeg bliver gerne at sige, at det er den enkelte enhed som indeni sig selv har ansvaret for, at manipulere de data som er vigtig for enhedens jeg. Hvad der dernæst udstilles på den baggrund er op til modtageren at undersøge om er brugbart og nyttigt for sit dets eget jeg.

Untitled (15)

intet der ikke er en intern del af helheden skal kunne manipulere med den.

Microservices skal give nogle forbedrede evner hos organisationen, hvoraf nogle af mulighederne er:

En anden evne er, at en del eller heldhed kan repræsentere en forretningsmæssig værdi eller mulighed. For eksempel på samme måde som vandpumpen, der kunne anvendes af mange forskellige motorer og ikke blot én.

Derfor, hvis vi ønsker at bygge mindre, for bla. at øge transparensen omkring kompleksiteten, forandre kommunikationsstrukturer og dele ansvaret op hvor sømningerne i domænet også splitter, så kan vi ikke længere organisere eller kommunikere på samme måde som hvis vi ville bygge systemer med ideen om, at alle dele skulle være forankret på samme sted.

Der følger trade-offs med til alle valg. Så uden først at acceptere at der naturligvis også følger trade-offs med i valget af et microservice design, så vil dit valg føre til nye frustrationer som blot vil være anderledes. De frustrationer vil højst sandsynligt komme fra organisationens forsøg på at adoptere nye måde at kommunikere på, eller dens umodenhed til samme.

Hvordan ser jeres kommunikationsstrømme ud ? Hvordan bygger I software på baggrund af den ? Tegn den op så i kan se hvordan strømningen er, men lad den være baseret på jeres eget data.

Personligt har jeg aldrig set en microservice arkitektur fungere, uden at der til grunds var dannet teams der ejede dele og små helheder, snarere end hele systemer eller store helheder.

Jeg har set det være en rigtig modbydelig tilgang mere end en gang. Der førte til skyttegravskrig imellem teams, elfenbenstårnsarkitekter der valgte at prøve at gøre det forfra - bare i andre teams. At koblingen imellem helhederne var så "tight" men menneskerne så adskilt, at den asynkroni og det mandat der skulle gøre ansvaret mindre hos det enkelte team, istedet mangedoblede den og samtidig udpenslede organisationen som værende både umoden og til sidst perfid.

Jeg ved godt det lyder vildt og dramatisk men det kan blive grimt når ens organisation faktisk viser sig patologisk, og ikke vil formår at tage ansvar for dets valg.

Teams skal kunne operere inden for rammerne, trygheden og autonomien for, hvad deres del og mindre helhed gør det muligt for dem at tilbyde andre og andet.

Hvis en organisation ikke formår at adskille disse begreber - dele, helheder, og systemer - både på et højere abstraktionsniveau og især i den praktiske udførelse, løber den en risiko for at blive overvældet af services, som reelt set kun er løst forbundet software centreret om teknologi frem for domæner, teams, og forretningsegenskaber.

Jeg har set interne service-registre i virksomhed, udviklet i hundredevis, som kunne alt fra at sende, emails, booke aftaler eller registere parkering. Problemet med den slags services er, at de ikke udgør en del af en større helhed som er forankret omkring et doæne i forretningen. De lever bare et passivt liv og ingen tager rigtig ansvar for dem af samme grund.

Jeg ville aldrig anbefale organisationer, der opererer ud fra traditionelle organisationsstrukturer, at forfølge en idé om at udvikle systemer baseret på microservices. Det kræver en vis modenhed fra ledelsens side - især omkring autonomi i de enkelte teams syntes at være meget svært at accepterer - men ofte også en teknologisk forandring blandt programmørernes tankevirksomhed, da de givetvis skal begynde at forholde sig til nogle andre begreber og tilstande, end de højst sandsynlig har været vant til.

Software bliver stadigvæk bygget på antagelser, anekdoter, idolisering og af hierarkiets prestige.

onsdag den 31. januar 2024

software: en potentiel mulighed for en virksomhed eller organisation for at understøtte målsætningen omkring enten at innovere, øge den forretningsmæssige økonomiske værdi eller på anden vis være bedre stillet ift. effektivitet og produktivitet.

software: eksterne eller internt vendte produkter, features, komponenter eller systemer, som har til formål at adressere ovenstående.


Da Jan og jeg for nogle år siden indledte vores samtaler og diskussioner omkring vores erfaringer og udfordringer i og med organisationer, som bygger software, var omdrejningspunktet, at mulighederne for at supportere og lære organisationer nogle bedre vaner i forbindelse med softwareudvikling, var ret store.

En af de udfordringer, vi begge har og havde været så stor en del af tidligere, er det faktum, at software ofte bliver drevet med udgangspunkt i en "god idé", ofte enten udklækket hos en leder eller et stort ego, men hvis hypoteser aldrig bliver valideret i den virkelige verden.

Vi var begge overbeviste om, at modenheden i organisationer og virksomheder skulle testes og valideres, fordi vores hypotese omkring ovenstående ikke var andet end vores egen pendant til "god idé", og vi vidste naturligvis heller ikke, hvad den virkelige verden ønskede sig, før vi involverede os i den.

Vores egen forventning var, at vi i det mindste kunne få taletid omkring vores budskaber hos virksomheder, der set udefra kæmpede med at få det meste ud af deres softwareorganisation.

Vi har aldrig nogensinde villet agere på samme vis som den typiske konsulentvirksomhed, hvor mantraet i grove træk alt for ofte er "gør som vi siger, fordi vi siger det" eller "I gør det forkert, I skal gøre sådan her". Det er en pinlig bevisførelse og på mange måder en arrogant og manglende kontekstforståelse, som desværre lever i alt for stor udstrækning i vores branche.

Vi havde selvfølgelig antagelser omkring vores hypoteser. Nogle skulle også vise sig at være korrekte. Men grundlæggende skulle det vise sig, at vi hurtigt blev udfordret af, at stort set ingen var interesseret i at blive fortalt, at deres initiativer og idéer ville nyde godt af at blive udfordret et andet sted end virksomhedens tankeland.

"Jeg har bygget software i 30 år uden at have talt med en eneste bruger," - softwareudvikler ansat i en softwarevirksomhed.

Vi ville ind tidligere.

Når vi oplevede teams på nært hold og betragtede deres udfordringer sammen med dem, var deres udfordringer sjældent af synderlig teknologisk karakter. Bevares, kompetente (tekniske) mennesker, som forstår, at målet for deres arbejde i virkeligheden ikke handler om at skrive kode eller tegne streger imellem systemer, skal man naturligvis gøre sig en smule umage for at tiltrække.

Men vi ville ind længe før den første linje kode, den første tegning på en tavle eller første skærmbillede blev udfærdiget. Vi ville ind der, hvor ledelsen begyndte at tro på, at virkeligheden for deres initiativer og idéer stemte overens med det tankeland, de befandt sig i.

Og det ville vi udelukkende for at spare dem for den potentielle hovedpine og de langstrakte perioder, som ud fra vores erfaringer fortalte os, at tiden brugt på endeløse møder, rygklapperi og monologer fra dem med mest senioritet, var tid, der ikke kom igen. Vi ville ind der, hvor vi kunne hjælpe med at udfordre deres billede af virkeligheden og hjælpe med, hvad det rigtige var for dem at bygge.

Hvorfor noget er en god idé, er jo et valideringspunkt, som skal udstilles og testes, ikke fordi idéen er dårlig, men fordi idéen er værdiløs, før den resulterer i noget virkeligt i den virkelige verden. Du kan ikke se ind i fremtiden, og selvom du gerne vil have ret, så er det en yndefuld egenskab hos mennesker at hvile i, at det er helt okay at tage fejl og derefter komme videre. Deraf "fail fast".


Af samme grund eksisterer der i rigtig mange virksomheder en forberedelse, som er fuldstændig uforløst, fordi initiativer ofte har det med at udspringe mere på baggrund af en leders stjerner på skulderen end på baggrund af at have brugt energi på at forberede sig og validere sine hypoteser, så det man producerer rent faktisk også stemmer overens med det, som virkeligheden efterspørger.

Vi ville ind der, hvor vi fik mulighed for at supportere og lære organisationen og lederne nye vaner, som de i forlængelse af os kunne bruge i deres egne organisationer.

Lederne blev et nøgleord her, fordi vi fandt ret hurtigt ud af det, som vores egen hypotese blev valideret ud fra - at det er de færreste organisationer, som er designet og drevet på baggrund af nutidige muligheder om at skabe et bedre miljø og fundament for ens softwareorganisation. Vi fandt ud af - vi havde allerede en antagelse herom - at langt størstedelen af organisationer til stadighed er designet på en måde, som helliger enkeltpersoners position frem for den samlede enheds kapacitet.

Kommunikation er i dag helt og aldeles gratis. Hvorfor ønske sig en leder, hvis rolle det er at kommunikere oppefra og ned? Hvorfor have en leder bestemme, hvordan et team skal adressere en given problemstilling?

Der ligger et enormt ego gemt i, hvordan de triangulære organisationer er designet, og det er også vores klare overbevisning, at det er en kæmpe fejl at lade enkeltpersoner udøve sit ansvar på baggrund af idéen om, at det de foretager sig, må være rigtigt, fordi ellers ville de jo kunne opleves som inkompetente.

Hvis en enkelt person er så dygtig til at komme med svarene, så lad vedkommende sidde ved klaveret og spille med, indtil sangen er færdig.

Vi arbejdede sammen med et par virksomheder og i teams, som har været ret fantastiske i deres evne til at organisere sig og forankre det mandat, autonomi og ansvar fra en kompetent ledelse. Det har været en gave at opleve, hvordan nogle organisationer evner at skabe en sådan arbejdsplads.

Men vi har fundet det afsindig svært at komme ind på det tidspunkt, vi gerne vil ind på. Idéer har det nemlig med at være sejlivet, og jo flere klap på skulderen ophavsmanden modtager, jo større energi får idéen. Vi har simpelthen ikke været gode nok til at få vores argumenter plantet, især omkring det at skulle forbedre organisationens evne til at forberede sig "inden vi går i trykken".

Default er den gode idé.

Vi havde specielt et engagement, som skulle vise sig at være en lærerig oplevelse. Vi har aldrig haft et ønske om nogensinde at gå ind i et udviklingsforløb med mindre, der foreligger en afklaring omkring hvorfor det forløb eksisterer, og hvad grundlaget for beslutningerne er baseret på.

Vi har hverken tid eller lyst til at bruge andre folks penge på at lave noget, som ikke kan understøttes med data fra virkeligheden. Det har været hele vores eksistensgrundlag ikke at omdanne en såkaldt god idé til noget, der alligevel ikke gav mening.

Så vi starter aldrig med at tegne diagrammer eller designe systemer på en tavle, eller sidde i møder og snakke om, hvem vi skal købe hvad fra og hvornår.

Vi arbejder med mennesker i den virkelige verden, og lader dem skyde med skarpt på baggrund af de hypoteser, der opstilles, så vi på den måde kan få indsamlet evidens og dannet grundlag. Det er sådan, det er nødt til at være, taget alle de forgangne års fejlede initiativer i betragtning.

I det her tilfælde – vores lærerige eksperiment – havde vi indledt en dialog med en virksomhed, som var så forblændet af deres egen idé, at selvom de godt kunne se værdien i at få den valideret i den virkelige verden, så var deres tro på idéen så stor, at de valgte at udvikle produktet i stedet for først at teste dets hypoteser af.

Det fik os alligevel til at indse og begribe omfanget og alvoren omkring idéens magt og dens tag i menneskerne, der er investeret i den. Det var jo ikke fordi vi ikke havde set det før – vores data viser os, at 80% af alle virksomheder, vi har været en del af, bygger software på den baggrund – men det kommer alligevel bag på os, hvor vigtig ens egen virkelighed synes at blive brugt som drivkraft for en idé.

Det har samtidig også vist sig flere gange, i andre kunderelationer, at når et team finder det udfordrende at vide, hvilken retning noget skal bevæge sig i, så default'es der ofte til den "gode idé", som så alligevel senere viser sig at være ingenting værd.

Af samme grund mener vi, fordi vi har været i de her forhold mere end bare et par gange, at det er langt mere værd at forberede sig langsommere end at bygge hurtigere. Du kan ikke snyde dig til evidens eller bruge ude-af-kontekst data fra andre. Du er simpelthen nødt til at teste og validere dig frem til dine egne data omkring den kontekst, I befinder jer i, og det kan spare dig for mere end bare tid og penge.

Vi anser os selv som en del af den bevægelse, som udover at være kompetente og passionerede omkring vores virke, opfatter og oversætter den agile filosofi og kultur som noget, der handler mere om at blive klogere på det, man bygger, frem for at gætte sig frem igennem lukkethed og ubarmhjertige vilkår. Altså handler det om at bygge det rigtige ved hurtigt at kunne modtage feedback fra den virkelige verden.

Jeg er et eller andet sted rigtig ked af, at agile har fået så dårligt et "rep", men med indførelsen af de ellers så smukke og pragmatiske muligheder, i hvad der syntes at være uforanderlige organisationer, er de på sin vis blevet misbrugt som en knækket løftestang, med troen på, at kulturændringer kan læres igennem kurser, tegninger, certificeringer og titler.

Kvalitet går langsomt men I vil hele tiden gøre tingene hurtigere.

Loven om "leaky abstractions" får hvert år en stadig større betydning for alvoren om, i hvilken retning branchen bevæger sig, når der laves investeringer i forbindelse med at forbedre den produktive og effektive tilstand for alle virksomheder, som bygger software.

Prøv for sjov skyld at se på, hvad der er blevet talt om på diverse konferencer, samt hvilke litterære værker der er udgivet de sidste 10 år, og frem til i dag, også dan dig dit eget billede af, hvor langt du egentlig synes, vi som branche har rykket os. Læg dertil din organisations forandring oveni.

Hvis du med fuldstændig ro kan sige til dig selv, at med flere af de samme abstraktioner, er vi blevet bedre, så chapeau til dig. Godt gået. Really!


Udfordringen er bare, at jo flere abstraktioner vi smider ovenpå hinanden, des mere skal vi forholde os til. Så selvom abstraktionen synes at gøre os i stand til mere, er der i samme ombæring mere, vi skal jonglere med. Så med en pseudo-forøgelse af produktivitet eller effektivitet medfølger der et stadig større kognitivt og økonomisk pres.

Jeg finder det glædeligt, når de mennesker, hvis litteratur jeg ynder at læse, eller hvis karriere jeg finder nogenlunde tidsløs, til stadighed beviser, at de "nederste" abstraktioner stadig er dem, som er mest betydningsfulde for, hvordan tingene reelt hænger sammen. Men jo længere jeg bevæger mig op i abstraktionerne, jo længere bevæger jeg mig imod popkulturens karakteristika om fuckability, larm og hurtige resultater.

På den måde finder jeg meget lidt tvivl omkring, at Jan og jeg desværre har været klemt op i et paradoksalt hjørne. De mennesker og virksomheder, der godt ved, hvordan man gør, har nemlig ikke brug for sådan nogle som Jan og jeg. Dem, som vi mener godt kunne bruge vores viden og data, enten leder de forkerte steder, eller også ønsker de, bevidst eller ubevidst, at mærke frustrationerne igennem deres egne erfaringer, og for sig selv.

Udviklingen af teknologi går stærkere, end vi når at forholde os til den, og det er svært at få øje på - bl.a. taget loven om "leaky abstractions" i betragtning - hvordan flere abstraktioner skal hjælpe os til rent faktisk at blive bedre. Det gælder ikke kun IT; det er ligeså udtalt en bekymring andre steder i verden. Bare kig op og se, hvem der forsøger at sælge dig mere teknologi.

Personligt finder jeg kvalitet andre steder end i teknologiens verden. Kvalitet for mig er en helt anden størrelse, og det kan være betagende at sidde og betragte historien og kurverne omkring den.

Når jeg nu sidder her og kigger på de materialer, som er brugt, og det håndværk, som er udført, på mit svenskbyggede sejlskib fra 1986, så bliver jeg hele tiden overrasket over, at nogen har formået at lave noget, der "lever" i så barske omgivelser (vand, salt, sol og vind), og som stadig er så holdbart og driftsikkert. Det er kvalitet.


Eller når jeg studerer min instruktionsbog til min Mercedes OM636, og det gør jeg flere gange om året, så falder jeg fuldstændig i staver over, hvor detaljeret og veldokumenteret det produkt er. Det er for mig en enestående oplevelse at sidde der og prøve at forstå, hvordan man kunne samle et team, og rent faktisk komme i mål med at udvikle noget så velfungerende og smukt. Det er kvalitet.

Jeg har derimod absolut ingen forventning til, at vi alle sammen skal hellige den samme forståelse eller ønske om kvalitet. Det ville være en yderst arrogant forventning. Men den laveste kvalitative fællesnævner må i en professionel setting adresseres, inden man bygger software, fordi den, udover at have betydning for selve kvaliteten af resultatet, også har en betydelig indflydelse på de mennesker, som deltager i forløbet omkring og i udviklingen.

Kvalitet kan udover at være en holdning også samtidig være en skrøbelig tilstand, som kræver, at en organisation udviser kurage og tryghed overfor de mennesker, hvis tilstedeværelse og energi de trods alt har et betydeligt råderum over, og som der er en forventning til, kan stemple ind.

Lederens rolle

En sideeffekt af de ting, Jan og jeg har oplevet i vores virke sammen, har bl.a. været, at de ting, som har været et velkendt negativ i årtier, stadig i stor udstrækning bliver brugt som støttekrykker, også selvom branchens kompetente og velansete litterære og udøvere har formidlet viden og statueret grundige eksempler på, at de er mindre gunstige ift. at drive udvikling af software.

Vi har måttet sande, at organisationer til stadighed er forankret omkring et triangulært organisationsdesign, hvor levn fra den traditionelle "switchboard manager" stadig har til formål at kontrollere og kommandere.

Organisationer har haft den udfordring, siden kommunikation er gået fra at være dyrt til at være gratis. Og de sidste 15 år har kommunikationen altså været gratis. Derfor har en af lederens primære roller ændret sig, fra ikke længere at agere bindeled imellem teams eller ledelse, sidde i toppen af trekantens snævreste linjer og kommandere nedad og rapportere opad.

Sådan ser verden ikke ud i dag, og jo før man accepterer det, des mindre vil det gøre ondt på ens organisation. Inden General Motors gik konkurs, bad en VP i GM om, at man fotograferede hele fabrikken hos Toyota, fordi GM måtte kunne opnå den samme mulige succes, hvis de blot kopierede Toyota-fabrikken.

At kommunikation er gratis, har de færreste organisationer grundlæggende accepteret – der er stadig alt for meget institutionel indoktrinering og hierarki (jeg kunne godt tale om ægte diversitet samt inklusion) – og det koster til stadighed virksomhederne rigtig dyrt.


Vi har set og været en del af teams, som er blevet bedt om at vente på, at et andet menneske i virksomheden er blevet færdig med sit eget arbejde, før et 10, 20, 80 personers team kunne komme videre.

Vi har oplevet, at teams skal sende support-emails for at ville udgive sin software.

Vi har oplevet, at et team ud af mange teams har bestemt, hvordan alle andre teams skal strukturere deres arbejde.

Vi har deltaget i agile transformationer. Sågar DevOps transformationer. Vi har endda selv brugt ordet digital transformation, fordi vi troede, vi kunne sparke døren ind hos dem, der alligevel ikke vidste, hvad det betød.

På et tidspunkt vil medarbejdere, som sidder fast i flaskehalse, magtesløshed, endeløse ligegyldige agenda-løse møder om tankeland, venten på såkaldte nøglepersoner, ikke længere acceptere, at de ikke kan udnytte deres eget voksne råderum og tage affære igennem deres egne kommunikationsstrukturer.

Så når samfundsdebatten også er koncentreret om spørgsmålet om, hvorfor vi skifter arbejde som aldrig før, og virksomheder har hamrende dygtige mennesker væltende ud af bagdøren, så tror jeg ikke, det er forkert at pege på det her som en betydelig udfordring.

Det har heldigvis vist sig at fungere langt mere effektivt at lade sine teams og medarbejdere eje ansvaret og have mandatet til selv at kunne gøre det, de mener er bedst for den forretningsmæssige egenskab, de har fået stillet i sigte.

"Organisationen", som de fleste af os har været i berøring med som professionelle, er i Jan og min lille bog, mega udfordret. Ikke blot fordi den ikke længere formår at bevise sit værd på et organisatorisk plan, men fordi verden er så forandret, at vi som mennesker ikke længere kan se os selv navigere i sådan et hierarki.

Da jeg mødte Said, en tidligere lektor på CBS, og min tidligere og helt igennem fantastiske kollega i Microsoft, sagde han til mig: "I er 10-15 år for tidligt på den, der er ikke mange som forstår, hvad det er, I forsøger."

Vi koncentrerer os ikke synderligt om fremtiden, vi koncentrerer os om, hvad vi har nu og her, og hvad der kommer i morgen, må vi forholde os til dér.

Vi har fået valideret et par af vores egne hypoteser igennem dialog og smørrelse med vel omkring hundrede virksomheder.

Vores idé om at få virksomhedens initiativer ud af tankelandet med målet om at:

Hvis du vil have flere detaljer, må du tage kontakt til mig.

Du kan ikke skalere agile. Et par af SAFe's misforståelser.

onsdag den 24. januar 2024

Det er en udbredt misforståelse, at man kan skalere agile. SAFe, et populært produkt i denne sammenhæng, falder ofte i denne kategori. Men at dvæle ved dette postulat er unødvendigt. Forståelsen af agile, som det er beskrevet i det agile manifest, er afgørende her. Det handler om en grundlæggende indsigt og accept af agilitet, snarere end en dogmatisk tilgang.

Agilitet er omgivet af visse dogmatiske synspunkter, hvilket jeg kunne diskutere længe. I softwareudviklingsforløb er det almindeligt at støde på såkaldte agile purister, der argumenterer med udsagn som "du gør det forkert" eller "det er også en del af agile".

"When one sperm gets into a human egg, there’s an automatic shut-off device that bars any other sperm from getting in. The human mind tends strongly toward the same sort of result."

SAFe indeholder mekanismer, som på overfladen kan synes agile, men som faktisk strider mod den sunde fornuft og erfaring, der ligger til grund for agilitet, som den er udtrykt i det agile manifest. Manifestets fire nøgleværdier - Individuals and interactions, Working software, Customer collaboration og Responding to change - er ikke komplekse. De tolv underliggende principper er endda mere objektive, om end de kan være udfordrende at følge i praksis.

"The brain of man is programmed with a tendency to quickly remove doubt by reaching some decision."

Agile er i den grad også blevet genstand for kommerciel udnyttelse, hvilket de sidste 20 år har vist. SAFe er et glimrende eksempel på, at kommercialisere det agile manifest i en retning det aldrig har været tiltænkt. Agile er ikke et produkt.

Samtidig er det er ikke nok bare at påstå "det agile manifest virker bare". Også selvom det langt hen ad vejen er sandheden.

"The brain of man conserves programming space by being reluctant to change, which is a form of inconsistency avoidance. We see this in all human habits, constructive and destructive."

Jeg har oplevet SAFe's såkaldte PI-Planning mekanisme hos en kunde, hvor 100 mennesker fordelt på 12 teams brugte 3 dage på at forberede det næste kvartals produktudvikling. Dette er ikke kun en voldsom overtrædelse af "planning fallacy", men også meget kostbart.

Udover den åbenlyse tilsidesættelse af "planning fallacy" så er det også en ofte meget dyr øvelse. I den pågældende kundes konstellation kan vi udregne det som 100 mennesker * 1000kr i timen * 7 timer * 3 dage = 2.100.000kr. pr kvartal.

Ved agilitet planlægges der baseret på hvad kunder og brugere finder relevant og på baggrund af evidens for, hvad der fungerer i de feedback loops som netop agile fordrer.

Man kan ikke planlægge tre måneder frem i et agilt miljø. Du kan godt forsøge at sætte nogle high-level målsætninger men lad endelig være med, at bruge dem som andet end din egen målestok for hvad dine egne ønsker er.

Hos Microsoft oplevede vi, at et otte-personers team forsøgte at planlægge et kvartal frem. Det lykkedes aldrig at komme ud med en plan, og møderne endte ofte i frustration over manglende konsensus og forståelse.

Agilitet handler ikke om skalering, men om at praktisere det, der står i manifestet og de underliggende principper for at skabe vedvarende gevinst.

Jeg forstår udmærket hvorfor SAFe har fundet vej til virksomheder, der er baseret på industrialiseringens blueprint. Det handler basal set om kontrol, som er en indgroet del af de fleste organisationer.

Disse virksomheder har enten ikke har formået eller ønsket, at ændre sin organisatoriske og kulturelle adfærd - noget der er nødvendigt for at opnå det som agile står for.

Og samtidig forstår selv samme virksomheder ikke forstår hvorfor det til stadigighed er svært for dem - vi har jo plastret agile på organisationen - at få større gevinster på baggrund af et sundere, sjovere og rigere fundament.

"...the idea of having an executive team, department directors, middle management, and then lower-level workers came straight from the railroad system..."

"If you’ve ever wondered where the workplace terms “chain of command” and “front line workers” come from, they transferred over from as the Greatest Generation returned from war and traded in uniforms and C-rations for suits and corporate..."

Indoktrineringen som stammer fra industrialiseringens hierarki, omkring værdiskabelse gennem hierakiets "command & control" og ledelsens prioriteringer, trives stadig i stor stil.

SAFe er blevet solgt til disse institutioner med et løfte om agilitet, men i realiteten bremser det alt, hvad agilitet står for - eksperimentering, autonomi, forretnings-potentiale - og fremmer i stedet silo teams, "chain of command", hierarkisk forankrede roller og en overflod af træninger og certificeringer.

"An ounce of prevention is worth a pound of cure." Brug energi på at tilegne jer gode vaner i stedet for at bekæmpe dårlige. Det sidste er nemlig mere energikrævende.

Quotes og kilder:

https://fs.blog/great-talks/psychology-human-misjudgment/ https://en.wikipedia.org/wiki/Planning_fallacy https://www.forbes.com/sites/forbesbooksauthors/2023/06/05/industrial-revolution-hangovers-part-i-corporate-hierarchy/ https://www.forbes.com/sites/forbesbooksauthors/2023/06/14/industrial-revolution-hangovers-part-ii-command-and-control-management/