Success

Vad är framgång för ett projekt?

Pengar givetvis. Vi gillar alla pengar. Dock är ju framgång ett djur med många personligheter (wow, going overboard with the liknelser där).

Frågar du projektledaren (=tid-, budgetstyrd), så handlar det om att leverera det som kunden frågat efter (dvs i princip leverera så mycket så att kunden kan övertalas att det räcker och därför ser sig tvungen att punga upp med stålarna).

Produktägaren vill se pengar över tid. Skit samma om fanskapet funkar som tänkt och byggdes på tid och pengar - nu ska det se till att dra in stålar också. Nya kunder och nya användare.

Ledningen sitter såklart och räknar pengar in och pengar ut (skit vore väl annars). Förhoppningsvis ser de också goodwill som ett värde; även om ett enskilt projekt/produkt går i stöpet av nån anledning, så kan kunden ändå tänkas beställa mer om projektet genomfördes på ett rätt och riktigt sätt.


Utvecklarna är nöjda i fallande ordning efter följande:

1. Systemet genererar inga problem som trillar ner så långt att jag behöver göra nåt
2. Systemet har användare
3. Systemet har glada användare
4. Systemet tjänar pengar

Notera att listan ovan gäller en luttrad utvecklare. En ung, oförstörd dito skulle kanske ha punkt 3 överst och punkt 1 längst ner.

Notera även att listan ovan gör en luttrad cyniker glad även om systemet aldrig kom i drift (ty ett system ej i drift genererar inga problem, se även http://hellrefaraherde.blogspot.com/2007/12/dlig-dag-p-jobbet.html).

Antalet problem som ett system genererar kan, i idealfallet, antas vara en linjär funktion av antalet användare.

Då utesluter man faktorer som att en dubbling av antalet användare kommer locka fram de där prestandaproblemen som ligger och lurar nånstans långt inne i buken på systemet; querysarna som funkar så fint i testmiljön, men som i verkligheten joinar de fetaste tabellerna i en 20 minuters full-table-search-fest.

Disk är billigt, det vet man. Raidade kanske inte lika. Vad man vet dock är att allt jävelskap loggar. Fett med gig med webserver-loggar (till 99,9999999 procent ointressanta, men man måste ju ha dem ifall det är nån som bråkar med systemet).

Backuperna på databasen måste såklart tas. Och sparas nånstans.

Rapporter måste filas på för att gå att köra i rimlig tid när datamängderna växer.

Kort sagt, ditt system blir som en trädgård du anlagt med gräs, fruktträds-yngel och buskar som sen gödslas och växer i en rasande takt så att du efter ett tag inte har tid att lägga ner häcksaxen ens för en kopp kaffe.

Resultatet blir att problemen växer med kvadraten på antalet användare.

Pengar kan antas växa linjärt med antalet kunder/användare på ett system.

See the problem here?

Eftersom man i slutändan (när man står framför Sankte Per?) mäts efter hur mycket pengar produkten drar in så kan man lakoniskt konstatera att om detta mått på framgång används (och vad annat vore rimligt), så gäller följande:

Om produkten blir riktigt framgångsrik så kommer du att sitta med arslet fullt, äta mer Losec än Kicki D äter falukorv och ha ett rätt ryckigt arbetsschema med nattmanglingar remote hemifrån).

Då är det dags att se till att man har ordentligt betalt eller att söka sig till greener pastures...

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