Hvilke "common grounds" er det rimelig å forvente?

Programmering
#1

Vi snakket litt om dette i tråden om formattering. En common ground er ting utviklere på teamet har til felles, dvs ting de kan / forstår. Spørsmålet er, hva er det rimelig å forvente?

Noen mener at man skal forvente så lite som mulig, og skrive koden på enklest mulig måte med så få abstraksjoner som mulig.

Andre tenker ikke så mye på dette. De bruker patterns of abstraksjoner fordi det er gøy, og kanskje litt fordi man føler seg smart, eller kanskje det rett og slett er vanskelig å skrive enklere kode.

Ifølge den studien som ble nevnt i tråden om formattering leser man kompakt kode raskere (kompakt som i færre tokens). Det tar omtrent like lang tid å forstå, gitt at man kjenner til den mer kompakte syntaksen (common ground). Det betyr at man burde utnytte seg av common grounds dersom mulig, men spørsmålet er igjen hvor langt man burde dra det.

Et annet interessant spørsmål er hva man gjør dersom det ikke er en common ground, men hvor det er mye å tjene på å ha det. Skal man forvente at folk leser seg opp og viser interesse for det? Skal man kjøre fagsesjoner?

Eksempler på ting som er common ground er avhengig av språket man bruker. Det er fordi hvert språk har en “idiomatisk” måte det blir skrevet på. Mulig det er nettopp dette som bør forventes som common ground også.

Til slutt: har du noen gode eksempler på common grounds / mangel på common grounds?

2 Likes
#2

Sykt spennende tema du tar opp!

Noen av mine tanker rundt dette:

For å kunne jobbe effektivt i “prosjekt-arbeidet” burde en deltaker ha en forståelse for det som er common-grounds for nettopp dette “prosjekt-arbeidet”, og man kan da si at å oppnå en forståelse for common-gounds er en type “front-loaded” arbeid som kreves før man effektivt kan ta del.

Elementer ved common-ground er bla. normer og regler for et gitt språk/teknologi på kryss av prosjekt/organisasjoner og bedrifter mm. Det er etter min erfaring knyttet sterke forventninger til nettopp kunnskap rund slike common-grounds hos de fleste utviklere/team/organisasjoner.
Men i tillegg til common-ground forbundet med språk/teknologi har man normer/regler forkortelser osv. knyttet opp mot domenet prosjektet tilhører, bedriften/organisasjonen som står for prosjektet og til slutt innad selve prosjektet.

Det er her jeg trur vektingen av forventet front-loaded arbeid i forbindelse med common-ground kan gjøres forskjellig basert på ulike parametere.

En bedrift/team/organisasjon med få deltakere, med lite “gjennomtrekk” kan kanskje bli ytterlige effektive med en økt andel front-loaded arbeid. Gitt det front-loada arbeidet faktisk forbedrer ytelsen til detalkerne.
Dette fordi jo lengre en person jobber på et prosjekt, dess større utbytte får man fra det det front-loada arbeidet.
Derimot større bedrifter med høyt “gjennomtrekk” av deltakere vil kanskje tjene på å ha en mindre andel front-loaded arbeid og prøve å kun følge språk/teknologi normer, men ellers ha utfyllende lettleselig kode. For eksempel store organisasjoner der det kan være flere 100 ulike utviklere(konsulenter) innom i løpet av et år, da vil man potensielt tjene på at disse bruker mest mulig tid på utvikling og minst mulig på front-loaded arbeid.

Så tenker jeg at komposisjon og fremtidig forventet komposisjon av deltakere spiller en rolle.
Hvis common-ground krever mye av deltakerene, men de som har evnen til å gjennomføre får mye igjen for det over tid, vil dette lønne seg der man kan garantere at alle eller flertallet er i stand til nettopp dette.
I tilfeller der fleretallet av utviklere, og potensielt et økende flertall i fremtiden, ikke har kapasitet til å forstå/sette seg inni forventet common-grounds vil dette kanskje over tid ha en negativ effekt.
Selv om det i utgangspunktet økte effektiviteten til teamet som originalt implementerte denne formen for common-grounds.

Det finnes sikkert andre eksempler på parametere som er avgjørende for faktisk utbytte av mindre eller økende grad av common-grounds. Og å finne relevante måter/metodikker for å vekte disse trur jeg kan være veldig interessant og nyttig.

2 Likes
#3

Veldig mange interessante punkter! Where to begin…

Interessant at du nevner “flertallet av utviklere”. Det betyr kanskje at “common” i common ground ikke nødvendigvis må gjelde alle. En god leder vil forhåpentlig være i stand til å vurdere hvor mange som er mange nok, og dermed si ja/nei til en ny teknologi/metodikk/etc. Lurer på hvor mye lederskap har å si her (kontra hva hver enkelt utvikler gjør).

Også interessant med tradeoff’en mellom tid brukt på å bygge common ground på forhånd vs. tid brukt på prosjektet. Utdanning er faktisk et godt eksempel på front-loaded arbeid, så en bra start er å forvente minimum det man lærer på bachelor/master, avhengig av hvilken utdanning personene på teamet har.

Du nevner også dette med konsulentarbeid vs in-house. Mulig at den mantraen om å skrive så enkelt som mulig kommer av at det er mange konsulenter, og at disse ofte lider når de kommer inn i et nytt prosjekt med mange antakelser om common grounds som ikke stemmer. (altså, mye kan vel forklares av dårlig kode også :stuck_out_tongue: )

Her er et par spørsmål man kan stille seg for å ta bedre avgjørelser (basert på posten din):

  • Hva er ansett som idiomatisk i språket / teknologien vi bruker?
  • Hvor mye erfaring/utdanning har personene på teamet?
  • Hvor lenge varer prosjektet?
  • Hvor mange nye utviklere må vi lære opp gjennom prosjektet?

En ting som mangler fra lista er hvilke personligheter man har på teamet, hvilke interesser de har, etc. Dette kan man knytte til ansettelsesprosessen også: Hvor mye overlapp burde det være i teamet fra start?

2 Likes
#4

Først må jeg komme med en liten disclaimer om at jeg har veldig begrenset erfaring fra arbeidslivet som utvikler. Når det er sagt så var den første tanken som slo meg at dette må være bakgrunn for mye frustrasjon, og tilsvarende må klarhet i dette være veldig nyttig. Som shuggapie skriver, ser jeg også for meg at det er en standard som mest effektivt kan defineres for og av spesifikke team. Og kanskje burde det være en dynamisk og iterativ prosess som man besøker på nytt av og til?

Til slutt lurer jeg på - Kan det å sette en lav standard for common-ground være en effektiv måte å hindre “over engineering”? (Er dette er reelt problem i arbeidslivet?)

#5

Helt enig. Har veldig troa på endringsvillige teams generelt. Hvis ikke blir det fort en cargo cult (vi gjør det fordi det er sånn det gjøres, men vi vet ikke hvorfor)

Ja, det kan være et problem. Men jeg tror ikke lav common ground fikser det. Hvis du bestemmer deg for å aldri bruke avanserte teknikker fordi du er redd for konsekvensene vil du heller ikke lære noe om når disse teknikkene er verdt kostnadene. For å unngå over engineering ville jeg heller satset på kritisk tenkning rundt løsninger. Dvs: hvilket problem er det vi faktisk skal løse, og vil den foreslåtte løsningen løse problemet? Eller vil den bare løse teoretiske problemer som vi ikke har?

Edit: det vil for så vidt hindre over engineering, men ikke under engineering, som kan være vel så ille

Edit 2: Når jeg tenker meg om kan man fint drive over engineering uten å bruke avanserte teknikker, så det er ikke nødvendigvis relatert

1 Like
#6

Ja helt enig, var litt lite gjennomtenkt gitt :sweat_smile:

Da slenger jeg ut nytt spørsmål jeg: Har dere inntrykk av at kravene til hva som kan defineres som common-ground generelt settes for lavt eller for høyt? Og hvorfor er det sånn?

#7

Hehe, nei synes det var et fornuftig spørsmål jeg. Det henger jo litt sammen det her. Over engineering kan oppstår fordi man bruker avanserte teknikker, men kan også oppstå med enkle teknikker på problemer man ikke har. Den første krever en høyere forståelse av tekniske konsepter, mens den andre kanskje krever mer forståelse av løsningen som helhet, hvorfor valg ble tatt på en gitt måte, etc.

Godt spørsmål…

Jeg har en liten teori… Du har to typer teams:

  1. Teams med dårlig samarbeid og lav trygghet. Her er du redd for å få tredd ting over hodet. Du er redd for nye ting fordi du ikke føler deg inkludert i avgjørelsen. Du faller tilbake til “enkelt er best, for da slipper jeg å være redd”.
  2. Teams med godt samarbeid og høy trygghet. Dumme spørsmål er ikke dumme. Nye ideer diskuteres. Nye implementasjoner går gjennom code review. Du føler deg inkludert i avgjørelser.

I team nr 1 må man ha lave krav til common ground for å unngå frykt, og dermed unngå forhåndsdømming av nye løsninger. Disse lave kravene vil holde teamet tilbake. Setter man høyere krav vil det også holde teamet tilbake. Det finnes ingen gode løsninger annet enn å bedre kulturen på teamet.

I team nr 2 settes kravene til common ground dynamisk basert på hva teamet synes er fornuftig. Uansett hvilket nivå man ender opp på blir det det riktige nivået for nettopp dette teamet.

Altså: Kravene som settes blir riktige eller feil avhengig av hvor godt teamet fungerer. Spørsmålet kan dermed reduseres til “Er software teams generelt gode eller dårlige?”. Og her er det jo gradsforskjeller som gjør det veldig vanskelig å finne et godt svar.

Det som mangler fra denne teorien er det som @shuggapie nevner om hva slags prosjekt det er, hvilken tidsramme det er snakk om osv. Hvis man tenker på dette i kontekst av gode/dårlige teams tror jeg mye handler om godt lederskap. En god leder vil ha bedre oversikt over prosjektet som helhet enn det utviklerne har.

2 Likes