softify.pro - Insiders

Det finns ett enkelt sätt att få lagerprogramvara att verka övertygande.
Öppna en instrumentpanel.
Visa några gröna siffror.
Lägg till ett diagram.
Placera lite lager på en lagerkarta.
Avsluta med en rapport.
Allt ser bra ut.
Och ändå kan allt vara fel.
För ett lager bryr sig inte om hur bra instrumentpanelen ser ut.
Det bryr sig om varje del av systemet är överens om vad som faktiskt hände.
Det blev den intressanta delen av det senaste softify.pro Flow-experimentet.
Inte ännu en skärm.
Inte ännu en KPI.
Inte ännu en rapport.
Något mycket mindre synligt.
Konsekvens.
Det började med ett lager.
Den nuvarande softify.pro Flow-demon arbetar med flera syntetiska lagermiljöer.
Olika lager-ID:n.
Olika kapaciteter.
Olika zonstrukturer.
Inget produktionslager.
Inga kunduppgifter.
Ingen verklig operativ information.
Men processlogiken beter sig som om allt detta spelade roll.
För i verklig logistik gör det det.
När ett lager väl är valt blir den kontexten en del av allt som följer.
Flows.
SSCC:er.
Rörelser.
Operatörer.
Analytics.
Rapporter.
Det låter självklart.
Det blir betydligt mindre självklart när samma process börjar dyka upp i flera olika delar av applikationen.
Sedan öppnade vi en annan vy.
Operational Analytics.
Plötsligt såg lagret helt annorlunda ut.
Inga lagerpositioner.
Inga rörelsepilar.
I stället:

• slutförda Flows,
• aktiva order,
• lagerutnyttjande,
• avvikelser,
• inleverans,
• utleverans,
• bearbetningstid.

Den visuella representationen hade förändrats.
Lagret hade inte.
Den distinktionen blev viktig.
För under KPI:erna fanns fortfarande enskilda poster.
Flow-ID:n.
SSCC:er.
Zoner.
Statusar.
Operatörer.
Bearbetningstider.
Annan vy.
Samma operativa verklighet.
Hittills, så gott.

Operational Analytics — aggregerat lagertillstånd, med de underliggande Flow-posterna fortfarande synliga.

88 % är bara användbart om systemet kan förklara det.
Anta att instrumentpanelen säger:
Lagerutnyttjande: 88 %.
Användbart.
Men ofullständigt.
Vissa positioner är upptagna.
Vissa är reserverade.
Vissa förblir lediga.
De statusarna är inte utbytbara.
Siffran blir bara pålitlig om systemet fortfarande kan förklara var den kommer ifrån.
Fem slutförda Flows?
Visa dem.
Två aktiva order?
Visa dem.
En avvikelse?
Vilken?
88 % utnyttjande?
Vad är upptaget?
Vad är reserverat?
Vad förblir ledigt?
En instrumentpanel bör sammanfatta verkligheten.
Den bör inte ersätta den.
Sedan ändrade vi språket.
Nederländska.
Lagret förblev detsamma.
Flow-ID:na förblev desamma.
SSCC:erna förblev desamma.
Operatörerna förblev kopplade till sina poster.
Endast språket ändrades.
Senare dök samma operativa tillstånd upp på kroatiska.
Sedan på franska.
Det är här flerspråkig programvara blir mycket mer intressant än översatta knappar.
En dålig översättning är lätt att lägga märke till.
En tillståndsförändring orsakad av ett språkbyte är mycket farligare.
Föreställ dig att byta från tyska till franska och tyst förlora det valda Flowet.
Eller att bygga om ett filter mot fel lager.
Eller att visa rätt SSCC inom fel processkontext.
Gränssnittet kan fortfarande se perfekt ut.
Systemet skulle inte vara det.
Flow följer därför en enkel regel:
Språk får ändra orden. Det får inte ändra sanningen.
Sedan fick Flowet en historik.
Browse & Drill-down anstränger sig inte särskilt för att verka imponerande.
Det kan vara just därför det är användbart.
Välj ett Flow.
Dess kontext visas.
Lager.
Zon.
Status.
Operatör.
SSCC.
Och sedan dokumentkedjan.
ASN.
Godsmottagning.
Lagerförflyttning.
Plockorder.
Plock.
Utleverans.
FLOW.
Sju steg.
Processen är inte längre bara ett aktuellt tillstånd.
Den har ett förflutet.
Och det förändrar frågan.
I stället för:
Vad händer?
kan vi fråga:
Hur hamnade vi här?
Det är en mycket bättre fråga när något så småningom går fel.

Ett Flow, en SSCC, en dokumentkedja — från ASN till slutförande.

SSCC blir den röda tråden.
Till en början ser en SSCC ut som det den är.
En identifierare.
Ett långt nummer i en tabell.
Men genom Flow blir den något mer användbart.
En röd tråd genom processen.
Följ den och andra saker börjar kopplas samman.
Ett lager.
Ett Flow.
En zon.
En status.
En operatör.
En dokumentkedja.
Så småningom en rapport.
Samma fysiska logistikobjekt är nu synligt från flera olika delar av applikationen.
Användbart.
Även farligt.
För varje ytterligare vy skapar ännu ett tillfälle för systemet att berätta en annan historia.
Och det är där det blir intressant.
Anta att Analytics säger att Flowet är aktivt.
Drill-down säger att SSCC:n tillhör det Flowet.
Dokumentkedjan säger att processen har gått längre.
Rapporten säger något annat.
Vilken stämmer?
Det här är inte ett Flow-specifikt problem.
Det är ett av de äldsta problemen inom affärsprogramvara.
Olika delar av samma system utvecklar gradvis sin egen version av verkligheten.
En skärm läser det transaktionella tillståndet.
En annan läser ett aggregat.
En annan förlitar sig på cachad data.
En rapport beräknar något lite annorlunda.
En avvikelse löses operativt men försvinner från rapporteringen.
Varje komponent fungerar.
Hela systemet ljuger.
Vanligtvis artigt.
Så vi öppnade Report Center.
Daglig operativ översikt.
Lager och beläggning.
Flow-prestanda.
SSCC-spårbarhet.
Avvikelser och SLA.
Samma operativa historia dök upp igen.
Slutförda Flows.
Aktiva order.
Lagerutnyttjande.
Avvikelser.
Inleverans.
Utleverans.
Bearbetningstid.
Men den här gången var frågan inte om rapporten såg korrekt ut.
Frågan var:
Kan den försvara sig själv?
En bra rapport ger dig en siffra.
Ett bättre system kan förklara var siffran kommer ifrån.

Rapportering från samma operativa tillstånd — inte en andra version av verkligheten.

Avvikelsen fanns fortfarande kvar.
En av de tystare detaljerna visade sig vara en av de viktigare.
Demodatan innehåller en avvikelse.
Den visas i Analytics.
Den visas i Drill-down.
Den visas i SSCC-spårbarheten.
Den visas i Report Center.
Och den förblir synlig i Exceptions & SLA.
Det är precis vad som borde hända.
Att operativt återhämta sig från en avvikelse betyder inte att avvikelsen bör försvinna från historiken.
"Processen fortsatte" och "inget hände" är inte samma påstående.
Inom logistik spelar den skillnaden roll.
Vid det här laget hade vi ett testproblem.
Inte ett programvaruproblem.
Ett testproblem.
Vi hade nu samma lager representerat som:

• analytics,
• enskilda Flows,
• SSCC-historik,
• dokumentkedjor,
• rapporter,
• och avvikelsevyer.

Var och en kunde testas oberoende.
Öppna.
Klicka.
Filtrera.
Verifiera.
Godkänn.
Nästa.

Det skulle vara enkelt.
Det skulle också missa den intressanta delen.
För sex gröna bockar bevisar inte att sex vyer stämmer överens med varandra.
In kommer COCO.
Igen.
COCO hade redan haft att göra med Flow tidigare.
Autentisering.
Användare.
Roller.
Databasmiljöer.
Språk.
Desktop-körning.
Sedan kom logistiken.
Lager.
Bestånd.
Plock.
Rörelser.
Avvikelser.
Dokument.
Ubuntu.
Red Hat Enterprise Linux.
Den här gången gav vi COCO något lite annorlunda.
Ingen skärm att verifiera.
En historia att följa.
Ta det här lagret.
Ta det här Flowet.
Ta den här SSCC:n.
Öppna Analytics.
Öppna Drill-down.
Byt språk.
Titta igen.
Öppna rapporten.
Hitta samma Flow.
Hitta samma SSCC.
Hitta avvikelsen.
Jämför.
Jämför sedan igen.

COCO följer samma operativa kontext genom softify.pro Flow — analytics, spårbarhet, språkbyten och rapportering.

Det förändrar testets natur.

Frågan är inte längre:

• Fungerar varje modul?

Den blir:

• Tror alla moduler att samma sak hände?

En mycket bättre fråga.
Mycket mindre bekväm.
Ett lagersystem bör ha ett minne.
Operatörer kanske ser positioner.
Lagerchefer kanske ser KPI:er.
Support kanske använder drill-down.
Revisorer kanske använder rapporter.
COCO kanske ser alla dessa.
Men under dessa perspektiv bör det finnas en historik.
Ett Flow bör inte få flera biografier beroende på vilken modul som är öppen.
En SSCC bör inte ha flera förflutna.
En avvikelse bör inte bara existera där det är bekvämt.
Ett lager bör inte bli ett annat lager bara för att gränssnittsspråket ändrades.
Det är vad det nuvarande Flow-experimentet egentligen handlar om.
Inte instrumentpaneler.
Inte rapporter.
Inte ens enskilda skärmar.
En operativ sanning, uttryckt på olika sätt.
Kontroll.
Känn lagret.
Känn tillståndet.
Veta vad som rör sig.
Veta vilken process som äger det.
Klarhet.
Förvandla KPI:er tillbaka till poster.
Förvandla poster till historik.
Förvandla avvikelser till bevis.
Förvandla en SSCC till något spårbart.
Flow.
Ett lager väljs.
Analytics börjar beskriva det.
Ett Flow går framåt.
SSCC:n förblir kopplad.
En dokumentkedja växer.
En avvikelse dyker upp.
Processen fortsätter.
Rapporten kommer ihåg.
Sedan ändras språket.
Lagret är fortfarande detsamma.
Flowet är fortfarande detsamma.
Historiken är fortfarande densamma.
Det var den förväntade delen.
Vad som hände efteråt var mer intressant.
COCO slutade testa vyerna oberoende av varandra.
Det började jämföra dem.
Ett tag hände inget anmärkningsvärt.
Samma lager.
Samma Flow.
Samma SSCC.
Samma historia.
Igen.
Igen.
Igen.
Och sedan stannade COCO.
Inte för att applikationen kraschade.
Det gjorde den inte.
Inte för att ett test misslyckades i vanlig mening.
Det gjorde det inte.
Det stannade för att två fullkomligt rimliga svar gav upphov till en tredje fråga.

Vi vet vad frågan är.
Flow vet varför det finns.
COCO vet var det ska titta härnäst.

Resten kan vänta.

Control. Clarity. Flow.

Vi borde nog sluta ge COCO idéer.
Det förra experimentet skulle vara nog.
En riktig applikation.
Riktig navigering.
Användare.
Roller.
Databaser.
Språk.
Bevis.

En respektabel fallstudie.
En ren slutsats.
Sedan visade någon det: Logistics in Motion.
Det var nog misstaget.

Det började med tre lager
Inget särskilt spännande.
Tre DEMO-lager.

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

Syntetisk data.
Ingen kundinformation.
Inget produktionslager.

Precis den typ av miljö där ingenting viktigt ska hända.
Sedan valdes det första lagret.
Och applikationen fick kontext.
Från det ögonblicket hade varje skärm ytterligare en fråga knuten till sig.

Tillhör detta fortfarande samma lager?
Ändrar språket bara gränssnittet?
Förblir processen på samma steg?
Stämmer lagret fortfarande?
Pekar dokumentreferensen fortfarande på rätt händelse?
Ser operatören exakt det som behövs för nästa åtgärd?

Plötsligt var den intressanta delen inte längre skärmen.
Det var kontinuiteten mellan skärmarna.

COCO tenderar att göra det.

Logistik är inte en samling skärmar
Utifrån sett kan lagermjukvara se bedrägligt enkel ut.
Varor anländer.
De lagras.
Någon beställer dem.
De plockas.
De skickas.
Klart.
Förutom att det finns en hel operativ värld gömd mellan anlänt och skickat.
Förväntad.
Mottagen.
Kontrollerad.
Tillgänglig.
Reserverad.
Flyttad.
Plockad.
Blockerad.
Korrigerad.
Skickad.
Reviderad.

Den fysiska rörelsen spelar roll.
Men det är statusövergången som gör den rörelsen begriplig för mjukvaran.
Och när de två verkligheterna slutar stämma överens får någon till slut en dålig dag.



Ett lager är lättare att förstå när rörelsen är synlig, inte bara registrerad.
Det är därför vårt logistikarbete aldrig egentligen börjat med menyer, instrumentpaneler, eller teknik.
Det börjar med det materiella Flow.

Var kommer informationen in?
Var förändras den?
Var kan den gå förlorad?

Var tvingas någon fråga en annan person vad som hände?
Var blir ett manuellt steg tyst den svagaste länken i en annars automatiserad process?
Ibland är svaret ett nytt gränssnitt.
Ibland en integration.
Ibland en skanner.
Ibland helt enkelt en bättre statusmodell.

Mer mjukvara är inte automatiskt bättre mjukvara.
Målet är inte automatisering för sin egen skull.
Målet är en process som förblir begriplig.

Control. Clarity. Flow.

Processen börjar innan den första bokningen.
Innan godsmottagning.
Innan plockning.
Innan lagerrörelse.
Innan den första transaktionen.
Flow ställer en mycket grundläggande fråga:
Vilket lager arbetar vi i?
Det låter nästan trivialt.
Det är det inte.
Lagerkontext hör till allt som följer.
Lager.
Dokument.
Platser.
Plockning.
Omflyttningar.
Revisionshistorik.
Undantag.

Processen kan se helt frisk ut medan den körs i fel kontext.
Det är precis den typen av problem som en skärmdump sällan avslöjar.
Och precis den typen av gräns som COCO gillar att ifrågasätta.

Språk är enkelt tills det inte är det
Tyska.
Engelska.
Kroatiska.
Norska.
Och andra.

En användarprofil definierar de tillgängliga språken.
Operatören byter språk medan applikationen är igång.
Gränssnittet ändras omedelbart.
Affärsprocessen får inte det.
Den skillnaden är viktig.
Lagret flyttar sig inte för att ordet för lager ändrades.
Plockordern startar inte om för att användaren valde ett annat språk.
En reservation försvinner inte.
Ett undantag tillhör inte plötsligt en annan transaktion.
Processen förblir där den är.
Endast dess representation förändras.
Det låter uppenbart.

Tills man inser hur många applikationer behandlar ett språkbyte nästan som en ny session.

En flerspråkig affärsapplikation borde inte göra det.
Presentationsläget kan ändras.
Affärsläget måste förbli stabilt.
Det gör språkbyte till ett förvånansvärt användbart regressionstest.
En liten funktion.
En mycket bra brottlinje.
COCO gillar brottlinjer.

Steg för steg börjar applikationen samla historik
Varor anländer.
Processen går framåt.
Godsmottagningen bokas.
Lagret förändras.
Lagerstatusen speglar den nya verkligheten.
Plockningen börjar.
Lagersaldo blir reserverat.
Operatören får en uppgift.

En mobil vy reducerar hela processen till det som spelar roll i just det ögonblicket:
Position.
Lagerplats.
Kvantitet.
SSCC.
Operatör.
Inget mer.
Inget mindre.
Det är viktigt.
Det mobila gränssnittet är inte en andra affärsprocess.
Det är en annan vy av samma process.
Lagerapplikationen får veta allt.
Plockaren behöver inte.
Clarity betyder inte alltid att visa mer information.
Ibland betyder clarity disciplinen att dölja nästan allt.

Sedan skannar någon fel plats
Här blir ett logistikflöde mer intressant än en funktionslista.
Den förväntade platsen är en sak.
Den skannade platsen är en annan.
Flow stannar.
Kraschar inte.
Stannar.
Det är en skillnad.
Processtatusen förblir synlig.
Det påverkade lagersaldot förblir begripligt.
Undantaget blir explicit.

Kontextuell hjälp förklarar vad som är relevant för den aktuella situationen.
Användaren löser avvikelsen.
Processen fortsätter.
Det här ögonblicket säger mer om operativ mjukvara än flera sidor med happy-path-skärmdumpar.
Verklig logistik är inte svårt när allt är korrekt.
Verklig logistik blir svårt när något är nästan korrekt.
Ett användbart system döljer inte det bakom en grön instrumentpanel.
Det ger undantaget en status.

En anledning.
En historik.
Och en väg framåt.

Dokument minns det människor glömmer

Allteftersom flödet fortskrider börjar referenser ackumuleras.
ASN.
Godsmottagning.
Lagerrörelse.
Plockning.
Utleverans.
Flow.
Den intressanta delen är inte att dokument existerar.
Den intressanta delen är att de berättar samma historia som processen.
Varför är detta lagersaldo här?
Vilken mottagning introducerade det?
Vilken operation reserverade det?
Vilken plockning förbrukade det?
Vilken leverans flyttade ut det?
Löstes ett undantag före nästa steg?
Vilket var det aktiva lagret?
Vad hände innan det nuvarande läget?
När status och dokumentation produceras av samma process blir spårbarheten lättare att lita på.
När de inte gör det börjar människor så småningom rekonstruera historiken.
Vanligtvis i Excel.
Vanligtvis under press.
Vanligtvis efter att något redan gått fel.
COCO föredrar bevis före det ögonblicket.
Tydligen reser COCO också
Det fanns en annan liten förändring mellan körningarna.
Ubuntu hade sin körning.
Red Hat Enterprise Linux 10 tog nästa.
COCO fortsatte.
Ingen ceremoni.
Inget speciellt "Red Hat-läge".
Inget omskrivet flöde.
Inget bekvämt förenklat test.
Samma Flow.
Annan mark under det.
En tidigare COCO-körning hade redan testat applikationen på Ubuntu Linux.
Den nuvarande flyttade till Red Hat Enterprise Linux 10.
Annan skrivbordsmiljö.
Andra systembibliotek.
Annan paketering.
Annan driftsmiljö.
Samma lager.
Samma affärslägen.
Samma lagerövergångar.
Samma språkbyten.
Samma undantagslogik.
Samma bevis.
Det är ett ganska bra sätt att testa plattformsoberoende mjukvara.

Annonsera inte att det är plattformsoberoende. Flytta det. Se sedan vad som går sönder.

Språkstatus.
Lagerkontext.
Dialogbeteende.
Timing.
Teman.
Processövergångar.
Undantagshantering.
Bevis.
Operativsystem har förvånansvärt kreativa sätt att exponera antaganden.

Ubuntu exponerade några.
Red Hat exponerar andra.
Det är användbart.

Eftersom plattformsoberoende teknik inte är förmågan att starta den körbara filen två gånger.

Det är förmågan att ändra miljön utan att ändra processens innebörd.
En lageroperatör borde inte bry sig om applikationen körs på Ubuntu eller Red Hat.
En plockorder borde inte bry sig heller.
Inte heller en revisionsspår.
Om plattformsskillnader börjar ändra affärsbeteendet är mjukvaran inte verkligt plattformsoberoende.
Den är bara portabel.
COCO verkar betydligt mer intresserad av den första definitionen.
Det är vi också.

COCO bestämmer inte vad korrekt logistik betyder
Den här delen är viktig.
COCO blir inte en lagerexpert bara för att det kan följa ett lagerflöde.
Människor definierar fortfarande korrekthet.
Människor bestämmer när lager blir tillgängligt.
Människor definierar vad en blockerad leverans betyder.
Människor bestämmer vem som får korrigera en kvantitet.
Människor definierar vilken rörelse som kräver en revisionsspår.
Människor bestämmer hur en giltig undantagslösning ser ut.
Människor bestämmer när en leverans är verkligt komplett.
COCOs jobb är annorlunda.

Upprepa.
Observera.
Jämföra.
Minnas.
Lämna bevis.

Gör det sedan igen efter att mjukvaran ändras.
Och igen.
Och igen.
Utan att bli uttråkad.
Utan att bestämma att förra veckans resultat förmodligen fortfarande gäller.
Utan att hoppa över det irriterande undantaget för att lunchen är om tolv minuter.
Den glamorösa framtiden för AI-testning innehåller en förvånansvärd mängd upprepning.
Vi betraktar det som en funktion.

Bevis förändrar samtalet
Traditionell testning slutar ofta med en helt rimlig mening:
"Det fungerade när jag testade det."

COCO är intresserad av nästa mening.

Vad fungerade exakt?
Vilket lager?
Vilken användare?
Vilket språk?
Vilket processläge?
Vilken sekvens?
Vilket dokument?
Vilket lagervärde?
Vad hände omedelbart före teststeget?
Vad ändrades omedelbart efteråt?
Kan en annan ingenjör förstå resultatet utan att fråga personen som utförde testet?
Det är där regressionstestning blir mer än upprepad klickning.
En skärm kan vara korrekt medan processen är fel.
Ett plockfönster kan se perfekt ut medan lagret redan drivit iväg.
Ett dokument kan existera medan tillståndet som borde ha skapat det aldrig inträffade.
En applikation kan visa 100 % medan en revisionsspår tyst är oense.
COCO följer Flow eftersom det är i Flow som dessa motsägelser blir synliga.

Någonstans mellan Control och Flow
Det finns en intressant symmetri här.
Bra logistikmjukvara försöker minska osäkerheten inom en verksamhet.
Bra testning försöker minska osäkerheten om mjukvaran som kör den.
Den ena frågar:
Var är artikeln?
Den andra frågar:
Hur vet vi att mjukvaran fortfarande vet det?
Den ena frågar:
Var denna rörelse slutförd?
Den andra frågar:
Vilket bevis visar att statusen ändrades korrekt?
Den ena frågar:
Kan nästa skift fortsätta?
Den andra frågar:
Kan nästa ingenjör förstå vad som hände?
Olika frågor.
Samma instinkt.
Gör statusen synlig.
Bevara resonemanget.
Minska mängden kunskap som bara finns i någons huvud.
Kanske är det kopplingen vi inte ursprungligen planerade.

Teknisk excellens utan banderollen
Ingen klickar på en Engineering Excellence-knapp.
Det finns ingen.
Och det borde det förmodligen inte finnas.
Teknisk excellens visar sig indirekt.
Lagerkontexten överlever ett språkbyte.
Samma process överlever en annan Linux-plattform.
En lagerrörelse förblir spårbar.
En mobil plockare ser exakt det som behövs och inget annat.
Ett undantag avbryter processen utan att förstöra dess status.
Hjälpfönstret förklarar den aktuella kontexten istället för att visa generisk dokumentation.
Dokumentkedjan stämmer överens med den operativa sekvensen.
Nästa ingenjör kan förstå vad som hände utan att fråga personen som råkade vara där.
Det finns gott om teater tillgänglig i modern mjukvara.
AI kan generera imponerande demonstrationer.
Instrumentpaneler kan animeras.
Siffror kan röra sig.
Videor kan se väldigt övertygande ut.
Inget av det bevisar att två lageroperationer inte tyst kan producera ett felaktigt resultat.
Inget av det bevisar att ett undantag fortfarande kan rekonstrueras veckor senare.
Inget av det bevisar att lagerarbetaren, speditören, och utvecklaren tittar på samma operativa sanning.

Teknisk excellens börjar på en mindre fotogen plats.

Med konsekvens.
Med bevis.
Med gränser.

Med viljan att hålla de tråkiga delarna tråkiga.
Osynlig tillförlitlighet producerar sällan den mest dramatiska skärmdumpen.
Tills man medvetet börjar leta efter den.

Control. Clarity. Flow.
Control är att veta vilket lager, vilken process, och vilket läge som är aktivt.
Clarity är att förstå vad som förändrades, när det förändrades, och varför.
Flow är att låta verksamheten fortsätta utan att förlora historien bakom den.
Det fungerar för logistik.
Det fungerar för mjukvarutestning.
Det fungerar förvånansvärt bra för teknik i sig.
Det första Flow-experimentet gav COCO Administration.
Användare.
Roller.
Databaser.
Språk.
Sedan gav någon det ett lager.
Sedan flera språk.
Sedan mobil plockning.
Sedan lager.
Sedan omflyttningar.
Sedan undantag.
Sedan dokument.
Sedan ett annat operativsystem.
Vid denna punkt borde vi förmodligen sluta lägga till saker.
Det kommer vi förmodligen inte att göra.

Control. Clarity. Flow.

Ubuntu hade sin tur.

Red Hat har den nuvarande.

Flow fortsätter att röra sig.

COCO fortsätter att titta.
Och någonstans mitt i den sista körningen blev det uppenbart att det finns ytterligare en fråga som väntar bakom denna.

Vi vet vad det är.
COCO vet vad det är.
Du vet inte.
Än.

Vi skulle kunna berätta för dig.

Men då kanske du slutar kolla om en ny Insiders-artikel har dykt upp.
Och det skulle förstöra experimentet.

Till ingenjören som öppnar detta repository för första gången: Välkommen.
Du kanske har kommit hit för att något gick fel.
En tjänst slutade svara.
En driftsättning betedde sig oväntat.
Ett larm väckte dig mitt i natten.
Eller så är du bara nyfiken på hur den här plattformen fungerar.
Vad som än förde dig hit, vet att detta projekt byggdes för exakt sådana stunder.
Inte för att ta bort svåra problem.
Utan för att göra svåra problem begripliga.
Du kommer att hitta kod.
Du kommer att hitta dokumentation.
Du kommer att hitta specifikationer.
Men ännu viktigare,
hoppas jag att du kommer att hitta resonemang.
Någon före dig ställde svåra frågor.
Någon samlade bevis.
Någon fattade beslut.
Någon förklarade varför.
Dessa förklaringar är en del av plattformen.
Behandla dem med samma respekt som källkoden.
En dag kommer du att förbättra något.
Kanske är det en liten bugg.
Kanske är det en helt ny förmåga.
Vad du än ändrar, kom ihåg att en annan ingenjör så småningom kommer att ärva ditt arbete.
Lämna dem mer än fungerande mjukvara.
Lämna dem förståelse.
Förklara din avsikt.
Dokumentera dina antaganden.
Bevara dina bevis.
Berätta historien bakom beslutet.
Den historien kan en dag spara någon timmar — eller dagar — av utredning.
Var inte rädd för att ersätta teknik.
Ersätt bibliotek.
Ersätt leverantörer.
Ersätt driftsättningsmodeller.
Ersätt programmeringsspråk.
Ersätt arkitekturer om nödvändigt.
Men innan du ersätter en idé, förstå varför den fanns.
Framsteg utan förståelse är bara förändring.
Framsteg byggt på förståelse blir utveckling.
Det kommer att finnas stunder då plattformen överraskar dig.
Behandla dessa stunder som gåvor.
Varje överraskning avslöjar något som arkitekturen ännu inte förstod.
Undersök tålmodigt.
Samla bevis.
Förbättra genomtänkt.
Lämna sedan lärdomen efter dig till dem som följer.
Så växer teknisk kunskap.
Det kommer också att finnas stunder då inget intressant händer.
Även de stunderna betyder något.
Tysta system är ofta friska system.

Om COCO tonar bort i bakgrunden för att incidenter blir kortare,
för att förklaringar blir tydligare, för att onboarding blir enklare, för att ingenjörer litar på bevisen, då lyckas plattformen.
Osynlig pålitlighet är en av de högsta formerna av teknisk excellens.
Mät inte det här projektet efter antalet automatiseringar det utför.
Mät det efter frågor som dessa:

• Blir folk avbrutna mindre ofta?
• Förstår ingenjörer system djupare?
• Är viktiga beslut lättare att förklara?
• Överlever operativ kunskap teamförändringar?
• Upprepas misstag mer sällan?
• Blir nya ingenjörer produktiva snabbare?

Det är resultaten värda att bevara.
Kom slutligen ihåg att ingen handbok är komplett.
Ingen specifikation förutspår varje framtid.
Ingen arkitektur överlever oförändrad för alltid.
Det är ingen svaghet.
Det är en inbjudan.
Observera verkligheten.
Ifrågasätt antaganden.
Förbättra plattformen.
Lär dem som kommer efter dig.
Och när din egen tid som förvaltare så småningom tar slut, lämna efter dig ett system som är lugnare, tydligare, mer begripligt och mer pålitligt än det du ärvde.

Om varje generation gör det, kommer COCO aldrig riktigt att bli föråldrat.
För dess största tillgång kommer inte att vara dess mjukvara.
Det kommer att vara den tekniska disciplin som förs vidare av de människor som fortsätter bygga den.
Tack för att du blev en av dem.
Nästa kapitel finns inte längre i den här handboken.
Nästa kapitel finns i koden du är på väg att skriva.

COCO-handboken

För mjukvara utvecklas.
En bra arkitektur utvecklas långsammare.
Och en bra filosofi bör överleva dem båda.

softify.pro