Scrumbled Eggs

Vi kör ju Scrum. Såklart. Nåt annat (som inte på annat sätt är tillräckligt agilt typ XP) år 2007 vore som ta en helkväll på Stureplan iförd banlonpolo, terylene-byxor och helskägg - ganska bakåtsträvande/framstegsfientligt alltså.

Scrum hanterar i princip deadlines genom att säga 'den tredje november har vi release'. Vad som kommer med då är de högst prioriterade backlog items som vi hunnit med. Man har något körbart efter varje sprint som, i princip, kan tas i drift närsomhelst förutsatt att det iaf täcker in de mest basala (och högst prioriterade) backlog items som krävs för att systemet skall kunna ge nån affärsnytta.

I bästa fall får man kunden med sig på tåget genom att de inser att de kommer få ett bättre, mer ändamålsenligt system än om det utvecklas med mer traditionella metoder, gärna kryddat med en vag kravspec och framtaget till fastpris och med hård deadline.

Har suttit i mer än ett fastpris/vag kravspec/hård deadline-projekt och kan intyga att det tar fram de värsta sidorna hos människan. Kunden försöker knö in så mycket features som bara är möjligt givet den vaga kravspecen medan projektet stretar åt andra hållet och ledningen piskar utvecklarna till att jobba kväll och helg in absurdum.

Resultatet blir ofta minst ett av följande:

• Kraschat projekt
• Law suits och rättstvister
• Pajade personliga relationer för de stackars utvecklarna
• Brain drain på företaget när de utnyttjade stackarna flyr till grönare ängder
• Total förtroendekris mellan kund och leverantör

Jag har suttit i ett projekt som prickade in fyra av de fem ovanstående punkterna (det blev aldrig law suit, men advokater togs in som lusläste kontrakt för att se om möjligheten fanns).

Så varför berättar jag då detta? Jo, vi som iaf officiellt höjer Scrum till skyarna har precis sålt in ett projekt till kund på fastpris, med vag kravspec och hård deadline.

Låt oss be till de högre makterna att det inte går som det brukar...

Läs mer om Scrum här: http://hellrefaraherde.blogspot.com/2007/11/15-minuter-daglig-masspsykos.html

Konflikträdsla

Hur kan det komma sig att vuxna män (let's face it, det är mest Y-kromosomer i vår bransch) som utan att blinka droppar tabeller i produktionsdatabasen när så krävs, får en liten svettpärla i pannan när de får en konflikt i svn?

Så till den milda grad att de ger sig på att committa sina ändringar både på trunken och den branch vi fixar buggar på (och därmed bäddar för klart mer skumma mergningar senare).

Det är också de som får en osäkerhetsrynka i pannan när ändringar ska mergas mellan brancher.

Det är nåt med versionshantering som gör att folk regredierar till ett osäkert finnigt högstadietillstånd och med flackande blick väntar på att nån annan ska ta tag i det. När mergningar, commits och branchningar är det säkraste man kan hålla på med - gör man fel ber man bara "mamma svn" snällt att ta fram det man hade nyss. Det är det svn är bra på.

Testa att be mysql snällt att ta tillbaka tabellen du just droppade av misstag så märker du skillnaden...

Dålig dag på jobbet

Hade en dålig dag på jobbet idag. Saker och ting går snett, vi får ta ner systemet oplanerat och får ett gäng arga användare och en del städa-upp-jobb i databasen.

Tänker nostalgiskt tillbaka på min tid i post-IT-bubble-Sverige. Det fanns fortfarande ett gäng företag som hade kvar pengar i sin säck från de galna dagarna då riskkapitalisterna kastade miljoner över vilken sunk-idé som helst. Har själv suttit med på ett möte med riskkapitalister i egenskap av tekniskt förkläde och hört dem kläcka ur sig att '35 miljoner? Vi går aldrig in med mindre än 50 miljoner' (företaget jag jobbade på hade räknat ut att de behövde 35 miljoner).

Att det var så ruggigt enkelt att äska pengar blev också indirekt the downfall för många projekt. Det måste vara det bästa sättet att ta död på ett företag: tvångsmata det med en gigantisk pengapåse (jag har sett det inifrån flera gånger). Sen mäts hur bra det går på hur snabbt stålarna rinner iväg, som om det fanns nån korrelation.

Det som egentligen betyder nåt - leverans - var helt underordnat. Detta ledde till (baserat på tron att botten på pengapåsen aldrig kommer dyka upp):

• Hyreskontrakt mitt i stan på fett stor yta. Gärna bundet på 5 år så man helt säkert får sitta med ett osäljbart kontrakt i evigheter när hyresmarknaden viker.
• Personalpyramiden (upp-och-ner-vänd). Ett järngäng på 5 utvecklare och sen en chefsorganisation värdig en tysk pansarkår. Inköpschef? självklart - det behövs såklart nån som köper fax-papper (detta var innan faxen var i princip helt utrotad) och pennor. Produktägare, marknadschef, säljchef, gruppchefer och fan och hans moster
• Ingen leverans nånsin. Det mest inbitna vattenfallstänket möjligt med lång specfas och sen en implementation som sträcker sig över år. Eftersom ingen mätte framgång med nåt så påtagligt som en leverabel, så togs en dylik heller inte fram
  

Resultatet blev såklart det man borde ha kunnat se. Pengarna tar slut. Inget användbart har tagits fram. Företaget blöder som en gris från hyreskontrakt och onödig personal. Riskkapitalisterna drar öronen åt sig för att bubblan spruckit. De där 'bara' 25 miljonerna till som man räknat fram skall räcka kommer aldrig. Och sen varsel i omgångar och sen konkurs.

På plussidan måste framhållas den galghumor som utvecklas hos personalen, man har faktiskt ofta som roligast under den här tiden. Att man blir av med jobbet vet man ju redan så den tid man har kvar går åt till att snacka skit och utsätta kollegor för practical jokes.

Så varför blir jag då nostalgisk? Jo (i skenet av min dåliga dag på jobbet), så påminns jag om alla hyllkilometrar kod jag var med och skrev under denna galna tid. Kod som jag fick bra betalt för att skriva. Kod som aldrig nånsin kördes i produktion. Kod som aldrig nånsin ställde till med problem.

Eller för att travestera general William Tecumseh Sherman (1820-1891): The only good code is the dead code...

Fåraherde movin' up!

Söker man på fåraherde på google.se så hamnar Hellre fåraherde på 5:e plats. Samma sökning på google.com renderar en 11:e plats.

Snart, om vi alla hjälps åt och cross-länkar, så kan vi ta den eftertraktade förstaplatsen för sökordet 'fåraherde'!

Moving up in the world!

Clusterfuck

Ursäkta titeln (som faktiskt inte är snuskig, se http://www.urbandictionary.com/define.php?term=clusterfuck).

Det jag ska negga om idag är klustring. Möjligen går det ett sus i utvecklarleden när jag skriver detta (nåja, ett sus bland de typ 12 ynka själar som hittat hit).

Klustring är väl det vedertagna sättet att säkra skalbarhet?
Dissa inte klustring, len!

(eftersom jag redan börjat länka till ordlistesajter och din förortssvenska kanske är lika skral som min: http://sv.wikipedia.org/wiki/F%C3%B6rortssvensk_ordlista)

Alla har vi väl hört någon på tekniksidan säga (eller i värsta fall sagt själva) på ett möte där business case-killarna skissar på scenarier med 25000 samtidiga användare:
"Det är lugnt, vi klustrar lösningen och adderar bara noder för att skala. Vår applikationsserver stöder klustring och databasen med"

Det är här vi går på samma mina som management gör när grabbarna från Rational (se http://hellrefaraherde.blogspot.com/2007/11/uml-underliggande-megakomplext-elnde.html)

kommer och säljer in metodik och svindyra verktyg: Vi hugger på silver-bullet-wobblern som en vårpilsk gädda!

Vad gäller management så får de ett paket med verktyg och rigida dokumenteringsregler som ger en illusion av ordning och reda, effektiv utvecklingsprocess och ROI (påminn mig förresten att jag ska skalla alla som säger ROI i tid och otid - 'När kan vi få ROI på den här fitchjurn?')

Utvecklarna får en illusion av en lans med vilken den mest skrämmande av alla bestar - prestandaproblemen - kan dräpas.

Missförstå mig rätt - jag anser såklart inte att man ska ha en dunderburk till server som gör allt - självklart behövs lastdelning mellan maskiner med olika ansvarsområden och möjlighet att addera fler burkar när det behövs (och om det hjälper).

Skillnaden är då att man får en 'klustring' som är skräddarsydd för ditt system - en fast nyckel istället för en skiftnyckel (och som alla som testat vet, så spöar den fasta nyckeln skiftnyckeln every time)

Eller för att dra till med en annan liknelse - hur sugen är du på att köpa ett par unisex-byxor i one-size-fits-all-stretch? Låter inte optimalt...

Skiftnyckeln/byxorna i det här exemplet är din applikationsservers/databas/messaging engine eller whatever's inbyggda lösning för att klustra upp systemet i brygga. Den har säkert som fjäll i Feskekörka:

• Kommit till främst för att tillfredsställa säljarna på produktföretagen som måste erbjuda klustring eftersom konkurrenterna har det
  
• Blivit så generell att den inte löser något specifikt problem (dvs t ex ditt systems) bra
  
• Blivit feature-bloated med distribuerade cachar, hot node deploying och fan och hans moster - inte ett öga torrt
  
• Pga feature-bloatningen blivit helt omöjlig att konfigurera för en vanlig dödlig - specialkonsulter måste tas in för att vada i träsket med XML-config-filer
  

Ovanstående information och t ex en brasklapp om att inte alla system passar för att klustra med just applikationsserver X:s inbyggda klustringsstöd står ingenstans att finna.

T o m mysql har skitnödigt lagt till klustringsstöd som ingenstans marknadsförs som nåt annat än det bästa sen skivat bröd.

Vi gjorde ett testskott med ett mysql-kluster i ett projekt jag jobbade i förut.
Första setup (innan klustring):

• Två servrar, en master och en replika som select-nod. Vi normaliserar prestanda på denna setup till 100%
• Andra setup (med klustring):
  Fyra servrar (minimalt mysql-kluster), samma applikation - Prestanda: 50%

Vi får en skalbarhetsfaktor på 4! Fast vänta... Åt fel håll. Hälften så snabbt med dubbelt så mycket hårdvara.

Hittade sen äntligen nåt obskyrt dokument på nätet som faktiskt erkände att mysql-klustring ställer en hel del krav på applikationens karaktär för att rocka. T ex gillar den inte joins så mycket. Då blir overheaden när servrarna pratar med varann så stor att systemet knäar.

Så om din applikation aldrig joinar tabeller utan bara gör uppslagningar på primary keys (fat chance) så kan mysql-klustring få din Volkswagen att bli en Porsche.

Men, vadå? Klustring funkar ju för världens mest använda gigantokluster Google?
Japp, men det gör det precis just för att de byggde en speciallösning för deras specifika behov, ett distribuerat operativsystem byggt enbart för snabb sökning och skalbarhet.

Hade de valt att sjösätta i WebLogic (eller insert valfri applikationsserver här) och klustra med deras stöd (vilken absurd tanke!) så skulle nog en google-fråga ge svar efter ett par kvartal istället för millisekunder...

Suboptimering

Satt häromdan och peer-reviewade lite kod. En kollega hade gjort ungefär följande:

(om du inte är intresserad av detaljerna så räcker det med att sammanfatta med 'komplex och felbenägen', så kan du scrolla ner och läsa resten)

• Skapat en klass som hette typ ValueCache vars syfte var att cacha 'semikonstanta' värden från databasen för att undvika databasåtkomster
• ValueCache:n instansieras i class-loading-time, varför en speciell mekanism fanns implementerad för att undvika att den läste från databasen vid initiering, eftersom risken fanns att db-connection poolen inte alltid kunde antas vara igång vid den tidpunkten
• Förra punkten innebär ju en risk att cachen är tom första gången nån frågar efter ett värde, så därför fanns en check som initierade cachen från databasen om den var tom
• Cachen har en time-to-live efter vilken hela cachen läses om
• Eftersom man då ibland joxar med hashmappen medan andra delar av systemet potentiellt läser samtidigt, så var anrättningen kryddad med synchronized-block till höger och vänster
• En freakish detalj var att cachen själv kunde slå av sig om den inte funkade nåt bra. Om man ändrar ett value (som cachades i cachen själv) i runtime, så revertar cachen till att gå direkt mot databasen (dvs precis som innan tjogtals icke-triviala kodrader skrevs, med den skillnaden att alla trådar potentiellt måste köa i synchronized-blocken som lagts till)

Jag stirrade fåraktigt på koden som hade vuxit till en Behemoth från en i grunden (one could argue) sund tanke att cacha lite data för att minska databasåtkomster.

Testfallen var enkeltrådade (eftersom det ju är krångligt att skriva bra multitrådade testfall) vilket ju liksom förfelar hela syftet - det är ju först i en lastad multitrådad miljö cachen skulle kunna ha en positiv effekt och också då den visar om den inte funkar som den ska.

Här satt jag nu och tittade på en lösning på ett problem som inte fanns. Våra eventuella prestandaproblem kommer (och det vågar jag sätta en tusing på) inte bero på slagningar mot en tabell med namn-värde-par på ett par tjog rader (med index, no less).

Det vi snarare jobbar med prestandamässigt är att få IIS att serva content i tillräcklig fart vid hög last samt några queries som inte har ett jota med valuecachen att göra.

Min gissning är att (om vi inte rycker koden) och går live med lösningen, fortare än attan får använda avstängningsmekanismen och sen ha en bara lite sämre lösning än vi hade innan.

Koden riskerar att ligga kvar, lika död som en fallen gnu på stäppen. Alltför complex-looking för att nån annan, inte insatt, ska våga ta bort den eller ändra nåt (tar man bort den så kompilerar ju inte testfallet - hu så läskigt).

Slutsats (och det är ju en gammal sanning som verkar ha svårt att sjunka in hos folk):

• OPTIMERA INTE
• OM DU MÅSTE OPTIMERA - OPTIMERA RÄTT SAKER
• OPTIMERA BARA SAKER SOM ÄR PROBLEM PÅ RIKTIGT OCH DÄR DET FINNS MÖJLIGHET ATT MÄTA INNAN OCH EFTER FÖR ATT SE ATT OPTIMERINGEN VERKLIGEN OPTIMERAT NÅT

Det finns en massa duktiga erfarna programmerare därute som räknar bytes och optimerar sina små uppslagningar i sina egna hemkokta datastrukturer med egna implementationer av B-träd.

Helt i onödan. Till gagn för ingen....

Caveat 1: Cachning funkar aldrig felfritt första gången du sjösätter det

Caveat 2: Komplex kod kan vara kul att skriva, men det är alltid den enkla lösningen som blir elegant