Najdražje napake nastanejo, ko razvoj steče, preden so jasni podatki, odgovornosti, meje sistema in načrt vzdrževanja.
Poslovni problem pred funkcionalnostmi
Projekt se mora začeti z razumevanjem odločitve ali procesa, ki ga želimo izboljšati. Seznam zaslonov ni enak opisu poslovnega problema.
Podatki kot temelj arhitekture
Treba je določiti lastništvo podatkov, identifikatorje, zgodovino sprememb, sinhronizacijo in pravila ob napakah. Slabo oblikovan podatkovni model se pozneje drago popravlja.
Meje sistema in odgovornosti
Vsaka integracija potrebuje jasen pogodbeni vmesnik, časovne omejitve, ponovne poskuse in dnevnik. Sistem mora smiselno delovati tudi takrat, ko zunanji servis ni dosegljiv.
Vzdrževanje je del izdelka
Namestitev, posodobitve, varnostne kopije, diagnostika in povrnitev prejšnje različice niso dodatki. So nujni deli profesionalne rešitve.
Manj funkcij, boljši rezultat
Prva izdaja naj reši najpomembnejši tok od začetka do konca. Dobro izbrana omejitev pogosto prinese več vrednosti kot širok nabor napol dokončanih možnosti.
Sklep
Najbolj profesionalen pristop ne skriva negotovosti. Jasno pokaže postopek, omejitve in razlog, zakaj je določena razlaga smiselna.
Katere odločitve sodijo pred prvo vrstico kode?
Pred razvojem je treba odgovoriti vsaj na vprašanja: kdo je lastnik podatkov, kateri sistem je glavni vir resnice, kako se rešitev posodablja, kako se varnostno kopira, kdo ima dostop in kaj se zgodi, ko povezava ali zunanji API odpove. Te odločitve določajo več prihodnjih stroškov kot izbira posameznega programskega jezika.
Dobro pravilo: najprej tok podatkov
Če znamo na eni strani narisati, od kod podatek pride, kdo ga spremeni in kam gre, smo že odkrili velik del arhitekture. Šele nato izbiramo baze, API-je, čakalne vrste in uporabniški vmesnik. Tak vrstni red zmanjšuje možnost, da bi tehnična rešitev postala sama sebi namen.
Kako temo uporabiti v praksi
Največ vrednosti dobimo, ko idejo prevedemo v majhen, preverljiv postopek. Najprej določimo cilj in izhodišče, nato spremenimo samo nekaj, kar lahko opazujemo, ter zabeležimo rezultat. Pri tehničnih temah to pomeni meritve, dnevnike in ponovljive teste; pri osebnih praksah pa jasen namen, časovni okvir in ločevanje subjektivnega vtisa od merljive spremembe.
Pomembna je tudi meja med možnostjo in dokazom. Zanimiva hipoteza je lahko razlog za raziskovanje, ni pa še potrjeno dejstvo. PICALLW zato pri vsebinah, kjer se stikajo tehnologija, človek in manj uveljavljeni pristopi, daje prednost transparentnosti: kaj je dobro podprto z raziskavami, kaj je praktična izkušnja in kaj ostaja eksperimentalno.