Drömkod

Jag läste "Dreaming in Code" av Scott Rosenberg. Den handlar om utvecklingen av ett open source-program som heter Chandler, och utspelar sig mellan 2003 och 2006. Under denna tid lyckas utvecklare+chefer begå i stort sett vartenda misstag som existerar. Med detta som bakgrund berättar författaren för läsare som inte kan programmera om olika programmerings-relaterade fenomen, som jak-rakning, the mythical man month, Extreme Programming, katedralen och bizarren.

Det är kul att läsa om ett utveckling, även om det i det aktuella fallet är smärtsamt och pinsamt, lite The Office sådär. Jag har även problem med själva berättandet. Författaren gör avstickare för att ge bakgrund och teoretisera, ibland 30 sidor i taget. Själva berättelsen hamnar i bakgrunden. Eventuellt hade det varit mer intressant om jag inte känt till det mesta innan, men jag har svårt att acceptera för långa pauser i berättelser. Vi lär av Charles Bukowski!

Författaren har en djupt pessimistisk syn på mjukvaruutveckling. Det går inte att få till det. Det går inte att planera, det går inte att estimera. Det finns utvecklingsprocesser, men de funkar bara för de som utvecklat dem, och kanske inte ens för dem. Programmerare vill inte vara med om någon planering, det vill bara optimera sina verktyg istället för att skriva vettig kod. Jag tror att det är den typen av attityd som saboterar många projekt. Man tror inte att det finns något som hjälper, och om man testar något som borde hjälpa så tar man det inte på allvar, och så fort man misslyckas så misströstar man och går tillbaks till en kombination av vattenfall och cowboy-programmering. Inte för att det är bättre, utan för att det är det som är bekvämast för alla inblandade: projektledarna kan planera på det sätt som är mest bekvämt för dem (Olle jobbar på A i två månader, Kalle jobbar på B i 4 månader) och utvecklarna slipper alla former av struktur och får skriva kod ostört.

Några teoretiker finner dock nåd inför Rosenbergs ögon: Brooks "The Mythical Man-Month" hänvisas det flitigt till, på det där naiva sättet som det brukar göra ("Kan vi verkligen ta in en ny utvecklare nu, det är ju bara 3 månader kvar till releasen, tänk om det blir kaos, tänk på att man-månaden är mytisk!"), eftersom det är den enda teorin om utveckling som alla känner till. Eric S. Raymonds "The Cathedral and the Bazaar" hänvisas det flitigt till, även om det ganska tydligt framgår att dess beskrivning av open source-projekt bara stämmer på ett fåtal större projekt. Joel Spolsky ges också stort utrymme att prisa Microsoft och slå ner på alla sätt att försöka strukturera upp utvecklingsprojekt.

Boken pendlar mellan tumme upp och tumme ner. När det handlar om hur Chandler-gänget försöker designa klart allt innan de börjar koda, eller väljer motsatt inriktning, så är det bra, men frustrerande. När det handlar om allmän data-historia så är det ofta ganska trist.

Version 1.0 av Chandler verkar ha släppts för några år sedan, sådär 5 år senare än tänkt. Jag laddade ner 1.0.3 för Mac, men det gick inte att starta på min dator.

Mediakonsumtion med mera

Förra veckan köpte jag en Jobs Mini för att ha som mediaspelare. På den installerade jag Boxee, som jag fått rekommenderat. Boxee är en typ av mediacenter. Det ger mig ett UI på TV:n och låter mig spela film och musik på datorn och på internet. Jag har inte köpt någon fjärrkontroll, men det funkar med Jobs-telefonen.

Tyvärr är inte Boxee helt stabilt. Ibland knäpper det till i högtalarna på ett ganska obehagligt sätt. Det är dåligt på att avsluta sig när man försöker logga ut. Men det gör inte så himla mycket. Det är ganska bra. Med alla de här små apparna som visar video från internet så breddas mitt TV-utbud på ett ganska härligt sätt. Open University, säger jag bara. Fan vad jag kan nörda ner mig i universitetskurser från Stanford om antikens historia.

Men det finns några nackdelar. Fanskapet kan inte scrobbla musiken jag lyssnar på. Om någon lyssnar på musik och internet inte hör, finns musiken då på riktigt? Sen kan man inte skapa playlists, så man får lyssna på en skiva i taget. Lite sådär som på 90-talet, när man manuellt måste byta skiva. Lite bättre än på 80-talet när man måste byta efter en halv skiva, men inte så väldigt 2010.

Boxee är baserad på kod från ett open source-projekt som heter XBMC. Väldigt open sourcigt namn, måste jag säga. XBMC kan scrobbla. Plus-poäng för XBMC. XBMC har ett sjukt open sourcigt sätt att installera plugins och appar: man browsar runt i kataloger i ett svn-repository. Minus-poäng för XBMC. Det gör att jag inte kan byta. Så jag antar att jag får försöka klara mig utan audioscrobbler tills de fixar det.

Ett tag funderade jag på att skriva mitt eget mediacenter istället. En app som låter mig browsa innehållet på min hårddisk, som spelar filmer med VLC och musik med mpd. Det hade varit något det. Men orka...

Lösningen på alla problem är som vanligt att skriva ett gnälligt blogginlägg. Kom ihåg var du läste det först!

Är dörren halvstängd eller halvöppen?

Här är en bra artikel om hur man som utvecklare kan konkurrera med open source-mjukvara. Många bra poänger om brister i typiska open source-projekt, som kan destilleras ner till "open source-utvecklaren bryr sig inte om andra användare än sig själv". Det kan handla om användarvänlighet (okej att en n00b inte klarar av att ladda ner saker från sourceforge, jag tycker också att det är orimligt krångligt), design, support, kommunikation, men den för mig mest intressanta punkten är den sista: rent teknisk kvalitet.

Standardtugget i open source-världen, i Stallman- och framför allt Raymond-traditionen, är att open source-kod är bättre, eftersom vem som helst kan inspektera den, buggfixa den, förbättra den på alla möjliga sätt. Men det händer inte med automatik, de flesta små projekt utvecklas av en ensam nörd. Den mesta kod som skrivs här i världen är dålig, oavsett om det sker på ett stort företag eller nattetid i ett sovrum.

Det är dessutom inte så att all kod som skrivs på fritiden är open source, eller att all kod som skrivs på arbetstid är stängd. Men oavsett var och när du skriver kod, så är du ett undantag om du är duktig på det. Och kodskrivande är ändå bara en liten del av mjukvaruutveckling.

Dålig information

Hur fylls det tomrum som uppstod då Paig Saghamullit slutade posta på sin blogg? Inte alls, tror jag, och jag har inga ambitioner att vara lika radikalt avfärdande som han, men lite gnäll kan jag alltid stå för...

LIMO kom upp i en diskussion på jobbet, och jag insåg att jag egentligen inte hade en aning om vad LIMO är. Internets to the helpers! Well... Hemsidan är inte direkt informativ. Det är en mobilplattform, eller en standard, och det är en Linux-kärna i botten. Men vad ingår egentligen?

Kolla in den här illustrationen. Jag förstår inte riktigt. Ingår "Application UI Framework" och "Application Mgr Framework" i plattformen? Jag vet inte, det känns som om det borde stå tillsammans med de andra sakerna i så fall, innanför middleware-ramen. Ska det vara ett GTK-UI, eller ska telefontillverkaren bygga sitt eget? Kommer någon typ av referens-applikationer ingå, som i t.ex. S60, eller ska telefontillverkaren bygga allt från scratch? Och om GTK, som inte känns så hett på telefoner, ska ingå i plattformen, innebär det att telefontillverkaren helst ska bygga sitt eget lager ovanpå det illaluktande plattforms-UI:t, som på Windows Mobile?

Och vad är egentligen anledningen till att informationen är så bristfällig? Är det för att de inte har något att visa upp, att det de har att visa upp är dåligt, eller att de helt enkelt inte ser någon anledning att dela med sig av teknisk information? Det känns inte speciellt Linux, ett intryck som förstärks av det tydligen väldigt viktiga DRM-ramverket. Men det är väl som det ska vara med Linux-projekt som drivs av klassiskt onda företag som inte fattar att open source har mer att erbjuda än kod som man kan plocka upp och springa sin väg med.

Eller för att sammanfatta, ett citat från Agoraphobic Nosebleeds lysande skiva Frozen Corpse Stuffed with Dope: Go have sex with Jesus Christ, you faggot!

Öupen såårs

Sedan det tillkännagavs att Symbian ska bli open source så har den delen av bloggsfären försökt fatta vad det innebär. Det är tydligen svårt. Alla som blir utsatta för det första gången verkar tänka "det kommer leda till anarki". Ungefär sådär som Andrew Tanenbaum tänkte för 15 år sedan, då han kom fram till att Linux aldrig skulle funka. Och det leder inte till vilken typ av anarki som helst, det är total anarki som gäller. Du kanske sitter på Nokia och jobbar på en ny telefon, och plötsligt har någon idiot i Singapore skickat in en patch som gör att din telefon går sönder. Hur detta faktiskt skulle kunna hända i praktiken ägnar man inte mycket tankemöda åt, man antar helt enkelt att det kommer bli så. Och detta problem måste man lösa.

Jag läste någon blogpostning igår, som bland annat handlade om hur binär-kompatibiliteten i Symbian ska kunna uppehållas när Symbian blir open source. När man stöter på den typen av naiva resonemang vill man först ta sig för pannan, sen hälla i sig en panna sprit, sen slå skallen i en värmepanna. Det bloggosfären inte inser är att ingenting ändras i och med att man släpper sin kod som open source, förutom att personalstyrkan kan komma att bli mer flytande. Just så. Inte nödvändigtvis större, men något mindre lättplanerad. Det är fortfarande samma människa som kommer bestämma vad som inkluderas i nästa release. Inte någon galning i Nya Zeeland. Hur ska galningen i Nya Zeeland kunna göra det? Ska ni helt enkelt ge honom fri tillgång till ert versionshanteringssystem, och varför skulle ni göra det? Han är ju helt galen!

Det var också något förvirrat resonemang kring vilka som skulle få bidra med kod (vilket totalt motsäger antagandet ovan, om att vem som helst skulle kunna skicka in kod var som helst). Tydligen skulle man kunna få bidra med kod till open source-Symbian om man hade ett gott renommé inom branchen. Ni kanske skulle försöka lära er av de som kan det här. Bra kod är bra kod, oavsett vem som skriver den, och dålig kod är dålig kod, även om personen som skrivit den råkar vara anställd av Symbian idag. Har ni funderat på att skaffa en Linus? Det är inte svårt att inspektera kod om man kan produkten den ska in i.