IDG:s Computer Sweden publicerade idag en intressant artikel som tog upp sju myter om programmering och hur man avfärdar dessa. Jag tänkte här passa på att ge mina egna erfarenheter och åsikter om dem.
Myt 1 – Offshoring ger snabbare och billigare utveckling
Här håller jag rent generellt med artikelförfattaren men det finns dock exempel på projekt där detta verkligen stämmer. I mindre projekt där beställaren är tydlig och rak med exakt vad som förväntas så fungerar det alldeles utmärkt att anlita programmerare i exempelvis Indien, Nepal eller något annat asiatiskt låglöneland där kompetensen finns. Däremot kan det lika lätt sluta med totalt kaos – odokumenterad och rörig kod, svårigheter med kommunikationen på grund av både språk och tidsskillnader osv. Jag har hört berättas om projekt där man fått börja om på scratch eftersom koden som levererats hållit så låg kvalitet. I större projekt med flera utvecklare så är det normalt sett en bra idé att ha alla dessa på plats eller åtminstone inom samma land / språkområde / tidszon.
Myt 2 – Bra programmerare jobbar mycket
Här är det inte annorlunda än i vilken annan bransch som helst. Jobbar man för mycket och mår dåligt av stressen (vilket alla gör i slutändan) så presterar man generellt sett sämre. Man måste kunna hålla huvudet skärpt om man ska kunna programmera på en hög nivå. Det gäller att må bra fysiskt OCH psykiskt. Man måste se till att motionera, träna, äta rätt och sova tillräckligt. Programmerar man mer än åtta timmar varje dag så bör man ifrågasätta sin planering.
Myt 3 – Bra programmerare är tio gånger mer produktiva
Precis som artikeln påpekar så bygger denna myt helt enkelt på ett missförstånd då det påstods i en studio från 1966 att de bästa programmerarna var tio gånger mer produktiva än de sämsta. Det är en ganska irrelevant jämförelse som det känns onödigt att kommentera vidare. De sämsta programmerarna finns normalt inte på ett företag som arbetar i branschen utan det handlar om nybörjare och hobbykodare.
Myt 4 – Avancerade verktyg ger bättre resultat
Här tycker jag att författaren ganska nonchalant avfärdar en oerhört viktig punkt. Visst kan man koda en enklare webbplats utan andra hjälpmedel än Notepad om man så önskar men alla blir efter inlärning betydligt mer effektiga med en riktig kodeditor. Dessutom är det mer eller mindre ett måste med projekthanteringssystem och versionshantering när man är flera utvecklare inom en organisation. Vidare så krävs det mer avancerade tekniska lösningar om man ens ska kunna drifta de större webbplatserna, såväl nationellt som internationellt.
Myt 5 – Ju fler som tittar på koden – desto färre fel
Det här är i motsats till föregående punkt en struntmyt, vilket inte heller författaren riktigt uppfattar. Att flera personer spontant tittar på koden bara för att kontrollera densamma kanske är vanligt inom open source-projekt men inom kommersiell verksamhet existerar det knappt. Däremot är det ofta nödvändigt att flera personer är inblandade i planeringsskedet än de som sedan arbetar i projektet. Koden kontrolleras först när man märker av buggar eller om prestandan påverkas. Tester under och efter utvecklingen är normalt förekommande.
Myt 6 – Bra programmerare skriver den snabbaste koden
Den här myten kan man inte slå hål på så lätt som författaren gör. Häri ligger istället en hel del sanning. Författaren säger i princip att man ska lita på att verktygen man använder producerar effektiv kod? Det är rent nonsens. Man måste ofta, i synnerhet i webbranschen, optimera kod på egen hand och se till att den fungerar bra tillsammans med de tekniska lösningar man använder sig utav. Sedan använder man naturligtvis verktyg för att diagnosticera problemen men det är en helt annan sak.
Myt 7 – Bra kod är enkel och elegant
Detta är återigen en myt med mycket sanning i. Bra kod ska rent generellt vara såväl enkel som strukturerad och väl dokumenterad men det är inte alltid man kan skriva enkel och elegant kod. Det är inte heller effektivt att hela tiden söka efter den mest eleganta lösningen.
En sammanfattning av artikeln är väl att den förenklar och generaliserar in absurdum på många sätt och vis, mycket på grund av att programmering är så pass diversifierat idag att man inte kan dra alla språk, tekniker och branscher över en kam. Att utveckla webbtjänster för en mediekoncern skiljer sig exempelvis enormt från att underhålla system i försvarsbranschen. Man kan inte applicera samma arbetsmetoder på alla projekt utan måste anpassa lösningen efter uppgiften, precis som inom alla andra områden.
