Andy Hunt er en av de 17 utviklerne som var med og laget The Agile Manifesto. Dave Thomas er Ruby-utvikleren som er kjent for å ha kommet opp med konseptet Code Kata. I 1999 gikk disse to sammen og skrev boken The Pragmatic Programmer: From Journeyman to Master.

I dag er dette den boken som oftest anbefales til nye softwareutviklere, og i mange firmaer er det til og med fast praksis å dele den ut til nye ansatte. Den inneholder et hav av praksiser og andre tips til praktisk og pragmatisk utvikling – både for team og individuelle utviklere. Boken står for smidighet og kritisk tenking, oppfordrer til nysgjerrighet, og legger vekt på nødvendigheten av å stadig utvide og foredle ens kunnskaper og ferdigheter.

Mange av mine lesere har nok lest den allerede, og nå har også jeg endelig gjort det!

The Pragmatic Programmer er en god introduksjon for relativt ferske utviklere, eller mer erfarne utviklere som ikke har vært eksponert for praksisene og prinsippene tidligere. For meg personlig var det ikke så mye å hente da jeg leste den nå – etter å ha vært en aktiv smidig utvikler i noen år. Den inneholdt noen gullkorn som også jeg kunne ha nytte av, men stort sett var det kun oppfriskning av velkjent stoff.

Likevel er boken fortsatt, selv om den ble skrevet for 12 år siden, ganske frisk og aktuell, og passer for dem som vil kalle seg software craftsmen. Den går ikke veldig i dybden på temaene den tar opp, og satset i stedet på å dekke mange fasetter av det å programmere.

Det meste jeg leste var jeg veldig enig i, men det var også enkelte tips og prinsipper jeg ikke støtter. For å være ærlig synes jeg tittelen burde ha vært The Pragmatic Programmer: From Apprentice to Journeyman. Den er nemlig skrevet for dem med kun litt erfaring, og vil ta deg et stykke på veien – men ikke tale om at du vil bli noen “mester” av å lese boken.

Etter å ha skrevet The Pragmatic Programmer sammen ble Andy Hunt og Dave Thomas forretningspartnere, og publiserer nå bøker for og av programmerere under navnet The Pragmatic Bookshelf. Her finner du noen av mine favorittbøker, blant andre Seven Languages in Seven Weeks og Pragmatic Thinking & Learning. Andre, relativt kjente bøker i serier inkluderer Learn to Program, The Passionate Programmer, The RSpec Book, Ship It! og Release It!. 

En lignende bok jeg har blogget om tidligere er Code Complete.

Det er på tide med et gjensyn med de små tegneserieheltene mine. Denne gangen dreier det seg om effekten av å ha mange utviklere som jobber på det samme prosjektet.

Jeg har alltid sagt at jeg foretrekker å jobbe i små utviklingteam. Størrelsen på et team har mye å si for hvilke utfordringer man får, og hvilke resultater man kan oppnå. Historien presentert over er ikke intuitiv, men har likevel endel sannhet i seg.

Et viktig stikkord er kommunikasjon. Etterhvert som et team vokser øker også antall kommunikasjonspunkter internt i teamet, og dermed også antall steder hvor kommunikasjonen kan bryte sammen. Tiden man må dedikere til kommunikasjon øker også betraktelig (figur 1 og 2).

Sammarbeid er vanskelig! Vi fokuserer mye på å lære å bli gode programmerere, men glemmer ofte at sammarbeid er en helt egen og veldig viktig ferdighet alle team-medlemmene trenger.

For å begrense problemene med kommunikasjon i større team legger man mere vekt på formaliteter, planlegging og dokumentasjon. I tillegg kommer man ofte opp med rollen teamleder. Et tradisjonelt utviklingsteam har en sentral leder som styrer utviklerne. Denne lederen skal fungere som et kommunikasjons-nav mellom utviklerne (figur 3). Han/hun får den ekstremt vanskelige oppgaven å sanke inn all den informasjonen som er viktig fra hver utvikler, og distribuere dem som trenger det. Det sier seg selv at man blir veldig sårbar for “feil” i dette leddet.

Og fleksibiliteten er borte… Etterhvert som smidig/agile har blitt populært har man lagt mindre fokus på å ha en sentral, styrende leder, og begrenser mengden planlegging, dokumentasjon og andre formaliteter – for at man skal kunne være mer fleksibel. Et lite team er da helt nødvendig.

Men det finnes også ulemper med små team; de er mere sårbare for forstyrrelser, sykefravær og slike ting.

En teknikk som hjelper på kommunikasjonen i teamet, og som muliggjør team bestående av flere utviklere, er utstrakt bruk av parprogrammering. Når utviklere jobber i par fokuserer to og to utviklere på den samme oppgaven, og kommunikasjonen dem imellom er svært tett og forhåpentligvis god. Antall øvrige kommunikasjonslinjer reduseres (figur 4).

Men husk at parprogrammering også er vanskelig, en ferdighet man må trene opp.

Solo-utviklere bedre enn team?

Det finnes dem som hevder at det optimale teamet kun består av én utvikler. I artikkelen Why a Great Individual Is Better Than a Good Team sier Jeff Stibel at det er vanskelig å finne dyktige personer, men at hver av dem er verdt et uendelig antall middelmådige personer. Ikke bare det, men dyktige enkeltpersoner er ofte mer verdifulle enn grupper/team som inkluderer dyktige personer.

Når vi blir en del av et team synker nemlig vår evne til å yte – blant annet på grunn av kommunikasjonsutfordringen. Stibel sier:

“When an activity can be performed sufficiently by one person with adequate skills, doing the activity as a group should be avoided.”

I 2009 blogget jeg om menneske-problemet, hvor det blant annet refereres til forskning som påstår at dyktige programmerere kan være opp til 28 ganger bedre enn dårlige programmerere. Om du har en slik utvikler i stallen din, eller er en slik selv, så må du være klar over at for å ta ut potensialet i en team-setting så må man trene på kommunikasjon og sammarbeid, og fjerne det man kan av barriærer og muligheter for kommunikasjonssvikt og feil.

Har du positive erfaringer fra å delta i et større utviklingsteam? Hvordan var teamet organisert? Hva ble gjort for å sørge for at alle kunne bidra optimalt? Del gjerne dine meninger i kommentarfeltet.

PS: Jeg snakker ikke her om å sammarbeide med dedikerte testere, driftsfolk, eller personer med forretningskompetanse. Dette er selvsagt viktig i mange sammenhenger. Denne artikkelen omhandlet spesifikt team av programmerere.

Andre relaterte artikler: En smidig teamleder | Utviklerprofiler og fire ferdighetskategorier | Parprogrammering ansikt-til-ansikt | Egoløs programmering: De 10 bud

I dag ble jeg tipset om en artikkel av Ted Neward – Advice to a New Programmer – med mye bra innhold om ting han og noen andre guruer skulle ønske de hadde blitt fortalt da de startet sin karriære.

Artikkelen nevner blant annet hvordan testing gradvis har blitt en viktig aktivitet for programmerere gjennom det siste tiåret, og at det nå blir regnet som et grunnleggende ansvar utviklere har. Den trekker også frem betydningen av parprogrammering:

“… when programmers actually practice pairing for a non-trivial amount of time, they quickly discover that pairing is nothing like they imagined it to be. In fact, when I talk to developers who initially resist pairing, and then give it a shot, the reactions that emerge are overwhelmingly positive …”

En annen sannhet ertikkelen snakker om er at den raskeste måten å utvikle på er å gjøre det riktig. Kvalitet er lik fart!

“… building applications “the right way” (whatever way that is) to produce a quality application is actually faster than producing an application quickly, then spending just as much time (or more) fixing the inevitable bugs and architectural changes that appear.”

Men det Ted sier var viktigst å lære for ham er det som kalles egoløs programmering, en programmeringsstil hvor personlige faktorer minimeres for å øke kvaliteten. Denne stilen har 10 bud man kan følge for å få en bedre hverdag som deltager i et utviklingsteam. Jeg har oversatt dem til norsk:

De 10 bud

1. Forstå og aksepter at du kommer til å gjøre feil.
2. Du er ikke koden din.
3. Samme hvor mye “karate” du kan vil det alltid være noen som kan mer.
4. Ikke skriv om kode uten konsultasjon.
5. Behandle folk som kan mindre enn deg med respekt, ærbødighet, og tålmodighet.
6. Det eneste konstante i verden er endring.
7. Den eneste sanne autoritet kommer fra kunnskap, ikke fra stillingen.
8. Kjemp for det du tror på, men akseptere nederlag på en god måte.
9. Ikke bli “den fyren inne på rommet der”.
10. Kritiser kode i stedet for mennesker, være vennlig mot utvikleren, men ikke koden.

(Kilden inneholder mer utdypning av hvert bud)

Ted Neward kommenterer:

“… adherents to these 10 commandments will find themselves not only learning more, but gathering the respect and admiration of their peers at a shockingly accelerated rate.”

“However, of all of these, by far the most important principle to understand is that of the first: “You are not your code.” This is a lesson I wish every developer would be forced to learn before ever being allowed to launch a compiler or interpreter, because everything else stems from that basic realization.”

“… when somebody turns to you and says, “I think I’ve found a bug in your code,” that the right response is to say, “Oh, that’s wonderful. Where is it?” That when somebody says, “I think I have a better way of handling this particular situation,” the right response is to say, “Excellent! Show me your ideas.” And that when somebody says, “I still don’t understand how this thing works,” the right response should be, “OK, tell me what part doesn’t make sense and let’s go over it again.”

Jeg anbefaler deg å lese hele artikkelen, og gjør disse budene til dine egne. Si til deg selv hver morgen når du ankommer kontoret, og hver kveld før du sovner: “Jeg er ikke koden min!”

Et siste sitat med på veien:

Kveldens tema var Dependency Injection (DI) da dansken Mark Seeman besøkte oss i Bergen. Han snakket om principles, patterns og containers, og foredraget fløt veldig bra. Han var overbevisende og underholdende, og beviste at live koding kan fungere utmerket når det blir gjort riktig. Etter min mening var dette ett av de bedre foredragene vi har hatt på NNUG.

La meg forsøke å koke ned Marks budskapet i et par avsnitt..

Dependency Injection handler først og fremst om å gjøre koden utvidbar. Og dette er relevant for nesten alle applikasjoner – vi utvider hele tiden med ny funksjonalitet i eksisterende løsninger.

Dependency Injection gir også renere kode, kode som ikke skjuler sine avhengigheter. Slik kode gjør det vanskeligere å gjøre feil. Han disset Service Locator pattern ganske kraftig, og forklarte godt hvilke ulemper det fører med seg. I PSWinCom bruker vi en kombinasjon av dependency incetion og service locator, og jeg er smertelig klar over svakhetene med den sistnevnte teknikken. Service Locator skjuler kompleksitet, mend DI statisk deklarerer kompleksiteten.

“Don’t be tempted by the Service Locator”

Mark Seeman er aktuell med boken Dependency Injection in .NET, som lanseres på Manning om et par måneder (tilgjengelig nå gjennom MEAP).

I går kom jeg over en liten blogpost fra lederen på Institutt for Informatikk i Oslo hvor jeg via noen linker oppdaget at det pågår en liten debatt om smidig vs. fossefall som inneholder endel missoppfatninger om hva smidig er for noe. I et forsøk på å spre det jeg mener er et riktigere syn på smidig skrev jeg følgende kommentar til posten, som jeg tenkte jeg skulle gjengi her.

Når vi snakker om smidig så kan vi befinne oss på ulike nivåer. Det kan bl.a. være snakk om en filosofisk innstilling, praktisk programmering, eller prosjektstyring.

Filosofisk sett er smidig det å ta inn over seg at man aldri sitter med nok kunnskap om prosjektet før det er ferdig. Det dreier seg om en anerkjennelse av at softwareutvikling ikke har så mye til felles med bygging av broer likevel.

Dyktige utviklere har dessuten i praksis drever smidig programmering siden programmeringens begynnelse. Prøving og feiling er en naturlig del av å skape noe nytt, og å skape noe nytt gjør man hver gang i dette faget.

Og når det dreier seg om prosjektstyring så er ren fossefall desverre en utopi. Ingen prosjekter over en viss størrelse har blitt gjennomført i ren fossefall, hvor arbeidsflyten kun går én vei. Fordi man må forholde seg til realitetene fører fossefall til en stor grad av merarbeide, og ble aldri en løsning på budskjettsprekkene – hvilket det var ment å være.

Smidig vil alltid ha elementer av fossefall i seg. Man gjør ting i riktig rekkefølge når man kan. Det smidige manifestet sier f.eks. at det er verdi i å følge en plan – det er bare det at det er viktigere å reagere på endringer om/når de måtte manifistere seg. Smidig som metode er på mange måter en videreutvikling/forfining av vannfall. På det filosofiske nivået er det en større endring.

Utviklingsmetodikken jeg lærte på Universitetet på 90-tallet (RUP) er et godt eksempel på en god blanding av stereotypisk fossefall og det vi i dag ser på som moderne smidig.

Når vi snakker om praktiske prosjekter som gjennomføres i Norge i dag så vil nok hybrid-prosjektene være i flertall. Som oftest vil prosjekter arte seg som vannfall utad; kunder skal ha en fastpris, de leverer en spesifikasjon, og vil ha en leveranse ved prosjektets slutt. Internt brukes det derimot som regel smidige metoder – og man forsøker gjerne også å “undervise” kunden og få dem med seg for å få tilbakemelding underveis.

Fossefall ser ut til å fungere når man starter med en veldig god spesifikasjon. Problemet er at den strengt tatt må være 100% perfekt – hvis ikke ville man hatt fordeler med å innføre smidige metoder. Det andre problemet er at om man har en så detaljert og gjennomtenkt spesifikasjon så har det meste, eller i alle fall mye av prosjektet allerede blitt gjennomført FØR man SIER at det har startet. Derfor er fossefall ofte en illusjon.

Som nevnt et par-tre (eller fire, fem) ganger nå begynner jeg om få dager i ny jobb. Det er utrolig mange ting jeg har lyst til å ta tak i og forsøke å gjennomføre, selv om jeg selvsagt vet alt for lite om forholdene jeg kommer til og hvilke utfordringer som er viktigst – et forbehold du må ha i bakhodet når du leser denne artikkelen.

Jeg har plukket ut fire ting som jeg føler veldig sterkt for, som jeg vil forsøke å innarbeide så tidlig som mulig. Jeg håper teamet vil se verdien i disse tingene, og at ledelsen er med på at det er viktige fokusområder. Jeg vil gjøre hva jeg kan for at utviklingsavdelingen i PSWinCom skal bli en smidig enhet som kan levere høy kvalitet or respondere raskt på endringer, og for å få til det vil jeg forsøke å jobbe med følgende…

1. Kontinuerlig integrasjon

Husker jeg riktig fra intervjurundene jeg har vært igjennom bruker man i dag ingen byggserver / continuous integration server. For meg er dette en absolutt nødvendighet for et profesjonelt utviklingsteam. Jeg satser på å installere TeamCity en av de første dagene mine (siden det er den jeg har best erfaring med – kjørte en test-install på laptopen på under 2 minutter, og integrerte Snookiepoof og Foosball Manager på rundt 15 minutter).

I tillegg vil dette være en fin øvelse å gjennomføre for at jeg skal bli kjent med hvilke løsninger vi har og hvordan de henger sammen.

En integrasjonserver er viktig av mange grunner. Den sørger for at vi har software som fungerer – ikke bare på utviklerens maskin – og at vi kan release hurtig. Den sørger for at alle testene kjører gjevnlig (se neste punkt), og reduserer betraktelig problemer knyttet til merging.

Jeg vil skape en kultur hvor man gjør hva man kan for å ikke bryte builden. Jeg vil at vi skal sjekke inn endringer så ofte som mulig, og få øyeblikkelig feedback om noe er galt. Som sagt vet jeg ikke hvordan forholdene rundt dette er i PSWinCom i dag, men jeg håper vi kan etablere kontinuerlig integrasjon som et senntralt konsept i vår utviklingsprosess.

2. Testing

Det neste jeg vil sette fokus på er testing. Vi har ingen dedikerte testressurser i mitt nye selskap, men vi leverer en tjeneste hvor stabilitet er superviktig. Jeg kjenner ikke til (og tviler på) om det eksisterer noen form for automatiserte tester i dag, men jeg vil jobbe for å gradvis få systemene våre under test.

Videre vil jeg introdusere gutta for testdreven utvikling og design (TDD), og håper jeg over tid kan illustrere hvordan dette fører til design/arkitektur som er enklere å vedlikeholde og endre, og som er mer intuitiv, i tillegg til ferre bugs og mindre regresjon, hurtigere utvikling, og en større trygghet i hva man leverer.

For som Robert C. Martin sa det i hovedtalen på NDC i år: “Debatten er over. Testdreven utvikling fungerer, og det finnes ingen gode grunner til å ikke bruke det. Faktisk kan det tenkes man bør karakterisere det som uprofesjonelt å ikke bruke det.”

Igjen vil innføring av tester være en god øvelse for meg, som vil gjøre meg kjent med den eksisterende koden. Jeg leser nå Working Effectively with Legacy Code for å være bedre rystet til å skrive enhetstester for et system som i utgangspunktet ikke er designet for det.

Til slutt et lite gullkorn fra Martin Fowler: “Manual scripted testing should be a human rights violation!” Jeg tror han mener det oppriktig.

3. Kvalitetskode

Kodekvalitet har etterhvert blitt noe av det viktigste for meg som utvikler. Det er ikke nok at programvaren tilfredstiller de funksjonelle kravene – vi må også stille krav til vedlikeholbarhet, og jeg ønsker derfor at vi i vår daglige utvikling skal legge vekt på ting som enkelhet i design, ren kode, og å følge DRY, SOLID og andre prinsipper som kjennetegner en god kodebase.

Jeg ønsker også at vi skal sammarbeide godt om utviklingen som et team, og at vi skal bruke en viss grad av parprogrammering og kodegjennomgang for å øke kvaliteten og felles eierskap til koden (Coding Horror: Pair Programming vs. Code Reviews). Parprogrammering er i tillegg nok en teknikk som vil hjelpe meg som er ny på teamet til å bli kjent med de eksisterende løsningene.

4. Iterasjoner og prosess

Dette er området hvor det sansynligvis er størst forventninger til at jeg skal bruke min erfaring til å forbedre måten PSWinCom jobber på. De har brukt Scrum en viss tid, men jeg fikk inntrykket av at de selv ikke er helt fornøy med hvordan de har gjennomført det. Utfordringen er at dette punktet er det som er mest uklart for meg før jeg får et bedre innblikk i hvordan ting fungerer i dag.

Smidige prosesser er ikke enkle oppskrifter som man bare kan følge for å oppnå raskere utvikling, høyere kvalitet og forutsigbarhet. Smidige teknikker må tilpasses, og det er ikke sikkert mine erfaringer er direkte overførbare. Dessuten har det skjedd mye i Agile-miljøet etter at Scrum dukket opp (i den formen som jeg har lært); ting som Lean og Kanban er ting vi bør se nærmere på, og som sansynligvis vil passe bra i en bedrift som vår.

Uansett ser jeg på dette som en viktig oppgave – å etablere en god prosess for prioritering, planlegging og gjennomføring. Jeg ønsker at vi skal kunne slippe oppdateringer ofte – alltid ha fungerende software, og at vi skal kunne fokusere på få ting om gangen (multitasking fungere ikke!). Som jeg var inne på i forrige artikkel mener jeg det er viktig at teamet skaper denne prosessen i felleskap.

Så det var altså mine fire, smidige kjepphester. Jeg håper å kunne rapportere tilbake til mine lesere med gode erfaringer rundt alle disse om noen måneders tid.

Knagger: Clean Code, DRY, kontinuerlig integrasjon, parprogrammering, PSWinCom, Robert C. Martin, Scrum, SOLID, TeamCity, TDD

1. august begynner jeg å jobbe for PSWinCom. Stillingstittelen er Senior systemutvikler / Team-leder. Jeg vil ha ansvar for organisering av og den daglige fremdriften i utviklingsteamet, planlegging og prioritering av iterasjoner, samt fasilitere smidig utvikling. Jeg har vært teamleder i et par år nå, men når jeg bytter jobb så føler jeg liksom at jeg kan starte med blanke ark, og tenker derfor mye på hvordan jeg vil fungere i denne rollen.

Så hva innebærer teamleder-rollen i et smidig team?

vs

Noen sier at i et smidig team er alle medlemmene likeverdige, og derfor skal man ikke ha en leder. Andre, som Robert C. Martin, snakker om mentor-teams, med én absolutt leder som alle skal se opp til, og som har total avgjørelsesmakt. Selv er jeg fan av selvorganiserende team som velger sin egen beste måte å gjøre ting på. Selvorganiserende team skaper et miljø hvor man stoler mer på hverandre, og tar felles ansvar. Men slike team trenger også en leder.

Den smidige teamleder fungere mer som en gjeter, i kontrast til den mere tradisjonelle lederen, som er som en millitær offiser. (Og nei, jeg sier ikke at smidige utviklere reduseres fra soldater til sauer, lol.) En smidig teamleder løper mye mer rundt utviklingsteamet, og påfører det ikke like mye direkte kontroll. Den smidige teamlederen gir teammedlemmene råd basert på egne erfaringer, han overvåker, men overstyrer bare når det er absolutt nødvendig. Han fjerner ting som forstyrrer teamets progresjon, passer på at prosessene teamet selv har vedtatt følges, og sørger for enighet.

En av hovedoppgavene til en smidig teamleder er å passe på at man lærer av feil, og endrer prosessen deretter. Et av de viktigste prinsippene et smidig team må følge er åpenhet.., man må snakke om hva som går galt – alle må ha fullt innblikk i hva som skjer, slik at man ikke får ubehagelige overraskelser som kunne vært unngått. Lederen må få utviklerne til å føle at det er helt greit, og at det er forventet, at man innrømmer og snakker om feil, og søker hjelp så tidlig som mulig. På den måten blir man bedre over tid.

Som teamleder ønsker jeg å følge disse fire pillarene, som legger vekt på smidige verdier:

1. Led gjennom eksempel

Jeg vil være et positivt eksempel for teammedlemmene gjennom hva jeg seier og gjør – under utvikling, i møter, i lunchen, i communitiet – alle steder. Jeg har forståelse om og erfaring fra smidig utvikling, og tror at “osmose” er den beste måten å overføre denne kunnskapen på. Det er for eksempel mye vanskeligere å overtale en utvikler til å prøve TDD enn å overbevise ham om at det fungerer ved å vise det i praksis.

2. Sørg for gjennomføring

Jeg må sørge for at vi bygger oss en prosess som vi har tro på, en prosess basert på våre egne erfaringer. Vi må fokusere på å levere forretningsverdi, men på en måte som skalerer og fungerer over tid. Vi må være fokuserte, og ikke forsøke å gjøre for mange ting på en gang – den eneste måten å gå raskt på er å gå godt!

3. Skap god energi

Jeg må legge merke til når teamet er i ferd med å miste den gode energien, og bruk mitt eget engasjement og eksempel til å stimulere teamets energi – spesielt når teamet står overfor tøffe utfordringer. Om (eller rettere sagt når) teamet fra tid til annen feiler, må vi analysere situasjonen i felleskap, og jeg må motivere teamet til å prøve igjen. Jeg må stimulere til både ståpåvilje og tolmodighet.

4. Promoter felleskap

Jeg må hjelpe alle til å føle seg inkludert, verdsatt og respektert. Mennesker jobber best når de har det bra! Vi kan ikke tollerere konflikter eller klikker. Vi må skape et miljø hvor vi stoler på folkene rundt oss – at de gjør jobben de skal slik teamet/bedriften ønsker at det skal gjøres. Heldigvis får mitt inntrykk av PSWinCom sålangt meg til å tro at dette blir en av de enkleste oppgavene.

Og så gjelder det bare å huske én ting: På samme måte som jeg forventer at teamet mitt skal være åpne for nye ideer, så må også jeg være åpen for ting jeg ikke har tenkt på, og som kanskje ikke er intuitive for meg. Et smidig team utvikler seg gjennom prøving og feiling, og ulike personligheter har ulike ting å tilby prosessen.

Knagger: Smidig, Teamleder

På NDC 2009 hørte jeg bl.a. på Oren Eini (a.k.a. Ayende Rahien) snakke om Production Quality Software. Første del av sesjonen var ikke så veldig bra, men når han begynte å snakke om hvordan vi bør bygge inn driftsovervåkning i systemene våre ble jeg veldig inspirert.

Oren påpekte at drift er en viktig stakeholder i det meste vi lager, og at vi bør designe for dem. Vi bør synliggjøre systemets status og parametre på en god måte. Han foreslo at alle systemer (av en viss størrelse) bør ha en separat Operations Database som skal gi oss bedre innblikk i hva systemet til enhver tid driver med.

Ops-databasen skal inneholde observasjoner og forventninger. Observasjoner er det enkletse, og noe mange av oss gjør i dag. Å observere vil si å logge ting som skjer, som for eksempel “At date X I started some process Y with parameter Z”. Denne informasjonen kan være nyttig i mange tilfeller, ikke minst ved feilsøking (som ellers kan være utfordrende i et produksjonssystem).

Forventninger er anderledes – det kan være ting som at “90% av alle transaksjoner skal fullføres innen 5 sekunder” eller “jobb X skal kjøre hver uke”. Ops-databasen kan kontrollere disse forventningene, og trigge en eller annen form for alarm om en eller flere ikke er innfridd.

Hva hadde dette å gjøre med blogging sa du?

Det Oren spesielt foreslo var at systemet kan skrive til en blog. Alle systemer burde ha sin egen blog, og stakeholderne burde abonnere på bloggen. Bloggen til et system bør se ut og fungere som en blog skrevet av og for mennesker – titler og innhold i blogpostene må bestå av normalt språk, og det må ikke postes for hyppig (bedre å summere opp hendelser i én post om det skjer mye på en dag). Dette vil gi dem som leser bloggen et helt annet forhold til det bakenforliggende systemet.

Jeg syntes dette hørtes veldig spennende ut. Her er en mockup av hvordan jeg ser for meg en slik blog skal kommunisere:

De fleste systemer i drift har en SLA – en Service Level Agreement – som sier noe om hvordan systemet skal yte. Men vi, spesielt vi utviklere, har et alt for dårlig forhold til SLA’en. Hvordan vet vi at den er opprettholdt? Oren foreslår at Ops-systemet skal automatisere SLA’en. Systemet kjøre en automatisert audit, f.eks. hvert 30 minutt, som foretar spesifike operasjoner som innebærer database aksess, filaksess, eksekvering av prosesser, osv. Miljøet systemet kjører i kan verifiseres, tilgjengelig diskplass, responstid etc. kan måles.

Alle ulike komponenter i systemet bør ha sine egne SLA’er, og de må være laget sånn at det går an å verifisere dem. Disse vil fungere som automatiserte akseptansetester mens systemet er i drift. Observasjoner, forventninger og miljø-validering vil til sammen gi et komplett bilde av systemet i drift, man vil enklere kunne identifisere feil som inntreffer, og man vil kunne fange opp problemer før det blir så mange av dem at det får hele systemet til å “knele”.

En detalj, men likefullt et viktig poeng, er at administrasjonsgrensesnittet, hvor man kan aksessere Ops-databasen, må være separat fra produksjonsgrensesnittet. Hvis produksjonssystemet går ned må man sørge for at man fortsatt har tilgang til Operasions.

For å oppsummere: Vi må designe systemene våre med tanke på drift. Vi har hørt det før, men gjennomfører det sjelden på en god nok måte. Vi må gi driftsfolkene det de trenger, men ikke gi dem for mye, for da mister de oversikten og fokuset på hva som er viktig. Å la systemet skrive en operations blog er et eksempel på et bra grensesnitt. Den viser kun nøkkeldata / hendelser. Og la Ops-systemet foreta automatiske system-verifiseringer gjevnlig for å fange opp problemsituasjoner tidlig, og for å bevise at vår fantastiske konstruksjon overholder SLA’en.

Du kan se Oren’s Production Quality Software sesjon ved å følge denne linken.

Knagger: Ayende, NDC

Robert C. Martin’s Agile Principles, Patterns, and Practices in C# er DEN BESTE programmeringsboken jeg noen gang har lest!!!

Det er ikke så ofte man kan begynne en blogpost med en setning som det der, og bruke både all-CAPS og tre utropstegn uten å få en flau smak i munnen. Men denne boken fortjener det virkelig. Den gir deg både lyst og kunnskapen du behøver for å omforme deg selv til en ideell, smidig systemutvikler.

Boken er full av anekdoter som virkelig får deg til å fortså hva som er galt med mange prosesser i dag, og hva som kan gjøres bedre. Og den utgjør bortimot et komplett sett med teknologi-uavhengig kunnskap om hvordan du skal gå fra en diffus problemstilling til et fungerende produkt.

Section I: Agile development

Den første delen av boken handler om smidig utvikling. Bob presenterer hovedtrekkene i eXtreme Programming, og går spesielt i dybden på planlgging, testing og refakturering. Han presenterer også en veldig bra historie som viser hvordan parprogrammering kan fungere i praksis:

“In order to demonstrate XP practices, Bob Koss and Bob Martin will pair program a simple application while you watch like a fly on the wall. We will use test first design and a lot of refactoring to create our application. What follows is a faithful re-enactment of a programming episode that the two Bob’s actually did.”

Historien er også tilgjengelig online, riktignok implementert med Java-kode – du kan lese den her.

Section II: Agile design

Her begynner boken virkelig å ta av. Bob snakker først om hvorfor design “rotner” over tid, og bruker resten av del 2 til å forklare hvordan man skal unngå at dette skjer. Han går i dybden på en rekke prinsipper innen objektorientert design, de såkalte SOLID prinsippene, og selv om jeg hadde hørt og lest en god del om dem fra før var det først med denne boken at jeg virkelig begynte å forstå.

Han forklarer hvorfor prinsippene er viktige, hvordan man skal kode for å innfri dem, og ikke minst hvilken tradeoff det innebærer å følge dem. Dette siste inpirerte meg til å skrive en liten blogpost jeg kalte når skal man følge SOLID prinsippene.

Bob bruker også mye av del 2 til å snakke om UML, og bruk av design-diagrammer innenfor smidig utvikling. Mange er av den oppfatning at modellering er noe man ikke skal gjøre når man er agile, men det kan være både feil og farlig. Bob lærer deg all den UML’en som er nødvendig for en smidig utvikler, og mener mye om hvordan man skal bruke dette “verktøyet”.

Section III: The Payroll case study

I del 3 demonstrerer Bob hvordan man går fra noen diffuse krav til et komplett program. Han bruker TDD, og viser deg all koden han produserer – inkludert testene. Han forteller grundig hvordan han tenker, og vi får se hvordan han følger OO-prinsippene og hvordan koden utvikler seg over tid.

I denne delen presenteres et hav av design patterns / mønstre, den mest forståelige forklaringen av design patterns jeg har vært borti faktisk, og vi lærer hvordan de brukes for å tilfredstille de grunnleggende prinsipene. Med fare for at den som leser boken blir pattern happy lærer han bort Command, Template Method, Strategy, Adapter, Monostate, Null object, Visitor, Decorator, Gateway, Proxy, State, osv., osv.

Denne delen av boken inspirerte meg til å skrive om hvordan man bryter avhengigheter mellom klasser, hvor jeg benyttet Strategy og Adapter.

Section IV: Packaging the Payroll System

I del 4 fortsetter man med applikasjonen fra del 3. Bob forteller oss om hvordan man bryter opp et prosjekt i moduler basert på Cohesion og Coupling. Han presenterer flere prinsipper, og patterns for å understøtte disse prinsippene. Og han fortsetter å presentere enhetstester og kode.

Denne delen inpirerte meg til å kode og blogge om hvordan man kan bruke en tilstandsmaskin til å gjøre kode mer presis og fleksibel: En generisk state machine i C#.

Mot slutten implementerer han også et grafisk brukergrensesnitt, og bruker da WinForms og Model View Presenter-mønsteret (MVP). Dette er det grundigste og mest forståelige eksempelet på MVP jeg noen gang har sett.

Det kan tenkes at jeg leste denne boken på akkurat det riktige tidspunktet i min egen utvikling, og at den ikke vil passe like godt for alle. Jeg tør likevel å anbefale den på det sterkeste til alle utviklere som ikke allerede praktiserer best practices innen smidig utvikling (TDD, parprogrammering, etc.) og som ikke allerede er guruer innen objektorientert design og vedlikeholdbar kode.

Andre Uncle Bob-relaterte blogposter: En karriære innen programmering | For mange utviklere som ikke bryr seg