This posting is part of the partners@work series.

It is better to have someone else promote you than promoting yourself! When you have partners, they can talk about you, promote you and tell everyone how great you are. Visa versa, you can do the same for your partners. Telling others about your partners will also increase the level of trust that people have in you. Partner logos are a great way of filling PowerPoint presentations and having a long list of partners available on your website docs wonders to your image.

That you are associated with your partner is a good thing. That is, if your partner is well regarded of course. If you doubt your partner’s reputation, it is wise to deny or revoke the partnership, although this may come across as being blunt. Be careful with whom you choose to partner.

Apart from name dropping, partnership are extremely helpful when organizing events & seminars, developing white papers or when exhibiting on a trade show. Often it is possible to work more cost effective and get more exposure by for instance sharing mailing lists.

When attending an event, your offering must be tailored to the attendees. You need to exhibit what your product can do for that specific target audience. This means you have to tailor your pitch or perhaps customize your product. This is where your partners come in. They have the required in-depth domain
knowledge that you may lack. Ideas for target specific markets and audiences may come from your peers in the marketing department or from your partners themselves.

When organizing a marketing initiative, it is advisable to let one party be responsible for planning and operations. This prevents the foreseeable communication problems and evenly plausible sliding deadlines. Create a formal project a have senior management commit to it. The advice has been given on many occasions, but is truer than ever in this case. Working across the boards on a project that does not immediately generate revenue requires an
elevated level of commitment and steering.

Wie tien jaar geleden investeerde in desktop-software werd voor gek verklaard. Alles moest online. In de browser. De pendule van de software-industrie is tegenwoordig weer terug. Desktop is hot, of beter gezegd: Apps op een smartphone zijn hot. Het lijkt wel of iedereen een iPhone-App wil, en ook één voor Android natuurlijk. Maar heeft een smartphone dan geen browser? Ja! En kun je met die browser niet hetzelfde als met een App? Misschien! Ik zie vier voordelen van een App boven een internetapplicatie.

Icoon op desktop          

Apps worden geïnstalleerd op de telefoon en hebben een icoon waar de telefoonbezitter regelmatig mee geconfronteerd wordt. Dit is pure reclame voor de App. Reclame die met een internetapplicatie niet kan worden gemaakt. Daar kun je het internetadres van een website hooguit in de bookmarks plaatsen. Dikke plus voor Apps hier.

Niet opnieuw inloggen

Apps kunnen onthouden wie je bent. Hierdoor hoeft de gebruiker niet telkens opnieuw in te loggen. In combinatie met het eerstgenoemde voordeel wordt de plus heel groot. Stel je voor dat je iedere keer dat je een App gebruikt opnieuw je e-mailadres en wachtwoord moet intypen. Dat ben je snel beu.

Local storage

Apps kunnen gebruik maken van de harde schijf van de smartphone. Internetapplicaties kunnen dit niet. Dit betekent dat Apps informatie kunnen onthouden en informatie niet telkens opnieuw hoeven op te vragen via het internet. Dit maakt Apps sneller en zorgt er bovendien voor dat er minder gedownload hoeft te worden wat scheelt in het dataverkeer, en dus lagere kosten voor de hosting.

User experience

Apps maken gebruik van mooiere controls dan internetapplicaties. Daarom zien Apps er beter uit, en voelen ze beter aan. Ze lijken robuster, ook al bieden ze dezelfde functionaliteit. Soms kun je met Apps dingen die internetapplicaties (lees: websites) gewoon überhaupt niet kunnen. De camera-functie is daar een goed voorbeeld van.

De gemakkelijke toegankelijkheid, het niet hoeven in te loggen, de snelheid en vloeiende user interface bieden veel voordelen. Dat gezegd hebben zal een App in de achtergrond altijd communiceren met een internetapplicatie. In mijn ogen is de App een mooi toevoeging, maar zeker geen vervanging.

Bij Octavalent houden we netjes bij welke bugs wij ontdekken en onze klanten melden. In sommige weken zijn het er veel, andere weken zijn het er heel weinig. Maar er zijn helaas altijd wel een paar onvolkomenheden in onze software. Het drama is niet zo groot: de meeste bugs zijn binnen korte tijd en zonder al te veel moeite opgelost. En (maatwerk) software is nooit bug-vrij. Desondanks zijn fouten vervelend, vooral als eindgebruikers er mee geconfronteerd worden en daardoor hun werk niet kunnen doen.

Om het aantal bugs te verlagen heb ik gekeken naar de oorzaken. Ik kwam tot de volgende vijf oer-redenen (in willekeurige volgorde):

• Slordigheid
• Componenten van derden
• Onvolledig functioneel ontwerp
• Incorrecte technische oplossing
• Architectuur

Slordigheid

Bij bugs is er een natuurlijke neiging om de programmeur te beschuldigen. En dat klopt natuurlijk. Als je iemand de schuld zou moeten geven, dan is het degene die de software gemaakt heeft. Dit is tegelijkertijd er kort door de bocht. Software schrijven is mensenwerk, en waar mensen werken, worden fouten gemaakt. Waar gehakt wordt, vallen spaanders. Het resultaat van een individu is de resultante van zichzelf en zijn omgeving. En het blijkt dat slechts een heel klein gedeelte van de bugs toegewezen kan worden aan slordigheid, domheid of andersoortige onhandigheid van de programmeur. Althans bij ons in het bedrijf. De discipline om goed op te letten waar je mee bezig bent is hoog. En dat moeten we zo houden.

Componenten van derden

We gebruiken regelmatig componenten van derden. Voorbeelden hiervan zijn: een component om PDF-documenten te genereren, een tekstverwerker in de webbrowser, en ook de webbrowser zelf (zoals Internet Explorer of Firefox). Het blijkt dat deze componenten niet altijd foutloos zijn, waardoor onze software onderuit gaat. Dit is geen excuus. Wij kiezen de componenten en dienen goed te testen. Desondanks is het wel een oorzaak. En tegelijkertijd mogen wij er in bepaalde mate vanuit gaan dat een veelgebruikte webbrowser als Internet Explorer backwards compatible is (dat wil zeggen: wat werkt in versie 8, werkt nog steeds in versie 9). De werkelijkheid is echter anders.

Onvolledig functioneel ontwerp

Voor de ontwikkelaar aan de slag gaat wordt een functioneel ontwerp gemaakt. In dit ontwerp staat precies beschreven hoe de te ontwikkelen software moet gaan werken. Vooral bij aanpassingen aan bestaande software treden problemen op. Een voorbeeld ter illustratie. In onze software wordt na een gebruikersactie (zoals het opslaan van een product) een tekst getoond met feedback (zoals “Product ‘ABC’ is opgeslagen.”) Er waren problemen met de manier waarop deze feedback getoond wordt, dat moest anders. Anders schrijf ik expres cursief, omdat het niet duidelijk was hoe het anders moest. Dit was aan de ontwikkelaar. De ontwikkelaar in kwestie gaat hiermee aan de slag en komt met een heel mooie oplossing. Iedereen tevreden. Tot blijkt dat de feedback-teksten op bepaalde plaatsen in de software net iets anders werken dan standaard gebruikelijk is. Nu valt lang te steggelen over de vraag of dit een fout van de ontwikkelaar was, of van de ontwerper. Feit blijft dat het goed was.

Incorrecte technische oplossing

Soms wordt een technische oplossing gekozen, waarvan we zeggen: dat hadden we beter niet zo kunnen doen. Deze conclusie valt uiteen in twee varianten: a) it seemed like a good idea at the time, en b) we wisten het van te voren. De eerste variant is voor iedereen met een technisch beroep herkenbaar (toch?) En ook niet technici kunnen zich een voorstelling maken van een foutief gekozen oplossingsrichting. We weten veel, maar niet alles. We hebben geen glazen bol. En soms kiezen we een oplossing die later niet blijkt te werken. Het is erger als we van tevoren wel hadden kunnen weten dat het technisch ontwerp niet klopt. Redenen hiervoor zijn een niet eenduidige architectuur. Er zijn meerdere oplossing voor het zelfde probleem, waardoor een ontwikkelaar sneller geneigd is een geheel eigen oplossing te bedenken, die hoe briljant ook, kinderziektes heeft. Communicatie vormt hierbij een belangrijke sleutel.

Architectuur

Ieder ontworpen systeem van een bepaalde omvang heeft een architectuur. Of het nu gaat om een wolkenkrabber of een stuk software. Iemand heeft nagedacht over de vraag welke materialen gebruikt worden en hoe de verschillende structurele componenten aan elkaar vast zitten. Een winkelcentrum bouw je niet met los zand, en software hangt ook niet met elastiekjes aan elkaar. Of soms toch wel? Architectuur-bugs zijn bugs waarbij er ergens iets veranderd wordt, en daardoor ergens anders iets niet meer werkt. Een verandering in één deel van de software leidt tot problemen in een ogenschijnlijk volledig ongerelateerd ander deel. Dit soort problemen zijn onlosmakelijk verbonden met het ontwikkelen van software. Ik speel het ontwikkel-spel al enkele decennia en heb niet anders meegemaakt. Ik schaar deze bugs onder het kopje architectuur, omdat een goede architectuur kan helpen dit soort bugs te voorkomen. Bijvoorbeeld door software op te splitsen in overzichtelijk componenten. Delen die klein genoeg zijn zodat de ontwikkelaar een volledig overzicht heeft op het geheel, en niet verzuipt in meer dan 100k regels code.

Gemiddeld gezien lopen software-projecten uit, staan ontwikkelaars onder druk en raken projectleiders gestresst. Deze optelling is niet goed voor de mensen, niet goed voor de kwaliteit en uiteindelijk niet goed voor de portomonee. Een aantal slimme koppen kwamen bij elkaar en schreef in het Agile manifesto dat de software-productie een ‘sustainable pace’ dient te hebben. Het tempo binnen een project moet vol te houden zijn. Makkelijk gezegd, maar hoe kom je tot zo’n houdbaar tempo? Vorige week hebben we binnen Octavalent opnieuw al het geplande werk afgekregen. Wat betekent dat en hoe doen we dat?

Iedere maandagochtend houden we de zogenaamde weekopening. In deze vergadering, waarbij iedereen aanwezig is, bespreken we de voorgaande week en plannen we het werk voor de komende week. Dit geplande werk is niet zo maar een gedachte, maar zien we als een commitment. Hoe gaat dit plannen in zijn werk?

Een software-project hakken we op in zo klein mogelijk stukken: de stories. Uiteindelijk bestaat een groot project daardoor uit enkele tientallen handzame stories. Iedere story kennen we een aantal punten toe. 1 punt betekent dat het niet veel werk is, niet complex is, en niet veel risico behelst. 2 punten betekent letterlijk 2 keer zoveel als 1, en 8 punten betekent dus 4 keer zoveel als 2 punten. Door punten te gebruiken in plaats van uren (en dit te schatten middels planningpoker) blijkt het aantal punten redelijke goed te kloppen.

Door stories in te plannen in een week, kun je de punten bij elkaar optellen en zo komen tot een totaal aantal punten voor die week. Achteraf kun je tellen hoeveel punten je daadwerkelijk gedaan hebt. Door dit een lange periode vol te houden (en hier zit de crux), bouwden we ervaringsstatistieken op. Zo weten we dat we gemiddeld 9 punten per FTE kunnen doen. Nu wordt het al gemakkelijker.

Tel op maandag de beschikbaarheid van de ontwikkelaars (in FTE), vermenigvuldig dit met 9 en dan hebben we het aantal punten dat we de komende week inplannen. Aangezien de stories punten kregen vóór het maken van deze rekensom, is het daarná slechts een kwestie van bepalen welke stories in de komende week op het planbord komen.

So far, so good. Maar we zijn er niet. Niets garandeerd dat de week niet overhoop wordt gehaald door haastklussen, bugmeldingen en tegenvallers. Haastklussen zijn heel simpel. Dat kan altijd, maar moet geruild worden met eerder ingepland werk. Dit is het principe van: “Je wilt dat XYZ in de planning komt? Wat gaat er dan uit de planning?”.

Bugmeldingen zijn lastiger. Een plotselinge test-woede van een collega of klant kan een stortvloed van kleine verbeterpunten opleveren. Alles is even belangrijk, maar het is de vraag of het nu moet. Bugs die geen showstoppers zijn, stellen we zonder pardon uit tot de volgende week. Blijkt op die maandag dat er veel bugs opgelost moeten worden, dan stellen we de productiviteits-schatting navenant bij van 9 naar 8 (of 7 of 6). Zijn er weinig bugs, dan gaat de productiviteits-schatting naar 10, of wellicht 11. Door bugs niet direct op te pakken, maar in te plannen, creeëren we een hoop rust wat de kwaliteit ten goede komt.

Tot slot kan het werk altijd tegenvallen. Een 2-punter (statistische gezien 6 uur werk) kan 3 dagen in beslag nemen. Weg planning? Niet helemaal. We hebben nog een sluitpost. Die sluitpost heet ‘Verbeteringen’. Verbetering zijn werkzaamheden waarvan het ontwikkelteam vindt dat ze nodig zijn. Voorbeelden zijn: wijzigingen in de architectuur, het inzetten van een nieuw technologie of het upgraden van een component. Dit zijn werkzaamheden die niet onmiddelijk moeten gebeuren. Ze kunnen makkelijk worden uitgesteld naar de volgende week. En dat doen we dan ook.

Hier zit wel een valkuil. Door verbeteringen als sluitpost te hanteren, loop je het risico er nooit aan toe te komen. Wij hebben dit ondervangen door voor verbeteringen een budget te bepalen, en wel 10% van alle ontwikkeluren. Dit tellen we per kwartaal. Stel dat we na drie weken in het kwartaal slechts 5% hebben besteed aan verbeteringen, dan weten we dus dat we voor de volgende week een lagere productiviteit moeten aanhouden.

Bij Octavalent zijn we op zoek naar een nieuwe ontwikkelaar. Ik krijg daarom weer veel CV’s onder ogen. Sommigen zijn goed, anderen vallen tegen. Het CV van een software-ontwikkelaar is net iets anders dan een gemiddeld CV. Vooral het kopje opleiding en ervaring met bepaalde technologieën. Wat zoek ik precies in een CV?

Algemeen

Gebruik niet te veel tekst. Opsommingen zijn super. Ook de standaard opmaak van een leeg Microsoft Word document voldoet prima. Schrijf maximaal twee kantjes en motiveer in je e-mail waarom je juist voor deze functie, bij dit bedrijf solliciteert.

Personalia

Hier staat puur feitelijke informatie over wie je bent, hoe je te bereiken bent en waar ik op internet meer over je kan vinden. Toon: naam, geboortedatum, adres, telefoonnummer, email en eventuele websites (zoals linkedin, weblog, github- of stackoverflow-pagina). Wees niet de benauwd om een foto bij te voegen. Het gaat er om dat ik je kan herinneren en een foto helpt.

Opleiding

Beschrijf alle opleidingen, cursussen, en trainingen die je gedaan hebt. Let er wel op dat opleidingen minder relevant zijn dan vroeger. Kennis is vluchtiger, dus een training van vier jaar geleden voegt niet veel meer toe. Ook zijn er veel meer mogelijkheden om bij te blijven. Lees je actief weblogs? Luister je podcasts? Zet dit dan bij opleidingen. Bij opleidingen wil ik zien waar je je basiskennis vandaan hebt (HBO/WO), en hoe je op de hoogte blijft van nieuwe ontwikkelingen.

Ik ben altijd een beetje beducht op (oud-)medewerkers van een detacheringsbureau die in wel heel veel opleidingen hebben gedaan. Dit wijst er meestal op dat ze op de ‘bank’ zaten/zitten. Goede medewerkers zitten namelijk op een project en doen alleen certificerings-trajecten als het echt moet.

Werkervaring

Werkervaring is meer dan een lijst met bedrijven waar iemand werkte. Sterker, de bedrijven boeien mij niet zo. Ik ken ze toch niet. Ik ben meer geïnteresseerd in de projecten waar iemand aan werkte: voor welke klant, hoelang, in welke rol en met welke technologieën. Dat gezegd hebbende wil ik wel weten hoelang iemand gemiddeld bij een werkgever werkt. Toon dus werkgevers, en per werkgever de projecten.

Veel werkervaring is goed, veel verschillende ervaringen is minder goed. Ik zoek iemand die focus heeft op een bepaalde technologie en binnen die technologie weet waar hij het over heeft. Een jack-of-all-trades kan over veel meepraten, maar is nergens echt goed in. Dit heeft zo zijn waarde, maar ik zoek het niet. Toon in je werkervaring welke technologieën, frameworks, talen, en bibliotheken je gebruikt hebt. Of je aan veel of weinig projecten hebt gewerkt is niet zo relevant. Als er maar een lijn in zit.

Zeg niet te snel dat je een expert bent in taal XYZ. Toon het mij. Bijvoorbeeld door er een aantal jaren mee gewerkt te hebben. Iemand die na twee jaar claimt C# -expert te zijn is voor mij niet geloofwaardig, en ondermijnt zijn CV. In tegenstelling: wanneer iemand vier jaar ervaring heeft met C#, dan trek ik zelf wel de conclusie dat hij weet waar hij mee bezig is.

Overigen

Iedere medewerker brengt niet alleen zijn hoofd en handen in, maar ook iets extra’s. Dit extra’s is met name in een kleinere organisatie van belang. Dat je op voetbal zit is niet zo relevant, wel als je daar iets speciaals doet: bijvoorbeeld door in de feest-commissie te zitten of voetbaltraining te geven. Spreek je vloeiend een vreemde talen die handig kan zijn? Ben je BHV-er? Heb je gewerkt aan een open-source project? Help je ouderen met het wegwijs worden op de computer? Schrijf je een blog? Doe je vrijwilligerswerk? Schrijf het hier op.

Struinend in mijn (ongepubliceerd) archief kwam ik de specificaties tegen voor een spelletjeswebsite. Ik meen mij te herinneren dat ik deze ooit schreef voor een wedstrijd. Later bleek dat de wedstrijd bedoeld was voor studenten en dat de inschrijving al was gesloten. Zo raakten het idee in de vergetelheid tot ik de tekst zojuist weer tegen kwam. Ik las hem en vond het nog steeds een aardige vonst.

Hierbij het concept: De website biedt puzzels aan. Een puzzel is een raadsel waarbij de bezoeker aan de hand van een hint een locatie moet raden. Dit kan een locatie zijn overal ter wereld. De puzzelaar ziet op het scherm een wereldkaart en hij moet op de kaart de juiste locatie aanklikken. Klikt hij inderdaad juist, dan heeft hij de puzzel gewonnen. Iedere puzzelaar kan zelf puzzels maken. Een puzzel bestaat uit uit de eerder genoemde hint & locatie (latitude en longitude) en een radius. De locatie in combinatie met de radius vormt een cirkel op aarde.

Om de juiste locatie te kunnen raden heeft de puzzelaar twee hulpmiddelen. Allereerst is er de hint. Het tweede hulpmiddel is het commentaar van andere puzzelaars. Je speelt een puzzel namelijk nooit alleen, iedereen kan met dezelfde puzzel meespelen. Als puzzelaar kun je suggestie aan een puzzel toevoegen. Op deze manier speel je tegelijkertijd met elkaar, maar ook tegen elkaar. Suggesties van anderen helpen jou, maar jouw suggesties helpen anderen.

Bij een goed spel valt iets te winnen, zo ook hier: punten. Bij het geven van suggesties kan de bedenker van de puzzel jouw suggesties upvoten en downvoten. Upvoten levert je 10 punten op, downvoten kost je 2 punten. Het totaal aantal punten van de upvotes en downvotes bepaalt de waarde van een puzzel. Win je de puzzel dan krijg je de waarde van de puzzel toegevoegd aan jouw totaal. Hetzelfde geldt voor de bedenker van de puzzel, die krijgt ook dat aantal punten. Je kunt dus op drie manieren punten scoren: door goede suggesties te leveren, door een puzzel te winnen en door een puzzel te verzinnen.

“Patentterreur verjaagt app-makers uit ‘gevaarlijk’ VS” kopte een artikel op de technologie-website Webwereld. Het was een artikel waar ik al een tijdje op zat te wachten. En ik werd er niet blij van. Kun je als Nederlands (of Europees) technologiebedrijf met een software-product mondiaal succes hebben? Met de patentoorlog die gaande is wordt het in ieder geval niet gemakkelijker.

Nederlandse software-makers zijn altijd al huiverig geweest voor verkoop in Amerika. De angst voor torenhoge claims is groot. Geen idee of dit volledig terecht is, maar ik kan mij er iets bij voorstellen. Amerika heeft nu eenmaal de reputatie dat klanten (of zelfs wildvreemden) je voor de raarste dingen voor het gerecht slepen. Vroeger hoefde je praktisch alleen maar bang te zijn dat anderen schade opliepen bij gebruik van jouw producten. En als jouw product goed in elkaar zat, dan waren de risico’s beperkt. De patentoorlog heeft hier een nieuwe dimensie aan toegevoegd.

Software-ontwikkelaars zijn over het algemeen creatieve mensen die features bedenken waar je bij staat. Stop een stel software-savvy mensen in een hok en de ideeën stromen over. Tot de patent-oorlog uitbrak was het een kwestie van prioriteren en bouwen maar. Tegenwoordig moet je rekening houden met patenten. Stel dat je een goed idee hebt voor een nieuwe feature, dan is de kans groot dat jij niet de enige bent met dit ‘briljante’ idee. En als iemand in Amerika dat idee ook had en hij werkt bij een groot bedrijf, dan is de kans groot dat het idee gepatenteerd is.

Maar wat betekent een software-patent eigenlijk? Kort gezegd komt het er op neer dat als je gepatenteerde technologie in jouw software gebruikt, dat je moet betalen aan de patenthouder. Ook als je ten tijde van de software-ontwikkeling niet wist dat er een patent was. Tijdens het ontwikkelen van software kun je dus ongemerkt inbreuk maken op patenten van anderen. Aan het proces van software ontwikkelen is door de patent-oorlog een extra activiteit toegevoegd: onderzoek doen naar patenten en nieuwe patenten aanvragen.

Nu gelden de patenten strikt gezien alleen voor Amerika. In Nederland (en geheel Europa) is het niet mogelijk om patenten op software aan te vragen. Software wordt gezien als algoritmes, wiskundige formules dus. En uitvindingen in de wiskunde kun je in Europa niet patenteren. Is er dus wel een probleem?

De Amerikaanse markt wordt gevormd door de patentoorlog. Amerikaanse softwarebedrijven houden bij de ontwikkeling van software rekening met patenten. Ze gebruiken geen gepatenteerde ideeën of patenteren zelf defensief. Amerikaanse bedrijven groeien op in een ecosysteem waarin patenteren een normaal onderdeel van het leven is. Europese bedrijven komen tot wasdom in een ander model. Omdat zij nooit rekening hoefden te houden met patenten, maken zij ongemerkt inbreuk op allerlei Amerikaanse patenten. Dit is geen enkel probleem, totdat ze de Amerikaanse markt op gaan. Het ‘niet gewend zijn aan patenten’ is een barrière voor toegang tot de Amerikaanse markt.

Op zich is Europa voor een Nederlandse bedrijf groot genoeg. Er zijn groeimogelijkheden zat op ons continent. Er is echter een bepaald type markt waarbij Amerika een must is: de winnner-takes-all-markt. Dit is een markt waarbij één of twee grote spelers (uiteindelijk) domineren. Enkele voorbeelden zijn: zoekmachines (Google, Yahoo, MSN), en sociale netwerken (FaceBook, LinkedIn). In een markt waarbij Europeanen niet naar Amerika kunnen, maar Amerikanen wel naar ons, delven wij per definitie het onderspit.

Er is echter een positieve kant aan de patent-woede. Tegenstanders van (software)patenten claimen dat patenten innovatie in de weg staan. In een systeem van gesloten innovatie kun je niet bij elkaar in de keuken kijken en geen gebruik maken van uitvindingen en ideeën van anderen. Europese bedrijven zijn door de koers van open innovatie wellicht in het voordeel. Hoewel hier ook het principe geldt dat Amerikanen wel in onze keuken kunnen kijken, maar wij niet in die van hen.

We zullen het zien.

Recent kwam ik op de website van Project Euler. Dit is een website met diverse wiskundige programmeer-raadsels. Voor iemand met een interesse in software is dit een leuke puzzel-site, en weer eens iets anders dan Angry Birds. Voor iedere puzzel is het de bedoeling dat je een heel klein programmatje schrijft wat een oplossing vind voor een bepaald probleem. Voorbeeld: “What is the smallest number divisible by each of the numbers 1 to 20?” Echt voor nerds dus.

Project Euler houdt ook statistieken bij. De twee die ik interessant vond, waren: Number of Users en Average User Rating, per programmeertaal. Vooral de Average User Rating vond ik interessant. Ik ga er van uit dat deze rating aangeeft aan hoevaak een gegeven antwoord goed is.

Aan de hand van de Tiobe-index pakte ik de vijftien meest populaire programmeertalen en kwam zo tot de volgende staatjes.

Ik vind het grappig dat met name de bovenste drie en onderste twee zo herkenbaar zijn. Bovenin vinden we Haskell (academici), Delphi (veteranen) en Assembler (die-hards). Onderin staan de talen voor de scriptkiddies: JavaScript en PHP. De rating zegt op zich natuurlijk niet zo veel over de intelligentie of snelheid van de programmeur. Maar het is wel zo dat de oplossing van een top-tier-programmeur één op de tien keer goed is. Terwijl een PHP-neefje pas na 25 keer tot een goed resultaat komt.