Cloud As A Service

Vil du virkelig være noget i IT-verdenen lige nu, så skal du helst tilbyde alle dine service-ydelser som – nåja – “as a service”. Seneste skud på stammen er “Test as-a-service”.

Og så “Cloud”. Det er jo gået hen og blevet det nye XMl – løsningen på alle IT-problemer. Det er virkelig et godt eksempel på gammel vin på nye flasker.

Lyder jeg som en gammel bitter mand? Måske. Jeg vil snarere sige, at jeg udviser rettidig omhu, og ikke springer på hvert nyt lyntog.

Conversations with an oak tree

For en uge siden skrev jeg om bogen Samtaler med et træ. Nu har jeg så været heldig at blive en af test-læserne på den engelske udgave “Conversations with an oak tree”.

Bogen er ifølge hjemmesiden blevet skrevet op til en 2010 udgave (den er trods alt også 13 år gammel), og planen er, at den skal udgives på et amerikansk forlag. Jeg er så småt begyndt at læse den (den nyindkøbte danske udgave har jeg så i mellemtiden lånt ud på mit arbejde), og minderne fra den gang, jeg læste den for så mange år siden, vender tilbage.

Jeg er spændt på at komme videre med den og finde ud af, hvor meget der var nødvendigt at skrive om pga. 13 års teknologisk udvikling i vores samfund – faktisk har jeg på fornemmelsen, at det ikke er særlig meget. 🙂

Vil du outsource? De 3 vigtigste råd

Gennem mine 8 år som selvstændig, har jeg gjort en dyd ud af, at bruge eksterne eksperter. Både på de områder, hvor jeg ikke selv havde kompetencer, men også indenfor mine egne områder, hvis der var for meget at lave. I de sidste 3 år brugte jeg meget folk fra udlandet: Bulgarien, Ukraine og Indonesien. Det har både været godt, men jeg har også brændt fingrene.

Derfor giver jeg her de 3 vigtigste erfaringer, som jeg har gjort mig:

1. Ansæt dine programmører for en længere periode af gangen

Du skal ikke hyre teams for enkelte projekter (f.eks. programmering af en hjemmeside). Alt for ofte vil du opleve ændringer i projektets krav undervejs, og så kan du nemt komme til at stå i en klemme. Leverandørerne kan desværre vise sig meget ufleksible med at afvige fra det aftalte.

Det er meget bedre at ansætte en eller flere programmører, som du så har fuld råderet over. Tro mig – du vil altid have noget, som de kan lave… 🙂 På den måde er du ikke nær så sårbar overfor ændringer i projekter.

2. Sørg altid for at du også får kildemateriale

Uanset om du får produceret en flashfilm, et design eller et program, så skal du udover det færdige produkt også få en kopi af kildematerialet. Også selvom du ikke selv har viden til at bruge den. Hvis du ikke gør, så har du bundet dig til leverandøren.

Jeg har oplevet, at en leverandør skulle lave nogle vigtige ændringer i en flash film 1½ måned efter at projektet var færdigt. Men de havde pludselig ikke længere tid, fordi de havde fået nogle store opgaver ind fra andre (vigtigere) kunder. Jeg kunne derfor vælge at vente 2 måneder eller få lavet flash-filmen helt forfra et andet sted. Ikke så fedt…

3. Outsourcing er ikke så effektivt som “lokalt ansatte”

Du skal regne med langt mere overhead og projektadministration, end hvis du havde dine folk ansat i samme kontor som du sidder i. Dels er det sværere at kommunikere på engelsk – ikke mindst fordi, at leverandørerne ikke altid er super-gode til engelsk. Men simpelthen også fordi man mangler muligheden for at stå samlet om en white-board tavle og “tegne-fortælle”. Der findes mange gode kommunikationsværktøjer på nettet, men det bliver bare aldrig helt det samme.

Tommelfingerregel: Et projektteam i udlandet har en effektivitet på ca. 50% af et, der sidder sammen med dig. Vær forberedt på, at ting skal forklares igen og igen og med mange eksempler, før det er helt forstået. Forvent, at ting skal kodes om 2-3 gange, inden den sidder i skabet.

Vær opmærksom på, at du kommer til at bruge meget tid på at koordinere projekterne. Du får derfor ikke noget reelt udbytte af kun at hyre en programmør.

Det lyder besværligt – skal jeg helt lade være?

Det er svært at svare entydigt på. Du skal i hvert fald ikke lade dig lokke bare af en billig pris. Til gipote.dk hyrede vi en Rails programmør i Indonesien for 3 måneder af gangen. Vi havde nogle helt konkrete opgaver til ham. Dem løste han også rimelig godt, men til gengæld brugte jeg en del tid på at sætte ham ind i opgaverne og kontrollere dem bagefter. Dermed blev min egen produktivitet sænket. Det var først, da vi ansatte endnu en programmør, at det virkelig gav noget. Vi brugte et firma, der hedder Kiranatama til Rails udvikling – dem kan jeg bestemt anbefale og jeg ville selv bruge dem igen

Og så lige en sidste ting: Hvis du selv er et en-mands firma, så har du nok ligesom jeg en stærk holdning til, hvordan tingene skal gøres – “my way or the highway”. Det skal du lære dig selv at lægge på hylden. For det kode, du får hjem, ligner med garanti ikke noget, som du selv ville lave. Men det kan du nok også lære noget af – det gjorde jeg. 🙂

What to learn next?

I’ve always had principle to learn at least one new technology/programming language/framework every year. So far it has, among the most interesting, amounted to: C and C++, Pascal, Delphi, Foxpro, MySQL (and developing on the MyODBC driver), Informix, Oracle, MSSQL, ASP, PHP, Perl, Python, Zope/Plone, Typo3, Drupal, OO Patterns, SCRUM project methods, Ruby on Rails, Prototype, … I’ve probably missed some.

This doesn’t mean, that I still use all of the above – simply that I always strive to learn something new, evaluate it, and maybe continue to use it.

I am in no way finished with Ruby on Rails – especially since this has become basis for my new full-time job. But I would really feel like stalling, if I don’t try something new.

So what do I really need to look at next? We are coming to the end of 2008 – what does 2009 have to offer my curiosity?