12.22.06
Hur smart får man vara?
Jag har funderat lite på om korthet i uttryck när man programmerar kan vara dåligt. Så här har jag resonerat:
All programmering (idag) sker i ett programspråk. Ett sådant språk är höggradigt styrt och tillåter bara specifika former (syntaxen). Inget kontroversiellt ännu.
Är man nybörjare i ett språk känns allting trögt och omständligt. Allt det som tidigare gick att uttrycka så enkelt i det språk du är van med känns plötsligt som hinder. Att loopa över en kollektion blir till en jätteuppgift. Jag håller själv på och fipplar med Ruby just nu efter åratal med Java. Och det är jobbigt, minst sagt, att bara klara av enkla uppgifter.
Är man dessutom tillvand med ett tidigare språk uttrycker man ofta logik i det nya språket på samma form som man hade använt i det tidigare språket. Detta leder ofta till ganska klumpiga konstruktioner när det kanske finns smartare lösningar. Språk tenderar ju att utvecklas och bli bättre och bättre på att uttrycka intentionen hos programmeraren. C-programmerare har ofta det problemet när de ska gå över till C++ eller Java. Det blir lätt mycket procedurell kod och lite objektorientering.
Men i takt med att du vänjer dig vid ditt nya språk flyter det på allt bättre. Du lär dig fler idiom och enklare sätt att uttrycka samma logik. Du börjar känna dig hemma i språket. Till sist behöver du inte fundera så länge på hur du använder språket. Du vet bara vad du vill uttrycka och skriver ned det. Du har lärt dig språkets byggstenar som du med lätthet komponerar till allt mer komplexa uttryck. Du har då helt assimilerat språket.
Problemet är att det finns en gräns någonstans – en gräns där koden blir för smart. Den blir inte enklare och elegantare längre, utan bara kortare. En gräns där programmet plötsligt blir svårare att förstå än tidigare.
Om något är svårt att förstå så är det också svårare att underhålla. Efter några års framgång löper plötsligt ditt program risken att kastas på bitkyrkogården därför att ingen känner till koden och den verkar så knölig att sätta sig in i. Dina ”smarta” lösningar kanske inte var så smarta.
Jag skulle gärna vilja få kommentarer angående detta och kanske t.o.m. exempel från det dagliga livet på när det hela gått för långt. Stämmer mitt resonemang?
12.15.06
Reflektion över destillation
Jag läste nyligen ut boken Domain-Driven Design (DDD), av Eric Evans. I ett av kapitlen tar Eric upp ”Destillation” som ett av stegen i hur man når en uttrycksfull och djup modell av verkligheten. Det innebär, som jag tolkar det, att ständigt arbeta med design, att våga tänka om och att ständigt förfina och förenkla sin modell av verkligheten.
Enligt boken och även min egen erfarenhet är det dock något som sällan sker i utvecklingsprojekt. Ofta stannar vi vid den första designen som ser ut att fungera. Den är i bästa fall en naiv, okunnig bild av domänen – i andra fall helt felaktig. Vi kanske till slut får mjukvara som fungerar, men den är inte fantastisk.
Hur som helst, kapitlet om destillation fick mig att fundera på om inte allt kreativt arbete har inslag av två faser: Ett kreativt skapande och ett analytiskt destillerande.
Låt mig ta ett exempel: Antag att du ska skriva en text för din blogg (surprise!). Många, inklusive jag själv, arbetar på så sätt att vi först försöker få ner alla relevanta tankar vi har om ämnet, därefter låta texten vila något, för att därefter förfina och förkorta texten i ett eller flera pass. Målet är säga exakt det man vill ha sagt (maximal uttrycksfullhet) på kortaste, elegantaste sätt (maximal förståelse och tillgänglighet). På samma sätt som i Evans’ DDD innehåller denna uppgift två distinkta faser.
Ett annat exempel som omedelbart dyker upp i huvudet är brain-storming. Många känner till reglerna för brain-storming, men inte alla känner till att den egentligen ska göras i flera omgångar. Först, kreativt spekulerande och idéskapande, därefter ett kritiskt förfinande och selekterande. Och gör om tills vi är nöjda. Precis samma sak.
Annat exempel: Kodning och refaktorisering sägs visserligen göras ”kontinuerlig”, men sanningen är ju att vi systemutvecklare arbetar i två modus: 1. Få till kod som löser uppgiften vi har framför oss, och 2. förfina koden för maximal förståelse, uttrycksfullhet och återanvändning. Samma sak fast kortare faser.
En fråga man kan ställa sig då: Varför två distinkta faser? En teori kan vara att våra hjärnor inte är kopplade för att tänka kreativt och analytiskt på samma gång. Det är nästan som en slags andning. Andas in: Sätt igång hjärnan på maximal kreativt läge. Andas ut: Betrakta det du har fått fram som om du aldrig har sett det förut. Utmana det för att hitta de absolut bästa tankarna. Det är svårt att att andas in och ut samtidigt.
Som norrlänningen sa: Destillation är en del av livet.
12.07.06
Empirisk forskning om skillnad i produktivitet
Man hör ju ofta uttalanden som ”Det är 10 x skillnad i produktivitet mellan olika utvecklare”. Senaste var det Jeff Sutherland (en av Scrums grundare) som menade att det var en faktor 25! Inte så att jag betvivlar att det verkligen är stor skillnad, men man skulle kanske önska att dylika uttalanden kom med en källhänvisning.
Jag har därför letat efter forskning som bekräftar eller vederlägger eventuell skillnad i produktivitet mellan olika utvecklare. Det jag har hittat är tyvärr rätt blekt:
- ”Individual developer productivity varies considerably”, som sägs vara en av ”lagarna” för ”Software Engineering”, ur Sackman,H., Erikson,W.J., Grant,E.E.: Exploratory Experimental Studies Comparing, Online and Offline Programming Performance. Comm. ACM 11,1 (1968), 3-11 (ej gratis tyvärr)
- ”Improved motivation can cause a ten-to-one difference in developer productivity”, enligt Barry Boehm: Software Engineering Economics, Prentice Hall (1981)
Inte mycket, alltså. Och framför allt inte färskt.
När man diskuterar den här frågan hamnar man också lätt i lite unkna diskussioner om vad produktivitet egentligen är. Om jag till exempel tar en timme till att hjälpa en kollega som kört fast. Är min produktivitet då noll? Inte i min bok.
Men lite intressant att bara en faktor som att en utvecklare är högst motiverad och en annan är omotiverad kan leda till en skillnad på en faktor 10.
Systemutveckling är en folksport.
12.02.06
Få betalt för gammal kod
När jag arbetade hos min förra arbetsgivare inledde jag ett litet kompetensprojekt för att bli javacertifierad utvecklare, dvs nivå 2 i Suns certifieringsstruktur. Sun har gett certifieringen det ”lättuttalade” namnet SCJD (Sun Certified Java Developer). Nåväl, när jag hade kommit ca 90% in i projekten (jag lovar, nästan allt fungerade) så valde jag att starta eget företag. Jag vet inte om du, käre läsare, startat eget någon gång. Jag lovar, certifieringsprojekt är inte det första man tänker på. Projektet fick vila.
I 14 månader.
För en vecka sedan beslutade jag mig för att ta upp det igen. Jag bävade för vad jag skulle hitta. Hur var det uppbyggt nu igen? Fanns det tester? Just ja, det var ju skrivet i Java 1.4… Och hur skulle det gå att flytta över till Mac OS? Hade jag ens källkoden?? Frågorna var många.
Men jag behövde inte oroa mig. Efter en dag eller två var jag uppe och körde som om ingenting hade hänt. In med källkoden och dokumenten, skapa nytt projekt i Eclipse, importera ant-skriptet och… voila!
Anledningarna till att det gick relativt fort var, som jag bedömer det, tre:
- Hög grad av automatisering. Enhetstester, acceptanstester, kompilering och leveranspackning. Allt fanns och fungerade direkt. Såå skönt!
- En liten designskiss som jag hade på papper. Den gav mig överblicken som jag inte fick från källkoden.
- Java och Eclipse. Säga vad man vill om gamla Java, men att uppgradera till ny version, med nya verktyg på ett nytt operativsystem var en enkel match. Det bara funkade, med ”mac-design” och allt.
Tänk er nu in i en annan situation: Inga tester, ingen automatisering och skrivet i C++… Ibland tänker jag att utvecklingen går litet framåt i alla fall.
