Jag och Usama

WTF?!? Fett mycket uppmärksamhet på nine-eleven (graf från bloggtoppen.se). Kan inte vara ett bra tecken. Kanske är det mrpi som lurat hit folk (se kommentar på förra inlägget). Tack i så fall, mrpi.

Skönt att någon hjälper mitt gnäll vidare ut i världen.

Personalities del 3

OK, det jag nu beskriver kanske inte är så mycket en hel personlighet utan mer ett irriterande karaktärsdrag: att låta påskina att man hela tiden vet vad den andre skall säga.

Det är lite släkt med oskicket att ta äran för andras idéer, men här försöker man liksom få credit för nån annans idé redan innan man hört den, vilket är fett irri.

Scenario: Jag hade för ett tag sen kommit på en ganska briljant idé (jo, ibland händer det faktiskt!) för att fixa ett problem med buffring av meddelanden mot ett annat system - något som vi har haft en del problems med på senaste tiden.

Jag börjar dra idén för min kollega - låt oss kalla honom Greger (var kom det namnet ifrån?):

- Jo, Greger, jag tänkte att vi för att fixa problemet så kunde vi istället för att buffra alla...
- Ja! Jag vet vad du tänker säga!
- ...OK, jag tänkte vi dels kunde sätta ner TTL för....
- Precis, jag vet!
- ...och se till att vi bara buffrar...
- Ja just det!

Ok, ni ser mönstret. Vid det här laget har man liksom tappat sugen. Syftet är rimligen att få motparten att tro att alla möjliga idéer som nån annan kan tänkas komma med redan tänkts i Gregers mästerhjärna vid nåt tillfälle.

Nåväl. Häromdagen upprepar sig situationen. Jag ska dra en idé (om än inte lika briljant) om ett annat problem för Greger.

Skillnaden denna gång är att när han första gången avbryter mig och skriker att han vet vad som försiggår i min miniskula lilla patetiska hjärna, så synar jag bluffen:

-OK, Greger. Vad är det jag tänker säga?

Pinsam tystnad och nåt mummel om att "det är nåt med hummfrumm som vi...".

HA!

Nu kanske det dröjer innan han kör det tricket på mig i alla fall...

Mera Corporate Bullshit

Kom just på lite mer saker som jag hatar med corporate bullshit-sajter. De har ofta bilder på kostym/dräkt-klädda unga skrattande människor politiskt korrekt av alla raser. Makes me wanna puke.

Och så har de nästan alltid blått i loggan och bakgrund. Jag börjar allvarligt tro att det inte är på riktigt utan att det är Satan själv som ligger bakom.

Corporate Bullshit

Har suttit idag och researchat lite på nätet efter programvara vi behöver i projektet. Det är ganska så off-the-shelf vi behöver, men man vill ju veta vad man ska köpa och att man köper rätt.

Jag har gjort det förut och kommer göra det igen (försöka hitta vettig info om produkter alltså).

Sökning på nätet tillsammans med benägen hjälp av tips från kollegor om vilka produkter som gäller. Bara surfa dit och få no-nonsense beskrivning av programvaran. White papers som beskriver hur det används och hur man integrerar. Uppriktiga redogörelser för begränsningar och scenarion för vilka man faktiskt medger att produkten inte är lämpad.

As if.

"Fleekster Enterprise Edition (Gold) 4.2 allows you to leverage your Business Expertise by data mining your Enterprise giving unprecedented reporting and monitoring possibilites while maintaining data integrity and security over all your data sources. Internet, email, messaging, push and mobile channels allow for instant data awareness across your, and your partners' organizations. In fact, it will display business graphs on your pale hairy ass if you want it to."

En massa ord (ok, påhittade, men inte långt från verkligheten), men ingen information. Över huvud taget.

Det är så jävla avkönat så att det ofta inte ens går att förstå vad de säljer. Ens för nån som varit i branschen i decennier och letar efter just det deras programvara gör.

Vem har bestämt att det ska vara så? Hoppas de att nån kostymsnubbe ska köpa skitsnacket och bestämma att man ska köpa grisen i floskel-säcken?

Jag upprepar (för alla som vill lyssna): JAG FÖRSTÅR INTE VAD ERAN PRODUKT GÖR OCH VAD NI FÖRSÖKER SÄLJA!

Bifogar för säkerhets skull också den engelska versionen för att upplysa våra engelskspråkiga vänner:

I DON'T UNDERSTAND WHAT YOUR PRODUCT DOES AND WHAT YOU ARE TRYING TO SELL!

Och då tillhör jag ändå dem som (indirekt) bestämmer vilken programvara som skall köpas, så jag borde ju tillhöra målgruppen för dessa corporate bullshit-sajter.

Påminn mig förresten om att jag skall skalla alla som använder begreppet 'leverage'...

FRA

Bara för att jag hållt käft på bloggen ett tag så betyder det inte att inte jag också kan snacka lite FRA. Sent ur startgroparna kan tyckas, men i alla fall.

Ungefär en vecka innan den olycksaliga lagen klubbades igenom försökte jag mig på lite direktdemokrati genom att maila ett urval av våra kära folkvalda för att försöka ingjuta lite folkvett och ryggrad hos dem. Jag cc:ade givetvis FRA:s generaldirektör Ingvar Åkesson så att han i lugn och ro, på kammaren, skulle kunna signalspana på mina mail även om serverparken inte snurrat igång ännu.

Reinfeldt låter ju som en repig skiva när han upprepar att lagens motståndare 'inte förstår' vad signalspaning innebär.

I så fall är vi i gott sällskap. En av riksdagsmännen (som iaf hade den goda smaken att inte svara med ett canned response, vilket de flesta gjorde), skrev bl a såhär:

... Sannolikheten att ett mejl från dig skulle fastna i FRA:s sökningar är så nära noll man kan komma - ÄVEN om du ägnade en hel vecka åt att försöka sätta ihop ett mejl som "fastnar"...

Hmm, antingen är det fullt med moroner på FRA som sitter och pillar sig i naveln. Eller också är det våra riksdagsmän som borde bli lite mer informerade.

Vad ska FRA spana på om inte innehållet i mailen? Givetvis kommer en del av spaningen innefatta en filtrering på en uppsättning nyckelord. Säkert också en hel massa andra kluriga algoritmer för att poängsätta mail på nån slags misstänkt-skala där de mest suspekta kommer granskas manuellt av nån 43-årig pot-bellied loser på FRA som aldrig riktigt blev av med sin acne.

Jag är nog rätt säker på att man skulle kunna fastna i nåt filter om man skickar lite jihad-mail mellan några yahoo-konton med arabisk-klingande användarnamn.

Sen sitter Federley och nästan gråter för att han fått smaka partipiskan. Vi har ju för f-n valt personer till riksdagen, inte partier. I annat fall skulle man ju kunna ha en person per parti och bara vikta rösterna efter valresultatet. Slut på pinsamma (för partierna) situationer där inte alla tycker som partiet.

Federley höll sen på att skita på sig av lycka när de 'tänkte om' och utsåg nåt nytt värdelöst tjänstemanna-organ som skall övervaka FRA. Då kunde han vika sig för partipiskan och slapp åka ur riksdagen och kanske faktiskt behöva söka ett riktigt jobb.

De här övervakarna över hemlige Ingvar och hans anhang kommer nog inte kunna uträtta så mycket misstänker jag. FRA:s verksamhet är ju det hemligaste som finns, så jag kan tänka mig att mötena kommer gå till ungefär så här:

Ingvar: Välkomna till juli månads möte mellan FRA och Datainspektionen

Övervakare: Hur går det egentligen till med spaningen rent tekniskt? Vad är det för begrepp ni filtrerar på? Vilka volymer av mail och annan kommunikation har blivit föremål för manuell inspektion? Har ni avvärjt några hot med hjälp av signalspaningen?

Ingvar: Nja, nu måste jag nog svara som jag gjorde vid vårt förra möte: Det är hemligt alltihop.

Övervakare: Ok, men lovar ni att ni inte gör nåt fuffens med all den här trafiken då?

Ingvar: Javisst lovar vi det. Precis som förra månaden.

Övervakare: Jahapp. Då får jag tacka så mycket, då.

Ingvar: Ja, tack själv för visat intresse!

Och vem vet? Den där kufiga snubben i din trappuppgång - han med den dåliga hyn och tveksamma hygienen. Du vet han som brukar öppna dörren bara en centimeter och stirra med ett blodsprängt öga när du är på väg upp till din lägenhet. Vem vet om inte det är vår FRA-loser som kan få för sig att privatspana lite på din trafik när ingen märker nåt.

Det är i alla fall säkert att ingen nånsin kommer få veta nåt om den saken...

No more AFK (Away From Keyboard)

Hej igen.

Tröttnade av nån anledning på att blogga. Sen gick jag av en händelse alldeles nyligen in på bloggen och insåg att allt som stod där var precis som jag tycker! Briljant! (Kanske inte så förvånande när man betänker att det var jag som skrev det).

Nåväl. Jag måste se till att mina fans (alla nio) får vad de vill, så därför har jag beslutat att börja igen.

Inte utan problem dock. Eftersom man måste logga in med ett gmail-konto på denna bloggmotorn och jag, eftersom jag är paranoid, inte använder mitt riktiga konto så krävs det att man kommer ihåg sitt pseudo-konto.

Det gjorde jag inte, vilket fördröjde mitt återträde i bloggosfären (påminn mig förresten om att jag ska skalla alla som använder begreppet 'bloggosfären').

Till sist visade det sig att IE på min laptop kom ihåg mitt pseudo-username på gmail efter att jag gått igenom alfabetets bokstäver systematiskt. När det väl var klart var det bara att använda det universella slask-lösenordet så var jag back-in-business!

Sura nu inte för att jag inte hört av mig senaste tiden, utan var istället glad, säg emot, negga o bråka, för det är det jag tänker göra.

Code Review Part Two

Kodgranskning är en vacker tanke och utförd regelbundet och med relativt korta mellanrum så blir det säkert en produktiv övning.

Alla kodgranskningar jag nånsin gjort eller varit utsatt för har varit one-offs, när nån chef får för sig att bedriva kvalitets-arbete.

Det är ju sällan så att nån ensam sitter och kodar årsvis och inte visar sin kod för nån - det är ju i princip alltid shared code ownership, så de andra i projektet är inne och pillar och fixar och det pågår såklart en ständig diskussion när man ser nåt tokigt nån gjort (för själv gör jag ju aldrig nåt tokigt ;-).

Tricket med kodgranskning är ju dock ofta att det kommer nån extern (=utanför projektet) och kikar på koden. Problemet som uppstår då är att det inte är rimligt att vederbörande läser all kod. Alternativen är stickprov, be utvecklarna plocka ut exempelkod, eller ta hjälp av nåt kodanalysverktyg som hittar skumheter i koden.

Det finns såklart svagheter med alla dessa approacher.

Alla system har sina ugly spots. Nästa kandidater för refactoring. De funkar, men koden ser för jävlig ut. Man kanske, för att spara fyra dagars utvecklingstid nån gång inför en release förra våren, la business-logik i en jsp-sida eller nåt. Man vet om det, man ska fixa det nån gång när man får tid.

Om stickprovaren hittar den koden så har man en del explaining to do. Om man själv får välja koden som skall reviewas så lär inte ful-bitarna komma med - alltså inte heller en representativ bild av systemet. Analysverktyg är bra och hittar död kod, tomma catchar och ostängda streams osv.

Problemet är att det kan bli väldigt mycket brus i rapporteringen från såna verktyg. Varningar ges ofta för saker som kan ses som kodstil snarare än suspekt kod (exempel är t ex huruvida man returnerar immutable collections, nåt som definitivt oftast är overkill utom i fallet då man bygger komponenter som skall användas av tredje part).

Ett annat problem är att man kan luras att lita på verktyget för mycket - en clean slate från analysverktyget ger en illusion av att allt är hunky-dory. Men den kan mycket väl släppa igenom en dylik kodsnutt skriven av nån projektmedlem (som borde skjutas):

public void criticalBusinessFunction() {
   try {
      // do a lot of stuff that definitely 
      // needs to be exception handled with care
   } catch(Throwable t) {
      t.printStackTrace();
   }
} 

Det bästa är nog att göra kodgranskning till en del av ett projekt från första början - granska de tio första klasserna i projektet. Återkom sedan periodiskt för att sedan släppa projektet fritt när alla är överens om hur koden skall skrivas.

Ful-bitar i projekt finns alltid och är därför ok. Bör dock märkas upp med kommentarer som förklarar varför fulfixen finns och TODO:-markeras så att de snappas upp av din favorit-IDE.

Kodanalysverktyg skall användas från början och gärna köras som en del i continous builds (varför inte publicera resultatet på intranätet).

Kaos är kanske din granne?

Yrkesmässigt så har jag bara funnits till i data-branschen. Från början till slut (inte slut, men nu) i ett ständigt tillstånd av kaos.

Ibland mindre kaos, ibland mer kaos än du skulle önska din KTH-polare-som-snodde-din-flickvän-på-tenta-puben.

Man undrar ju om livet i andra ingenjörs-vetenskaper är likadant. Är det kaos när man ska bygga en ny bro över Svartån i Örebro? Eller är det bara att använda vedertagna standarder, räkna lite på det och sen producera en ritning som den lokala byggaren omsätter i en stilig och hållfast bro?

Skillnaden i ett systemutvecklingsprojekt, om man fortsätter på bro-liknelsen, skulle kunna vara att man tre veckor innan leverans får veta att det måste gå att taxa trafikplan från den lokala flygplatsen över bron (= scope creep). Eller att skyltarna på bron måste visas i 15 språk beroende på var bilen som kör över den är registrerad.

Jag föreställer mig att bron över Svartån är mer lättspecad. Tyngden av bron plus max antal samtidiga fordon gånger pi eller nåt for safety. Rota upp nån gammal ritning över en liknande bro i Arboga, fippla lite i ett schysst CAD-verktyg och sen är man hemma.

Är det så? Har jag fel? Är det bara vi som bor i kaos? Jag uppmanar alla som jobbar med att designa broar att berätta hur det funkar i deras värld.

Code Review Part One

En strip som träffar ganska rätt vad gäller kod-review: http://www.osnews.com/images/comics/wtfm.jpg

Société Degénérale

Min första rubrik på franska! (och jo, "Degénérale" är menat som en ordvits...).

Har följt rapporteringen (http://www.svd.se/nyheter/utrikes/artikel_815041.svd) om mannen som sumpat 46 miljarder för den franska banken. Fyrtiosex tusen miljoner. I runda slängar en Ferrari 430 Scuderia om dagen i 63 år.

Alla hackar på den stackarn, men rimligen är det nåt ruttet i staten Danmark vad gäller övervakningen av dessa unga män i 30 000-kronors-kostymer som mäter sin manlighet i mätenheterna Rolex, Porsche och storleken på aktieaffärerna.

I en artikel (http://www.svd.se/nyheter/utrikes/artikel_807159.svd) står det att han "lyckades ta sig förbi de säkerhetssystem som banken satt upp". Hmm. Det måste ju ändå vara så att transaktionerna går att härleda till en viss person.

Man kan ju tro att det gått till så att vår käre vän Jerome Kerviel blivit fartblind; han har nog successivt ökat sin omsättning utan att nån slagit larm. Efter en tid känns säkert inte affärer i storleksordningen en miljard Euro som en big deal.

Man hade ju hoppats att följande konversation vid något tillfälle ägt rum på veckans personalmöte på Société Degénérale:

- Eh, bien. Låt se, denna vecka har vi en omsättning på Pierre på 650 000 Euro, Louise har omsatt 760 000 Euro. Olivier har tyvärr bara kommit upp i 270 000 Euro, skärpning Olivier.

- Oui, Monsieur Directeure.

- Bon. Sen har vi Jerome. Han har denna vecka omsatt 1800 000 000 Euro. Merde!

Inget sånt har uppenbarligen förekommit. Förmodligen en simpel rapport från trading-systemet som ingen brytt sig om att beställa.

Det går inte att förstå att de inte sett till att ha ordentlig övervakning av sina anställdas aktiviteter - speciellt i en bonusdriven ersättningsmiljö.

I alla fall är ansvaret delat mellan vår vän Jerome och de som ansvarar för säkerhet och övervakning på banken ifråga.

I värsta fall, och det är nog inte helt otroligt, kände ledningen till det och lät honom hållas så länge det gick bra. När kraschen kommer, så låter man Jerome smaka giljotin...

Ta steget?

Satt idag och kodade ramverk för XML-ifiering av objekt som en del i ett projekt för en plattform vi ska använda inom organisationen.

Kul? Javars.
Gjort det förut? You bet. Inget nytt under solen. Visst finns det utmaningar, men det mesta har man sett förut och undviker därför tidigare pitfalls man trillat i (det är väl det som erfarenhet ger).

Blev jag gladare? Hmm. Det börjar snart bli dags att fundera på om jag ska fortsätta på utvecklarbanan och bli ett skägg eller ta steget till att bli nånslags chef (fast det känns inte riktigt rätt heller).

Talande är kanske att jag tycker det är roligare att rita streck och pilar och berätta för andra (=kodapor) hur saker och ting borde implementeras istället för att koda själv.

Kodar-mässigt är jag bättre än fler jag är sämre än - fast absolut ingen superkodare. Jag kommer inte att kläcka ur mig nästa 3D-motor för first-person-shooters eller nästa trådnings-stöd i Linux-kärnan. Det jag är vass på är att bygga på befintliga grejer och se helheten. Och det räcker för att tjäna ihop till blodpuddingen.

Det tråkiga med hela chefs-biten är att det finns ju få chefsjobb som inte innefattar personalansvar. Det brukar ju annars vara den karriärväg som erbjuds - från senior utvecklare till mellanchef med utvecklingssamtal, löneförhandlingar och snack med Nisse som har alkoholproblem.

Konstigt, det där. Ta en snubbe med vässad kompetens inom ett område och ge honom ett annat jobb (=mellanchef) för vilket han har nada utbildning, noll erfarenhet och tveksam entusiasm.

Det borde finnas fler jobb där man dompterar kodaporna (=ritar pilar och streck) men slipper MS Project, Gant-scheman, budgetar, personalplanering och utvecklingssamtal med folk man knappt känner.

Har du ett jobb som passar, så hör av dig...

Could have told you so

Läste SvD om projektet GVD - Gemensam VårdDatabas (http://www.svd.se/opinion/brannpunkt/artikel_787511.svd)

En halv miljard bränd. 500 miljoner. 500 000 tusenlappar. Jag har sett det i ett liknande projekt jag själv var med i även om pengarna som brändes där kanske var en tiondel så mycket (fast 50 000 tusenlappar är ju också en slant).

Utan att veta ett skit om GVD förutom det jag läst i artikeln, så tror jag att jag har en bra idé om vad som gått snett:

Upphandling. Upphandling innebär såklart att den billigaste leverantören som uppfyller kriterierna skall göra jobbet. Det ställer dock enorma krav på de inblandade aktörerna. Att en leverantör kommer med en låg prislapp är knappast en garanti för att projektet skall lyckas (snarare tvärtom skulle jag vilja påstå).

Specning. Specningen måste vara immaculate för att det skall fungera. Upphandling innebär ju implicit en fastpris-approach och redan där har man byggt in en konflikt. I projektet jag var med i fanns det en diger spec. Diger i form av tjockleken på pärmen, kanske inte lika fyllig vad gäller innehållet. T ex specades rapportdelen sisåhär, och nu citerar jag: "Relevanta rapporter skall kunna genereras från systemet". Försök leverera till den specen i en fastpris-deal där beställaren försöker suga ut det yttersta och du som leverantör sätter klackarna i backen.

Integration. Från artikeln: "25 journalsystem av olika ålder och kvalitet". Hmm. Vi snackar säkert en härlig cocktail av system alltifrån nyutvecklat och stordatorsystem via OS/2 till Windows 3.1 med neandertal-version av Access. Helt säkert lösningar som evolverat patch-för-patch med features som styrs av semikolon-separerad data i fritextfält i databasen. En gränslös källa till problem.

Struts-mentalitet. Uppenbarligen har ledningen (som talande nog har slutat allihop enl artikeln) högaktningsfullt skitit i alla varningssignaler och istället snackat om hur bra det blir när visionen blir verklighet. As if.

Inkompetens. Jag tvivlar på att landets skarpaste hjärnor varit på plats när projektet planerades. Det finns såklart lagkrav (t ex att upphandling skall ske) som i viss mån bakbinder de inblandades möjligheter att styra projektets gång, men det är troligt att ingen från beställarsidan insåg att projektet, som det las fram, var i princip omöjligt att genomföra. Det är svårt att lägga skuld på leverantören i detta fall - det är ju inte deras sak att såga ett projekt för att det inte är genomförbart. Det enda resultatet är ju att det går till en annan leverantör.

Greed. Nu motsäger jag punkten ovan lite. Det finns självklart ett visst ansvar hos leverantören att backa ur om projektet inte är genomförbart. Här ser det ut som om de säkert insett att det här aldrig går att ro iland, men bedömt att de i alla fall kommer att få betalt för arbetet (=sno våra skattepengar). Så shame-on-you Oracle och WM-data.

Det som borde gjorts (och jag har såklart ingen aning om ifall det gjordes), är en förstudie som bedömde riskerna med projektet. Hade en bra sådan analys gjorts hade kanske vi kunde lagt 500 000 tusenlappar av våra skattepengar på äldrevård eller nåt annat nyttigt...

Personalities del 2

Mera persönlichkeiten kommer här (läs den spännande första delen här: http://hellrefaraherde.blogspot.com/2008/01/personalities.html):

The Floater. En kille med teknisk kompetens, men inte tillräckligt för att kunna bidra effektivt till projektet. Börjar ofta som utvecklare, men får glida över till mer administrativa sysslor eftersom det han producerar i kodväg inte håller måttet. Plötsligt sitter The Floater som projektledare. Sen går det via mellanchef raka vägen upp i företagsledningen. Om fem år har han optioner, bonusprogram och tjänar dubbelt så mycket som du. Det är ju f-n att man är kompetent. Notera dock att det inte är en variant på 'skit flyter uppåt'-klyschan. Det är inget större fel på karln. Bara det att The Floater inte är tillräckligt vass för att faktiskt producera nåt produktionsmässigt.

The Bit Brain. Kan ibland överlappa med The Fresh Guy. Programmeringens motsvarighet till att ha gröna fingrar. Han gillar datorer och datorer gillar honom. The Bit Brain producerar reg expar lika fort som du skriver mail. Ovärderlig tillgång i projekt - det är alltid kvalitetskod producerad i rasande fart. The Bit Brain har sällan ambitioner att ta ledande roller och bestämma saker. Du måste mata honom med en spec.

Shit-for-brains. Ej att förväxla med The Slow Poke, som faktiskt ofta är kompetent. Shit-for-brains har helt enkelt inte begåvats tillräckligt förståndsmässigt för att kunna koda. Drar ner projektets produktivitet genom att ständigt behöva långrandiga förklaringar. De uppgifter som han får, efter ingående förklaringar komplett med pseudo-kod, blir alltmer triviala alltefter att han misslyckas med att leverera. Att få Shit-for-brains tilldelad till sitt projekt innebär dessutom att de som planerar resurser tycker att de har gett dig en ny resurs, vilket gör att du hamnar längst ner i prioritetslistan nästa gång resurser skall fördelas. Jag gillar svenska arbetsrättslagar, men det vore gött om man kunde få be security följa Shit-for-brains ut ur lokalerna bärandes på en papplåda med en krukväxt och fyra pärmar och personligen elda upp hans passerkort.

The Ego. Killen som har lite för hög uppfattning om sig själv och sina förmågor. Ofta kompetent, men inte i paritet med vad han låter påskina. En udda fågel i vårt svenska jante-landskap - lite typiskt amerikansk i sin framtoning. The Ego får en att gnissla tänder i tysthet när man hör honom gå på om hur saker och ting skall göras, gärna i möten med ledningen, när man själv läst hans mediokra kod och genomskådar the bullshit. The Ego har också ofta inga problem med att ta credit för andras idéer - något som får dig att vilja karva ut hans lever med en sked (ifall det är din idé han snor). The Ego går det såklart alltid bra för. De som bestämmer saker vet såklart inte att han är medioker utan sväljer hela grejen. De hör aldrig dina tänder som gnisslar...

Nu börjar jag få slut på karaktärer. Kanske återkommer i ämnet när jag funderat lite till på folk jag haft förmånen att jobba med.

Personalities

Nu tänker jag försöka nagla ner karakteristika hos folk jag jobbat med. Alla har ju sina egenheter men vissa har fler.

The Fresh Guy - färsk från högskolan. Ivrig att lära. Ofta briljant kodare, men devoid of självförtroende. Inte sällan överglänser The Fresh Guy dig vad gäller regelrätt kodning. Du får lita till din erfarenhet och pondus (=kagge) för att hävda dig. Det funkar oftast väldigt bra eftersom The Fresh Guy saknar självförtroende och därför gärna undviker alla typer av beslut och överlåter det till dig. The Fresh Guy är en nära nog optimal tillgång i ditt projekt - produktiv, ambitiös och viker inte när det gäller att bygga tråkiga delar av systemet. Beware - The Fresh Guy kommer att försöka sno ditt jobb så fort han (eller tyvärr mer sällan hon) levlat lite på förtroendeskalan.

Pularen - ofta low-key kille (nu slutar jag lägga in tjej-brasklappar. Let's face it - det är bara grabbar i vår bransch). Säger inte mycket, men är alltid på jobbet. Kommer du in 7:22 så sitter Pularen där. När du går 17:56 så är Pularen där på sin plats och kommer så vara flera timmar till. Låt oss bara konstatera att det är Pularen som vet bäst hur man larmar på. Pularen levererar ofta bra (men vem fan skulle inte göra det om man jobbade 12 timmar om dan). Baksidan är det sociala - det är uppenbart nåt fel i huvet på Pularen, så det sociala samspelet med projektmedlemmarna blir lidande.

The Tech Guy - ultra-kompetent, ultra-insnöad. The Tech Guy har inget behov av sociala färdigheter. Root-login på samtliga miljöer smäller högre. The Tech Guy förstår inte att du inte har full kompetens på hans område. Det går aldrig upp för honom att du har andra prioriteter (typ bygga färdigt systemet). Att hantera The Tech Guy innebär att hålla honom nöjd (kom ihåg att han är ultra-kompetent ).

The Slow Poke - killen som inte tar för sig (om det inte gäller mormors-hosta-längd på 3-fikat). Ofta kompetent. Det som produceras håller bra kvalitet. Men det produceras inte mycket. Den ledande principen är att varje producerad kodrad kan betyda problem. Den rimligaste slutsatsen för The Slow Poke är att inte producera nån kod. Att hantera The Slow Poke är svårt. Regelrätt konfrontation kanske kan funka. Men sen kommer säkert facket och klagar på att arbetsgivaren vill att de anställda faktiskt ska jobba effektivt under arbetstid

Det är sent nu, så jag får fortsätta en annan dag...

Är du crappy?

En ganska bra uppradning varningstecken på att du kanske är en crappy programmer:
http://damienkatz.net/2006/05/signs_youre_a_c.html

Complexity Killed the Cat

Att utveckla system är en komplex verksamhet. Det ska fungera tekniskt, kommersiellt och användarna ska vara glada. Inte så att det krävs övermänniskor för att genomföra projekt, mer så att varje nytt projekt är så olikt det förra - det finns sällan ett facit.

Det känns som om risken att nåt ska gå snett och få ett projekt att gå i stöpet är så mycket större än möjligheten att det ska gå bra att det är helt magiskt att folk satsar pengar på systemutvecklingsprojekt. Det vittnar verkligen om människans obotliga optimism (och ofta också downright stupidity).

Nu menar jag inte att det är bara det tekniska som kan fallera. Riskerna är minst lika stora på business-planet.

Lek med tanken att alla de tiotals miljarder som brändes under IT-bubblan istället investerats i kort som vi alla vet är säkra (porr-, sprit- och vapenindustrierna), så hade de varit hundratals miljarder idag (jag förbehåller mig rätten att bortse från alla etiska implikationer ;).

Det finns såklart andra verksamheter som är så komplexa att det svindlar. Tänk t ex på det otroliga faktum att vi får en färsk nytryckt DN/SvD eller whatever i brevlådan varje dag. Ett journalistiskt (nåja inte alltid), tekniskt och logistiskt Labero-trick varje dag.

Skillnaden är att de utför samma trick varje dag. De har kunnat finslipa sitt projekt under årtionden och kan genomföra det med precision just för att det är same-old same-old varje dag.

Vi har sällan den lyxen.

Problemet är att själva kaoskomponenten i ett systems livscykel - från idé till fungerande system (eller kod i malpåse) - gör att det inte med framgång går att ta fram ett recept för hur man skall göra. Tumregler är det bästa vi kan hoppas på.

Och denna ovisshet går att slå mynt av. Det dyker oavbrutet upp folk som menar att de har svaret på alla frågor. Lösningen på alla problem. The silver bullet to rule them all...

Min tro är att tumregler är all we can hope for.

Det finns inte:

• ett språk/miljö som löser alla problem
• en metodik (vattenfall, scrum, xp, rup...) som passar alla utvecklingsprojekverktygsstöd
• verktygsstöd (oavsett hur mycket man betalar) som gör projektet till en walk-in-the-park
  

En rimlig fråga är kanske 'Ge mig tumreglerna du jiddrar om, mannen?'.

Där kan jag inte ge nåt svar (jag vill ju inte vara killen med silverkulan)...

Det enda jag hoppas är att lite av min luttrade cyniska attityd kan smitta av sig lite lagom på alla entusiastiska oerfarna systemutvecklare out there.

Tänk efter innan ni hakar på the-most-recent-best-thing-since-sliced-bread, så slipper ni göra samma misstag som jag gjorde i min ungdom...

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...