Size matters

Hvordan skal jeg løse dette problemet på mest mulig effektiv måte? Det er når man kan stille seg dette spørsmålet at det er gøy å være programmerer. Men altfor ofte blir spørsmålet heller: Hvordan i helvetet får jeg løst dette problemet innenfor arkitektur-rammene som har blitt bestemt? Her er det mindre morro å være programmerer. Man har haugevis av potensielt gode løsninger, men får ikke lov til å implementere dem pga arkitekturbestemmelser.

Hvordan havner man i slike situasjoner? Kan de unngås?

Er det arkitekten sin skyld?

Det er lett å skylde på arkitekten og kalle ham (eller henne) for en idiot og et stabeist, men er dette rettferdig? Både ja og nei. Stabeist er kanskje korrekt, men idiot er vedkomne neppe. Intelligens er evnen til å finne gode generiske modeller som kan brukes til å finne løsninger i en kaotisk hverdag. Idioter pugger tallene i boka og ser ikke sammenhenger. Intelligente mennesker lærer seg reglene for å regne seg frem til alle mulige tall – ikke bare de i boka. En god og intelligent arkitekt er en som kan finne enkle overordnede strategier som gjør applikasjonen som helhet ryddig og pen. Fra et kaos av brukerhistorier og kundekrav skal han eller hun finne enkle og elegante strategier som kan brukes til å løse alt. Hvis alle programmerere kunne gjøre akkurat som de ville for hver brukerhistorie, hadde koden endt opp i kaos. Alle hadde funnet opp sine egne hjul, og noen av dem hadde nok vært ganske kantete og skjeve. I vedlikeholdbarhetens navn om ikke annet er det klart at arkitekten ønsker seg felles løsninger og forutsigbare implementasjoner. Men finnes det alltid én løsning som passer overalt? «Gjør alt så enkelt som mulig, men ikke enklere» sa Einstein. IQ-tester måler evnen til å finne enklere løsninger, men de måler ikke nødvendigvis evnen til å se når nok er nok.

Maks antall personer = 150

Når utviklernes hoved-utfordring er å få løsningen til å passe inn i arkitekturen er det klart at noe har gått galt. Min teori er at disse situasjonene er et tegn på at prosjektet har blitt for stort. Akkurat som at store firmaer gjerne er mye tregere enn mindre firmaer, blir store prosjekter tregere enn små. Tregere både når det gjelder utførelse av eksisterende oppgaver, og enda mer når det gjelder innføring av nye prosesser. Antropologen Robin Dunbar har oppdaget at 150 mennesker det meste folk klarer å holde styr på. Det militære og flere firmaer har tatt dette med i betraktning og passer på at organisasjons-enheter aldri inneholder mer enn 150 mennesker. Selv om man ikke kjenner alle, så vet man hvem de er og hvor de jobber. Hvis man trenger noe gjort, kan man bare gå bort til den man vet man bør snakke med, og få det gjort der og da. Når organisasjonen vokser over 150 mennesker vet man ikke lenger hvem det er man må kontakte for å løse problemene sine. Man må da henvende seg til sjefen sin, eller en helpdesk på andre siden av kloden eller noe slikt, og håpe på at de igjen klarer å finne frem til den som kan hjelpe. Jo større og bedre organisert bedriften er, jo mindre effektiv blir kommunikasjonen. Når IT-support sitter i Jakarta, lønningskontoret er i Stavanger og markedsføringen foregår i Dubai, så blir det dårligere kommunikasjon enn om alle var i samme bygg. Mange mener at slik må det bare være når firmaet vokser, for man kan da ikke ha lønnskontor, IT-support og markedsføring i hvert eneste kontor når man har hundrevis av kontorer verden over. Jeg er ikke enig. I smidige prosjekter utvikler man ikke database-koden, business-logikken og GUI-koden hver for seg. Man utvikler brukerhistorier hver for seg. GUI, business-logikk og database-greier samtidig. Jeg tror noen store firmaer kunne lære mye her. Istedenfor å samle alle IT-avdelinger under ett tak, tror jeg det lønner seg å heller samle alle som har med samme produkt under ett tak. Design, produksjon, markedsføring, IT-support og alt som hører med til et produkt. Hver business-enhet bør være istand til å tjene penger. Slik organisering koster kanskje mer, men den vil også produsere og tjene mer.

Maks antall klasser i et prosjekt = ?

Mye av det samme skjer i store software-prosjekter. Når prosjektet vokser og vokser ender man fort med å gruppere koden etter «software tier» og ikke etter bruksområde. Man lager regler som at «slik snakker vi med databasen» og «slik skriver vi rapporter». Og reglene gjelder for alle uansett. Jeg tror man med fordel heller burde dele prosjektet inn i separate produkter. Produktene vil bestå av en samling av brukerhistoriene som passer sammen på et vis. Disse produktene trenger ikke ha samme regler for bruk av database eller noe som helst. Arkitekten og utviklerne står fritt til å finne løsninger som passer best for akkurat dette produktet. Jeg tror ikke denne typen tankegang kommer naturlig for folk med høy IQ. IQ driver folk til å se mønster og finne fellestrekk og dermed gruppere alt som likner. Her var det oppkobling mot database, der var det oppkobling mot database – da slår vi dem sammen! Her var det et lønnskontor, der var det et lønnskontor – da slår vi dem sammen! Det føles godt og opp til et visst nivå er det selvsagt det rette å gjøre. Men et sted går grensen. Hvor da? Når bør man begynne å tenke på splitting? I business-verden er 150 et tall å huske på. Har vi tilsvarende tall for software-utvikling? Hvor mange klasser kan et prosjekt ha? Er det antall klasser vi burde telle? Siden det er så fristende å finne fellestrekk og lage felles løsninger, tror jeg det hadde vært greit å ha noen konkrete tall og grenser å forholde seg til. Når man disse grensene kan man begynne å tenke seg om: Har prosjektet blitt for stort? Kan jeg dele det inn i mindre enheter? Kanskje svarene er nei, men det er viktig å stille seg spørsmålene like vel.

5 kommentarer om “Size matters”

  1. Kanskje skillet kan gå rundt services i en SOA arkitektur? Hver service implementerer en avgrenset og sammenhengende del av løsningen og tilbyr dette som en tjeneste, og arkitekturen i hver service trenger ikke være lik.

    Man har også dette som DDD kaller Bounded Context. Innforbi hver hver av disse kan man velge forskjellige arkitekturløsninger.

  2. Veldig gode tanker og du har mye rett i det at man må ikke la arkitekturelle føringer legge hindringer på gjennomføringen. Jeg tror dagens hverdag er veldig anderledes enn den var selv for bare noen få år siden, det er en rekke viktige elementer som gjør det enklere og billigere å være mer fleksibel i arkitektur og implementering.

    Det er to viktige endringer som har skjedd: Vi har vokst opp og verktøyene våre har vokst opp!

    Det at vi har vokst opp har en kombinasjon med at vi har blitt vant til å bruke programvare som oppfører seg og ser veldig ulike ut. Vi har blitt vant til touch-baserte grensesnitt på telefonen og avanserte websider bygget i Flash, Silverlight og AJAX. Det er ikke lengre samme verdien av den tradisjonelle gjennomføringen av grensesnitt som følger «Microsoft-guidelines». Dette ser vi også veldig tydelig i det som Microsoft selv produserer, ta f.eks. Expression-pakken og sammenlign med Office-pakken. Windows Phone 7 er et annet testament til at den tradisjonelle oppbyggingen av grensesnitt ikke lengre gjelder og det er nå mulighet for å skape bedre brukeropplevelse og mer oppgave-orienterte løsninger.

    Det andre er at verktøyene våre har vokst opp, dette er veldig viktig. Nå er det enklere enn noensinne å lage systemer, noe som ofte fører til at vi graver oss selv ned i et dypt hull av kompleksitet og overdrevet med funksjonalitet og unødvendige abstraksjoner. Enklere og raskere utvikling av applikasjoner har åpnet muligheten for å betrakte programmer etter «bruk og kast» prinsippet. Det er ofte det smarte alternativet å skrive om hele systemet på nytt etter noen få år, fremfor å bruke mange millioner på å sikre et billigere vedlikehold. Vedlikeholdet av systemene vi utvikler for våre kunder er noen ganger større enn den første investeringen, og sannsynligvis vil det i enkelte tilfeller være mer hensiktsmessig å gjøre ting på nytt – Ettersom det skjer forbedringer i verktøy og rammeverk hvert eneste år, kan gevinsten man får av ny teknologi være ganske stor.

    Jeg har tro på små, fleksible og selvorganiserende grupper fremfor store organisasjoner og jeg tror slik organisering er fullt mulig selv i store organisasjoner. Som du nevner, la oss heller putte alle nødvendig kompetanse i hver gruppe og la dem løse utfordringene i felleskap, fremfor desentralisering av oppgaver.

  3. Her er det viktig å ta i betraktning modenheten i organisasjonen. Et umodent team som får lov til å gjøre ting på letteste måte kan fort havne i et uføre de ikke vet hvordan de kommer ut av, og kaster bort tid og penger. Men om teamet er modent og bevisst utsetter beslutninger og er i stand til å refaktorere et enkelt desgn ved behov kan man slippe tak i arkitekturen på en annen måte. I en smidig gjennomføring trenger man ikke ha en fastlagt arkitektur, men man lar den vokse frem. Dette betinger modenhet.

    Roy Osherove skriver om modenhet og at umodne teams trenger en sterk leder (http://5whys.com/blog/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html). Jeg tror det samme gjelder for arkitektur, som en form for teknisk lederskap.

  4. @Sondre, hadde ikke tenkt på det på den måten, men som du sier er det klart at dagens teknologi gjør det enda enklere å «gjøre som jeg sier» 🙂 Sånn skal det være!
    @Bjørn Erik, enig at det er viktig med modenhet i teamet. Smidig og scrum forutsetter kompetanse på en annen måte enn fossefalls-metodikk (hvis det er det det heter på norsk).
    Men selv arkitektur som har «vokst frem» av kompetente folk kan bli et problem hvis prosjektet blir for stort. Dette skjer typisk ved at man begynner med de viktigeste, mest grunnleggende og gjerne de enkleste brukerhistoriene i prosjektet. Innen man kommer til de litt sære tilfellene som ikke er brukt så ofte, er arkitekturen på plass og det blir klin umulig å implementere de spesielle tilfellene innenfor arkitekturen. Så ender man ofte med å klage over at kunden kommer med så teite krav. «Trenger dere virkelig det her?» «Kan dere ikke bare gjøre sånn her istedenfor?» osv.

  5. Jeg liker perspektivet til Bjørn Erik. Det er viktig at man finner en balanse mellom et team som styres av en autoritær, firkantet arkitekt og et team som ikke har styring i det hele tatt.

Legg igjen en kommentar