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.