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...
Tuesday, January 29, 2008
Friday, January 25, 2008
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...
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...
Sunday, January 20, 2008
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...
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...
Saturday, January 19, 2008
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.
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.
Friday, January 18, 2008
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...
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...
Saturday, January 12, 2008
Ä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
http://damienkatz.net/2006/05/signs_youre_a_c.html
Friday, January 11, 2008
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:
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...
Friday, January 4, 2008
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:
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:
- Systemet genererar inga problem som trillar ner så långt att jag behöver göra nåt
- Systemet har användare
- Systemet har glada användare
- 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...
Subscribe to:
Posts (Atom)