En takknemlighet for (teknisk) arkitektur (sammenkoblet)

En gang i tiden holdt jeg på å møte arkitekter som hadde endt opp med å jobbe med nettet.

Jeg spurte hvorfor. Noen gode svar:

• Arkitekter tenker på hvordan folk beveger seg mellom rom (sider) og hva det betyr for brukeropplevelsen – dette var i en tid da webdesignere ofte kom fra grafisk design og trakk mer på enkeltsidelayout
• Arkitekter tenker på negativt rom, og hvordan det du legger i et rom former sosial atferd – dette var i en tid da nettet før det sosiale nettet
• Arkitekter må jobbe med mange forskjellige disipliner for å lage noe, og alle disse menneskene tror de er den viktigste personen i rommet, og det er slik produktteam er også – lol

Jeg er ikke arkitekt, men noen av favorittbøkene mine handler om arkitektur.

Her er tre:

To ting som arkitektur gjør har vært i tankene mine nylig: hvordan den former forståelse og hvordan den former sin egen evolusjon.

---

Informasjonsarkitektur

Det er en sjelden designer som opererer både på makroen av strategi og kultur og organisasjoner, og mikroen av håndverk og smak og interaksjoner.

Jeff Veen er en. Jeg husker at han sa til meg en gang: Design handler om å skape den riktige mentale modellen for brukeren.

(Nå handler tydeligvis design ikke bare om det, men for det spesielle problemet jeg tok til Veen, sa han nøyaktig det jeg trengte å høre for å bli løs.)

Så jeg elsker å tenke på primitivene til funksjonalitet og innhold for brukeren og hvordan de forholder seg, slik at brukeren kan resonnere intuitivt om hva de kan gjøre med systemet, og hvordan.

Og dette er en interaktiv prosess: for en førstegangsbruker, hvordan møter de først et system og hvordan finner og lærer de over tid?

Og dette er en kognitiv prosess: mentale modeller er abstrakte; det vi oppfatter er ekte. Så hvordan skjer forståelse?

(AI-agenter bruker programvaren min. Prioriter klarhet fremfor følelser.)

---

Don Norman skrev The Design of Everyday Things (1988), høyt elsket av webdesignere, og populariserte “brukersentrert design.”

Norman tok også inn begrepet råd fra kognitiv psykologi. Som laget av JJ Gibson: å oppfatte noe er også å oppfatte hvordan man skal nærme seg det og hva man skal gjøre med det (som tidligere diskutert).

Den beste måten å legge merke til avfordances er å legge merke til hvor de går galt! Norman dører:

Noen dører krever trykte instruksjoner for å betjene, mens andre er så dårlig utformet at de får folk til å gjøre det stikk motsatte av hva de trenger for å åpne dem. Formene eller detaljene deres kan tyde på at skyving skal fungere, når det faktisk er nødvendig å trekke (eller omvendt).

Hver gang du ser en PUSH-etikett festet på som ekstrautstyr, er det papir over en normannisk dør.

Jeg var glad for å møte en normannisk dør irl denne uken.

Så jeg strekker definisjonen av arkitektur her, for å inkludere dette, men rull med det. Arkitektur er hvordan ting blir forstått.

---

Arkitektur er hvordan ting utvikler seg – hvordan de er tillatt å utvikle seg.

Det er et vakkert boligfelt på toppen av en ås i Sør-London.

Dawson’s Heights (1964) er formet som en forskjøvet dobbelbølge, og ser annerledes ut i horisonten fra alle vinkler og med hver endring av lyset. Likevel er den på nært hold også i menneskelig skala, til tross for sine 10 etasjer.

Hovedarkitekt Kate Macintosh ønsket at beboerne skulle ha balkonger, men dette ble sett på som å kaste bort offentlige penger på unødvendig luksus…

Hun visste at de ville bli fjernet fra designene hennes for å spare penger, og gjorde dem viktige:

alle balkongene på Dawson’s Heights er brannutløpsbalkongermen de er også private balkonger fordi rømningsdøren er en lås av typen “knus glass for å gå inn”, slik at du trygt kan bruke balkongen din til hva du måtte ønske.

---

Teknisk arkitektur

Så programvarearkitektur er også teamstruktur – hvem trenger å snakke med hvem – men også hvordan man kan sørge for at å gjøre noe på den raske og skitne måten også er å gjøre det på riktig måte.

Halvparten av programvarearkitekturen er å sørge for at noen kan fikse en feil i en hast, legge til funksjoner uten å ødelegge den, og være lat uten å gjøre feil.

… sa jeg i 2004.

Jeg tror dette gjelder intern programvarearkitektur og for biblioteker du importerer.

---

Saken med agentkoding er at agenter maler problemer til støv. Gi en agent et problem og en stundsløkke og – på lang sikt – vil det løse det problemet selv om det betyr å brenne en billion tokens og skrive ned til silisiumet.

Som, hvor er bunnen? Hvorfor ikke ta en vanlig engelsk spesifikasjon og slipe inn i ren montering hver gang? Det ville gått raskere.

Men vi vil at AI-agenter skal løse kodeproblemer raskt og på en måte som er vedlikeholdbar og tilpasningsdyktig og komponerbar (som drar nytte av forbedringer andre steder), og hvor hvert tillegg gjør hele stabelen bedre.

Så nederst er virkelig flotte biblioteker som kapsler inn harde problemer, med flotte grensesnitt som gjør den “riktige” måten til den enkle måten for utviklere å bygge apper med dem. Arkitektur!

Mens jeg vibber (jeg kaller det vibbing nå, ikke koding og ikke vibbing) mens jeg vibber, ser jeg på kodelinjer mindre enn noen gang før, og tenker på arkitektur mer enn noen gang før.

Jeg svetter utviklererfaring selv om menneskelige utviklere neppe noen gang vil være mitt publikum.

Hvordan lager vi biblioteker som agenter elsker?