softify.pro - Insiders

Det finnes en enkel måte å få lagerprogramvare til å virke overbevisende på.
Åpne et dashbord.
Vis noen grønne tall.
Legg til et diagram.
Plasser noe lager på et lagerkart.
Avslutt med en rapport.
Alt ser bra ut.
Og likevel kan alt være feil.
For et lager bryr seg ikke om hvor bra dashbordet ser ut.
Det bryr seg om alle deler av systemet er enige om hva som faktisk skjedde.
Det ble den interessante delen av det nyeste softify.pro Flow-eksperimentet.
Ikke enda en skjerm.
Ikke enda en KPI.
Ikke enda en rapport.
Noe mye mindre synlig.
Konsistens.
Det begynte med et lager.
Den nåværende softify.pro Flow-demoen fungerer med flere syntetiske lagermiljøer.
Forskjellige lager-ID-er.
Forskjellige kapasiteter.
Forskjellige sonestrukturer.
Ingen produksjonsbeholdning.
Ingen kundedata.
Ingen ekte operativ informasjon.
Men prosesslogikken oppfører seg som om alt dette betydde noe.
For i virkelig logistikk gjør det det.
Når et lager er valgt, blir den konteksten en del av alt som følger.
Flows.
SSCC-er.
Bevegelser.
Operatører.
Analytics.
Rapporter.
Det høres selvsagt ut.
Det blir betydelig mindre selvsagt når samme prosess begynner å dukke opp i flere ulike deler av applikasjonen.
Så åpnet vi en annen visning.
Operational Analytics.
Plutselig så lageret helt annerledes ut.
Ingen lagringsposisjoner.
Ingen bevegelsespiler.
I stedet:

• fullførte Flows,
• aktive ordre,
• lagerutnyttelse,
• unntak,
• inngående,
• utgående,
• behandlingstid.

Den visuelle fremstillingen hadde endret seg.
Lageret hadde ikke.
Det skillet ble viktig.
For under KPI-ene var det fortsatt individuelle poster.
Flow-ID-er.
SSCC-er.
Soner.
Statuser.
Operatører.
Behandlingstider.
Annen visning.
Samme operative virkelighet.
Så langt, så bra.

Operational Analytics — aggregert lagerstatus, med de underliggende Flow-postene fortsatt synlige.

88 % er bare nyttig hvis systemet kan forklare det.
Anta at dashbordet sier:
Lagerutnyttelse: 88 %.
Nyttig.
Men ufullstendig.
Noen posisjoner er opptatt.
Noen er reservert.
Noen forblir ledige.
De statusene er ikke utskiftbare.
Tallet blir først pålitelig hvis systemet fortsatt kan forklare hvor det kommer fra.
Fem fullførte Flows?
Vis dem.
To aktive ordre?
Vis dem.
Ett unntak?
Hvilket?
88 % utnyttelse?
Hva er opptatt?
Hva er reservert?
Hva forblir ledig?
Et dashbord bør oppsummere virkeligheten.
Det bør ikke erstatte den.
Så endret vi språket.
Nederlandsk.
Lageret forble det samme.
Flow-ID-ene forble de samme.
SSCC-ene forble de samme.
Operatørene forble knyttet til sine poster.
Bare språket endret seg.
Senere dukket samme operative status opp på kroatisk.
Deretter på fransk.
Her blir flerspråklig programvare mye mer interessant enn oversatte knapper.
En dårlig oversettelse er lett å legge merke til.
En statusendring forårsaket av et språkbytte er mye farligere.
Tenk deg å bytte fra tysk til fransk og stille miste det valgte Flowet.
Eller å bygge om et filter mot feil lager.
Eller å vise riktig SSCC i feil prosesskontekst.
Grensesnittet kan fortsatt se perfekt ut.
Systemet ville ikke være det.
Flow følger derfor en enkel regel:
Språk kan endre ordene. Det kan ikke endre sannheten.
Så fikk Flowet en historikk.
Browse & Drill-down anstrenger seg ikke spesielt for å virke imponerende.
Kanskje er det nettopp derfor det er nyttig.
Velg et Flow.
Konteksten dukker opp.
Lager.
Sone.
Status.
Operatør.
SSCC.
Og deretter dokumentkjeden.
ASN.
Varemottak.
Lagerbevegelse.
Plukkordre.
Plukking.
Forsendelse.
FLOW.
Sju trinn.
Prosessen er ikke lenger bare en nåværende status.
Den har en fortid.
Og det endrer spørsmålet.
I stedet for:
Hva skjer?
kan vi spørre:
Hvordan endte vi opp her?
Det er et mye bedre spørsmål når noe til slutt går galt.

Ett Flow, én SSCC, én dokumentkjede — fra ASN til fullføring.

SSCC blir den røde tråden.
Til å begynne med ser en SSCC ut som det den er.
En identifikator.
Et langt tall i en tabell.
Men på tvers av Flow blir den noe mer nyttig.
En rød tråd gjennom prosessen.
Følg den, og andre ting begynner å koble seg sammen.
Et lager.
Et Flow.
En sone.
En status.
En operatør.
En dokumentkjede.
Til slutt en rapport.
Det samme fysiske logistikkobjektet er nå synlig fra flere ulike deler av applikasjonen.
Nyttig.
Også farlig.
For hver ekstra visning skaper enda en mulighet for systemet til å fortelle en annen historie.
Og det er der ting blir interessante.
Anta at Analytics sier at Flowet er aktivt.
Drill-down sier at SSCC-en tilhører det Flowet.
Dokumentkjeden sier at operasjonen har kommet lenger.
Rapporten sier noe annet.
Hvilken stemmer?
Dette er ikke et Flow-spesifikt problem.
Det er ett av de eldste problemene i forretningsprogramvare.
Ulike deler av samme system utvikler gradvis sin egen versjon av virkeligheten.
Én skjerm leser den transaksjonelle statusen.
En annen leser et aggregat.
En annen stoler på bufrede data.
En rapport beregner noe litt annerledes.
Et unntak løses operativt, men forsvinner fra rapporteringen.
Hver komponent fungerer.
Hele systemet lyver.
Vanligvis høflig.
Så åpnet vi Report Center.
Daglig operativ oversikt.
Lager og belegg.
Flow-ytelse.
SSCC-sporbarhet.
Unntak og SLA.
Den samme operative historien dukket opp igjen.
Fullførte Flows.
Aktive ordre.
Lagerutnyttelse.
Unntak.
Inngående.
Utgående.
Behandlingstid.
Men denne gangen var spørsmålet ikke om rapporten så riktig ut.
Spørsmålet var:
Kan den forsvare seg selv?
En god rapport gir deg et tall.
Et bedre system kan forklare hvor tallet kommer fra.

Rapportering fra samme operative status — ikke en andre versjon av virkeligheten.

Unntaket var fortsatt der.
En av de stillere detaljene viste seg å være en av de viktigere.
Demodataene inneholder et unntak.
Det vises i Analytics.
Det vises i Drill-down.
Det vises i SSCC-sporbarheten.
Det vises i Report Center.
Og det forblir synlig i Exceptions & SLA.
Det er nøyaktig det som bør skje.
Å komme seg operativt etter et unntak betyr ikke at unntaket bør forsvinne fra historikken.
«Prosessen fortsatte» og «ingenting skjedde» er ikke det samme utsagnet.
I logistikk betyr den forskjellen noe.
På dette punktet hadde vi et testproblem.
Ikke et programvareproblem.
Et testproblem.
Vi hadde nå det samme lageret representert som:

• analytics,
• individuelle Flows,
• SSCC-historikker,
• dokumentkjeder,
• rapporter,
• og unntaksvisninger.

Hver enkelt kunne testes uavhengig.
Åpne.
Klikke.
Filtrere.
Verifisere.
Bestå.
Neste.

Det ville være enkelt.
Det ville også gå glipp av den interessante delen.
For seks grønne haker beviser ikke at seks visninger stemmer overens med hverandre.
Inn kommer COCO.
Igjen.
COCO hadde allerede hatt med Flow å gjøre før.
Autentisering.
Brukere.
Roller.
Databasemiljøer.
Språk.
Desktop-utførelse.
Så kom logistikken.
Lagre.
Beholdning.
Plukking.
Bevegelser.
Unntak.
Dokumenter.
Ubuntu.
Red Hat Enterprise Linux.
Denne gangen ga vi COCO noe litt annerledes.
Ikke en skjerm å verifisere.
En historie å følge.
Ta dette lageret.
Ta dette Flowet.
Ta denne SSCC-en.
Åpne Analytics.
Åpne Drill-down.
Endre språket.
Se igjen.
Åpne rapporten.
Finn samme Flow.
Finn samme SSCC.
Finn unntaket.
Sammenlign.
Sammenlign deretter igjen.

COCO følger samme operative kontekst gjennom softify.pro Flow — analytics, sporbarhet, språkendringer og rapportering.

Det endrer testens natur.

Spørsmålet er ikke lenger:

• Fungerer hver modul?

Det blir:

• Tror alle modulene at det samme skjedde?

Et mye bedre spørsmål.
Mye mindre komfortabelt.
Et lagersystem bør ha ett minne.
Operatører ser kanskje posisjoner.
Lagersjefer ser kanskje KPI-er.
Support bruker kanskje drill-down.
Revisorer bruker kanskje rapporter.
COCO ser kanskje alle disse.
Men under disse perspektivene bør det finnes én historikk.
Ett Flow bør ikke få flere biografier avhengig av hvilken modul som er åpen.
Én SSCC bør ikke ha flere fortider.
Ett unntak bør ikke bare eksistere der det er praktisk.
Ett lager bør ikke bli et annet lager fordi grensesnittspråket ble endret.
Det er hva det nåværende Flow-eksperimentet egentlig handler om.
Ikke dashbord.
Ikke rapporter.
Ikke engang enkeltskjermer.
Én operativ sannhet, uttrykt på ulike måter.
Kontroll.
Kjenne lageret.
Kjenne statusen.
Vite hva som beveger seg.
Vite hvilken prosess som eier det.
Klarhet.
Gjøre KPI-er om til poster igjen.
Gjøre poster om til historikk.
Gjøre unntak om til bevis.
Gjøre en SSCC om til noe sporbart.
Flow.
Et lager velges.
Analytics begynner å beskrive det.
Et Flow går fremover.
SSCC-en forblir tilknyttet.
En dokumentkjede vokser.
Et unntak dukker opp.
Prosessen fortsetter.
Rapporten husker.
Så endres språket.
Lageret er fortsatt det samme.
Flowet er fortsatt det samme.
Historikken er fortsatt den samme.
Det var den forventede delen.
Det som skjedde etterpå var mer interessant.
COCO sluttet å teste visningene uavhengig.
Det begynte å sammenligne dem.
En stund skjedde det ingenting bemerkelsesverdig.
Samme lager.
Samme Flow.
Samme SSCC.
Samme historie.
Igjen.
Igjen.
Igjen.
Og så stoppet COCO.
Ikke fordi applikasjonen krasjet.
Det gjorde den ikke.
Ikke fordi en test feilet i vanlig forstand.
Det gjorde den ikke.
Den stoppet fordi to helt rimelige svar produserte et tredje spørsmål.

Vi vet hva spørsmålet er.
Flow vet hvorfor det finnes.
COCO vet hvor det skal se neste.

Resten kan vente.

Control. Clarity. Flow.

Vi bør nok slutte å gi COCO ideer.
Det forrige eksperimentet skulle være nok.
En ekte applikasjon.
Ekte navigasjon.
Brukere.
Roller.
Databaser.
Språk.
Bevis.

En respektabel casestudie.
En ren konklusjon.
Så viste noen det: Logistics in Motion.
Det var nok feilen.

Det begynte med tre lagre
Ingenting spesielt spennende.
Tre DEMO-lagre.

• Kalsdorf bei Graz.
• Wiener Neustadt.
• Klagenfurt.

Syntetisk data.
Ingen kundeinformasjon.
Ingen produksjonsbeholdning.

Nettopp den typen miljø der ingenting viktig skal skje.
Så ble det første lageret valgt.
Og applikasjonen fikk kontekst.
Fra det øyeblikket hadde hver skjerm et spørsmål til knyttet til seg.

Tilhører dette fortsatt det samme lageret?
Endrer språket bare grensesnittet?
Forblir prosessen på samme steg?
Stemmer beholdningen fortsatt?
Peker dokumentreferansen fortsatt på riktig hendelse?
Ser operatøren nøyaktig det som trengs for neste handling?

Plutselig var den interessante delen ikke lenger skjermen.
Det var kontinuiteten mellom skjermene.

COCO har en tendens til å gjøre det.

Logistikk er ikke en samling skjermer
Utenfra kan lagerprogramvare se villedende enkelt ut.
Varer ankommer.
De lagres.
Noen bestiller dem.
De plukkes.
De sendes.
Ferdig.
Bortsett fra at det finnes en hel operativ verden gjemt mellom ankommet og sendt.
Forventet.
Mottatt.
Kontrollert.
Tilgjengelig.
Reservert.
Flyttet.
Plukket.
Blokkert.
Korrigert.
Sendt.
Revidert.

Den fysiske bevegelsen betyr noe.
Men det er tilstandsovergangen som gjør den bevegelsen forståelig for programvaren.
Og når de to virkelighetene slutter å stemme overens, får noen til slutt en dårlig dag.



Et lager er lettere å forstå når bevegelse er synlig, ikke bare registrert.
Det er derfor vårt logistikkarbeid aldri egentlig har startet med menyer, dashbord, eller teknologi.
Det starter med den materielle Flow.

Hvor kommer informasjon inn?
Hvor endres den?
Hvor kan den gå tapt?

Hvor blir noen tvunget til å spørre en annen person om hva som skjedde?
Hvor blir et manuelt steg stille den svakeste delen av en ellers automatisert prosess?
Noen ganger er svaret et nytt grensesnitt.
Noen ganger en integrasjon.
Noen ganger en skanner.
Noen ganger rett og slett en bedre tilstandsmodell.

Mer programvare er ikke automatisk bedre programvare.
Målet er ikke automatisering for sin egen skyld.
Målet er en prosess som forblir forståelig.

Control. Clarity. Flow.

Prosessen begynner før den første bookingen.
Før varemottak.
Før plukking.
Før lagerbevegelse.
Før den første transaksjonen.
Flow stiller et veldig grunnleggende spørsmål:
Hvilket lager jobber vi i?
Det høres nesten trivielt ut.
Det er det ikke.
Lagerkontekst hører til alt som følger.
Beholdning.
Dokumenter.
Lokasjoner.
Plukking.
Omplasseringer.
Revisjonshistorikk.
Unntak.

Prosessen kan se helt sunn ut mens den opererer i feil kontekst.
Det er nøyaktig den typen problem et skjermbilde sjelden avslører.
Og nøyaktig den typen grense COCO liker å stille spørsmål ved.

Språk er enkelt til det ikke er det
Tysk.
Engelsk.
Kroatisk.
Norsk.
Og andre.

En brukerprofil definerer de tilgjengelige språkene.
Operatøren bytter språk mens applikasjonen kjører.
Grensesnittet endres umiddelbart.
Forretningsprosessen skal ikke det.
Det skillet er viktig.
Lageret flytter seg ikke fordi ordet for lager endret seg.
Plukkordren starter ikke på nytt fordi brukeren valgte et annet språk.
En reservasjon forsvinner ikke.
Et unntak tilhører ikke plutselig en annen transaksjon.
Prosessen forblir der den er.
Bare representasjonen endres.
Det høres opplagt ut.

Helt til man innser hvor mange applikasjoner behandler et språkbytte nesten som en ny økt.

En flerspråklig forretningsapplikasjon bør ikke gjøre det.
Presentasjonstilstanden kan endres.
Forretningstilstanden må forbli stabil.
Det gjør språkbytte til en overraskende nyttig regresjonstest.
En liten funksjon.
En veldig god bruddlinje.
COCO liker bruddlinjer.

Steg for steg begynner applikasjonen å samle historikk
Varer ankommer.
Prosessen går fremover.
Varemottak bookes.
Beholdningen endres.
Lagerstatusen gjenspeiler den nye virkeligheten.
Plukking begynner.
Lagerbeholdning blir reservert.
Operatøren mottar en oppgave.

En mobilvisning reduserer hele prosessen til det som betyr noe i akkurat det øyeblikket:
Posisjon.
Lagerplass.
Antall.
SSCC.
Operatør.
Ikke mer.
Ikke mindre.
Det er viktig.
Det mobile grensesnittet er ikke en andre forretningsprosess.
Det er en annen visning av samme prosess.
Lagerapplikasjonen kan vite alt.
Plukkeren skal ikke måtte det.
Clarity betyr ikke alltid å vise mer informasjon.
Noen ganger betyr clarity å ha disiplinen til å skjule nesten alt.

Så skanner noen feil lokasjon
Her blir en logistikk-arbeidsflyt mer interessant enn en funksjonsliste.
Den forventede lokasjonen er én ting.
Den skannede lokasjonen er en annen.
Flow stopper.
Krasjer ikke.
Stopper.
Det er en forskjell.
Prosesstatusen forblir synlig.
Den berørte beholdningen forblir forståelig.
Unntaket blir eksplisitt.

Kontekstuell hjelp forklarer hva som er relevant for den nåværende situasjonen.
Brukeren løser avviket.
Prosessen fortsetter.
Dette øyeblikket sier mer om operativ programvare enn flere sider med happy-path-skjermbilder.
Ekte logistikk er ikke vanskelig når alt er korrekt.
Ekte logistikk blir vanskelig når noe er nesten korrekt.
Et nyttig system skjuler ikke det bak et grønt dashbord.
Det gir unntaket en status.

En grunn.
En historikk.
Og en vei videre.

Dokumenter husker det folk glemmer

Etter hvert som arbeidsflyten skrider frem, begynner referanser å samle seg opp.
ASN.
Varemottak.
Lagerbevegelse.
Plukking.
Utsendelse.
Flow.
Den interessante delen er ikke at dokumenter finnes.
Den interessante delen er at de forteller den samme historien som prosessen.
Hvorfor er denne beholdningen her?
Hvilket mottak introduserte den?
Hvilken operasjon reserverte den?
Hvilken plukking forbrukte den?
Hvilken forsendelse flyttet den ut?
Ble et unntak løst før neste steg?
Hva var det aktive lageret?
Hva skjedde før den nåværende tilstanden?
Når tilstand og dokumentasjon produseres av samme prosess, blir sporbarheten lettere å stole på.
Når de ikke er det, begynner folk til slutt å rekonstruere historikken.
Vanligvis i Excel.
Vanligvis under press.
Vanligvis etter at noe allerede har gått galt.
COCO foretrekker bevis før det øyeblikket.
Tydeligvis reiser COCO også
Det var enda en liten endring mellom kjøringene.
Ubuntu hadde sin kjøring.
Red Hat Enterprise Linux 10 tok den neste.
COCO fortsatte.
Ingen seremoni.
Ingen spesiell "Red Hat-modus".
Ingen omskrevet arbeidsflyt.
Ingen bekvemt forenklet test.
Samme Flow.
Annen grunn under den.
En tidligere COCO-kjøring hadde allerede testet applikasjonen på Ubuntu Linux.
Den nåværende flyttet til Red Hat Enterprise Linux 10.
Annet skrivebordsmiljø.
Andre systembiblioteker.
Annen pakking.
Annet driftsmiljø.
Samme lager.
Samme forretningstilstander.
Samme beholdningsoverganger.
Samme språkendringer.
Samme unntakslogikk.
Samme bevis.
Det er en ganske fin måte å teste plattformuavhengig programvare på.

Ikke annonser at det er plattformuavhengig. Flytt det. Se så hva som går i stykker.

Språktilstand.
Lagerkontekst.
Dialogoppførsel.
Timing.
Temaer.
Prosessoverganger.
Unntakshåndtering.
Bevis.
Operativsystemer har overraskende kreative måter å avsløre antakelser på.

Ubuntu avslørte noen.
Red Hat avslører andre.
Det er nyttig.

Fordi multiplattform-utvikling ikke er evnen til å starte den kjørbare filen to ganger.

Det er evnen til å endre miljøet uten å endre betydningen av prosessen.
En lageroperatør bør ikke bry seg om applikasjonen kjører på Ubuntu eller Red Hat.
En plukkordre bør heller ikke bry seg.
Det bør heller ikke et revisjonsspor.
Hvis plattformforskjeller begynner å endre forretningsatferd, er programvaren ikke virkelig plattformuavhengig.
Den er bare portabel.
COCO virker betydelig mer interessert i den første definisjonen.
Det er vi også.

COCO bestemmer ikke hva korrekt logistikk betyr
Denne delen er viktig.
COCO blir ikke en lagerekspert bare fordi det kan følge en lager-arbeidsflyt.
Mennesker definerer fortsatt korrekthet.
Mennesker bestemmer når beholdning blir tilgjengelig.
Mennesker definerer hva en blokkert levering betyr.
Mennesker bestemmer hvem som kan korrigere en mengde.
Mennesker definerer hvilken bevegelse som krever et revisjonsspor.
Mennesker bestemmer hvordan en gyldig unntaksløsning ser ut.
Mennesker bestemmer når en forsendelse er virkelig komplett.
COCOs jobb er annerledes.

Gjenta.
Observere.
Sammenligne.
Huske.
Etterlate bevis.

Gjør det så igjen etter at programvaren endres.
Og igjen.
Og igjen.
Uten å bli lei.
Uten å bestemme at forrige ukes resultat sannsynligvis fortsatt er gyldig.
Uten å hoppe over det irriterende unntaket fordi lunsjen er om tolv minutter.
Den glamorøse fremtiden for AI-testing inneholder en overraskende mengde repetisjon.
Vi anser det som en funksjon.

Bevis endrer samtalen
Tradisjonell testing ender ofte med en helt fornuftig setning:
"Det fungerte da jeg testet det."

COCO er interessert i den neste setningen.

Hva fungerte nøyaktig?
Hvilket lager?
Hvilken bruker?
Hvilket språk?
Hvilken prosesstilstand?
Hvilken sekvens?
Hvilket dokument?
Hvilken beholdningsverdi?
Hva skjedde umiddelbart før teststeget?
Hva endret seg umiddelbart etterpå?
Kan en annen ingeniør forstå resultatet uten å spørre personen som utførte testen?
Det er der regresjonstesting blir mer enn gjentatt klikking.
En skjerm kan være korrekt mens prosessen er feil.
Et plukkevindu kan se perfekt ut mens beholdningen allerede har drevet av sted.
Et dokument kan eksistere mens tilstanden som skulle ha skapt det aldri inntraff.
En applikasjon kan vise 100 % mens et revisjonsspor stille er uenig.
COCO følger Flow fordi det er i Flow disse motsigelsene blir synlige.

Et sted mellom Control og Flow
Det er en interessant symmetri her.
God logistikkprogramvare prøver å redusere usikkerhet innenfor en operasjon.
God testing prøver å redusere usikkerhet om programvaren som kjører den.
Den ene spør:
Hvor er varen?
Den andre spør:
Hvordan vet vi at programvaren fortsatt vet det?
Den ene spør:
Ble denne bevegelsen fullført?
Den andre spør:
Hvilket bevis viser at tilstanden endret seg riktig?
Den ene spør:
Kan neste skift fortsette?
Den andre spør:
Kan neste ingeniør forstå hva som skjedde?
Ulike spørsmål.
Samme instinkt.
Gjør tilstanden synlig.
Bevar resonnementet.
Reduser mengden kunnskap som bare finnes i noens hode.
Kanskje er det koblingen vi ikke opprinnelig planla.

Ingeniørmessig fortreffelighet uten banneret
Ingen klikker på en Engineering Excellence-knapp.
Det finnes ingen.
Og det bør sannsynligvis ikke finnes en.
Ingeniørmessig fortreffelighet viser seg indirekte.
Lagerkonteksten overlever et språkbytte.
Samme prosess overlever en annen Linux-plattform.
En lagerbevegelse forblir sporbar.
En mobil plukker ser nøyaktig det som trengs og ingenting annet.
Et unntak avbryter prosessen uten å ødelegge dens tilstand.
Hjelpevinduet forklarer den nåværende konteksten i stedet for å vise generisk dokumentasjon.
Dokumentkjeden stemmer overens med den operative sekvensen.
Neste ingeniør kan forstå hva som skjedde uten å spørre personen som tilfeldigvis var der.
Det er nok av teater tilgjengelig i moderne programvare.
AI kan generere imponerende demonstrasjoner.
Dashbord kan animeres.
Tall kan bevege seg.
Videoer kan se veldig overbevisende ut.
Ingenting av dette beviser at to beholdningsoperasjoner ikke stille kan produsere et feil resultat.
Ingenting av dette beviser at et unntak fortsatt kan rekonstrueres uker senere.
Ingenting av dette beviser at lagerarbeideren, spedisjonøren, og utvikleren ser på den samme operative sannheten.

Ingeniørmessig fortreffelighet starter et mindre fotogent sted.

Med konsistens.
Med bevis.
Med grenser.

Med viljen til å holde de kjedelige delene kjedelige.
Usynlig pålitelighet produserer sjelden det mest dramatiske skjermbildet.
Helt til man bevisst begynner å lete etter det.

Control. Clarity. Flow.
Control er å vite hvilket lager, hvilken prosess, og hvilken tilstand som er aktiv.
Clarity er å forstå hva som endret seg, når det endret seg, og hvorfor.
Flow er å la operasjonen fortsette uten å miste historien bak den.
Det fungerer for logistikk.
Det fungerer for programvaretesting.
Det fungerer overraskende bra for ingeniørfaget selv.
Det første Flow-eksperimentet ga COCO Administration.
Brukere.
Roller.
Databaser.
Språk.
Så ga noen det et lager.
Så flere språk.
Så mobil plukking.
Så beholdning.
Så omplasseringer.
Så unntak.
Så dokumenter.
Så et annet operativsystem.
På dette tidspunktet bør vi sannsynligvis slutte å legge til ting.
Vi kommer sannsynligvis ikke til å gjøre det.

Control. Clarity. Flow.

Ubuntu hadde sin tur.

Red Hat har den nåværende.

Flow fortsetter å bevege seg.

COCO fortsetter å se på.
Og et sted midt i den siste kjøringen ble det tydelig at det er et annet spørsmål som venter bak dette.

Vi vet hva det er.
COCO vet hva det er.
Du vet det ikke.
Ennå.

Vi kunne fortalt deg det.

Men da vil du kanskje slutte å sjekke om en ny Insiders-artikkel har dukket opp.
Og det ville ødelagt eksperimentet.

Til ingeniøren som åpner dette repositoriet for første gang: Velkommen.
Du har kanskje kommet hit fordi noe feilet.
En tjeneste sluttet å svare.
En utrulling oppførte seg uventet.
Et varsel vekket deg midt på natten.
Eller kanskje du bare er nysgjerrig på hvordan denne plattformen fungerer.
Uansett hva som førte deg hit, vit at dette prosjektet ble bygget for nettopp slike øyeblikk.
Ikke for å fjerne vanskelige problemer.
Men for å gjøre vanskelige problemer forståelige.
Du vil finne kode.
Du vil finne dokumentasjon.
Du vil finne spesifikasjoner.
Men enda viktigere,
håper jeg du vil finne resonnement.
Noen før deg stilte vanskelige spørsmål.
Noen samlet bevis.
Noen tok beslutninger.
Noen forklarte hvorfor.
Disse forklaringene er en del av plattformen.
Behandle dem med samme respekt som kildekoden.
En dag vil du forbedre noe.
Kanskje er det en liten bug.
Kanskje er det en helt ny funksjon.
Uansett hva du endrer, husk at en annen ingeniør til slutt vil arve arbeidet ditt.
Etterlat dem mer enn fungerende programvare.
Etterlat dem forståelse.
Forklar din hensikt.
Dokumenter dine antakelser.
Bevar bevisene dine.
Fortell historien bak beslutningen.
Den historien kan en dag spare noen for timer — eller dager — med undersøkelser.
Ikke vær redd for å erstatte teknologi.
Erstatt biblioteker.
Erstatt leverandører.
Erstatt utrullingsmodeller.
Erstatt programmeringsspråk.
Erstatt arkitekturer om nødvendig.
Men før du erstatter en idé, forstå hvorfor den fantes.
Fremgang uten forståelse er bare endring.
Fremgang bygget på forståelse blir evolusjon.
Det vil komme øyeblikk der plattformen overrasker deg.
Behandle de øyeblikkene som gaver.
Hver overraskelse avslører noe arkitekturen ennå ikke forsto.
Undersøk tålmodig.
Samle bevis.
Forbedre gjennomtenkt.
Etterlat deretter lærdommen til dem som følger.
Slik vokser teknisk kunnskap.
Det vil også komme øyeblikk der ingenting interessant skjer.
Også de øyeblikkene betyr noe.
Stille systemer er ofte friske systemer.

Hvis COCO forsvinner inn i bakgrunnen fordi hendelser blir kortere,
fordi forklaringer blir klarere, fordi onboarding blir enklere, fordi ingeniører stoler på bevisene, da lykkes plattformen.
Usynlig pålitelighet er en av de høyeste formene for teknisk fortreffelighet.
Ikke mål dette prosjektet etter antall automatiseringer det utfører.
Mål det etter spørsmål som disse:

• Blir folk avbrutt sjeldnere?
• Forstår ingeniører systemer dypere?
• Er viktige beslutninger lettere å forklare?
• Overlever operativ kunnskap teamendringer?
• Gjentas feil sjeldnere?
• Blir nye ingeniører produktive raskere?

Det er resultatene som er verdt å bevare.
Husk til slutt at ingen håndbok er komplett.
Ingen spesifikasjon forutsier hver fremtid.
Ingen arkitektur overlever uendret for alltid.
Det er ingen svakhet.
Det er en invitasjon.
Observer virkeligheten.
Utfordre antakelser.
Forbedre plattformen.
Lær opp de som kommer etter deg.
Og når din egen tid som forvalter til slutt tar slutt, etterlat et system som er roligere, klarere, mer forståelig og mer pålitelig enn det du arvet.

Hvis hver generasjon gjør det, vil COCO aldri virkelig bli utdatert.
For dens største aktivum vil ikke være dens programvare.
Det vil være den tekniske disiplinen som føres videre av menneskene som fortsetter å bygge den.
Takk for at du ble en av dem.
Neste kapittel er ikke lenger i denne håndboken.
Neste kapittel er i koden du er i ferd med å skrive.

COCO-håndboken

For programvare utvikler seg.
En god arkitektur utvikler seg langsommere.
Og en god filosofi bør overleve begge.

softify.pro