Moi je sais ! Et vous ?
Si vous savez, passez par la case départ, prenez vos 20.000 Francs (ou 200 euros) et revenez la semaine prochaine

Donc, pour ceux qui ne savent pas, je vous conseille vivement la lecture de Programming Collective Intelligence. Ce livre explore et vous explique en profondeur quelques-uns des algorithmes les plus utilisés dans les site Web 2.0.

Vous trouverez donc dans ce livre un chapitre intitulé Making Recommandations qui vous explique comment les meilleurs sites Web 2.0 arrivent à savoir, en fonction de ce que vous leur avez dit que vous aimiez, ce qui pourrait vous plaire. Grâce aux algorithmes expliqués, vous comprendrez mieux comment Amazon vous recommande des articles, ou ce qui fait le succès de sites comme last.fm ou iLike.com.

Ce livre traite également des moteurs de recherche dans le chapitre Searching and Ranking. L’algorithme PageRank, sur lequel Google a bâti son empire, y est expliqué en détail. J’ai également appris dans ce chapitre comment utiliser des réseaux neuronaux pour améliorer les résultats d’une recherche en fonction des liens qui sont cliqués par les utilisateurs.

Un autre sujet qui m’a passionné dans ce livre concerne le filtrage de document. L’auteur détaille plusieurs algorithmes de classification, notamment le très célèbre fitrage bayésien qui sert à déterminer si un email est un spam ou pas.

Enfin, un autre chapitre qui m’a beaucoup intéressé, c’est celui traitant des modèles de prix. Ce chapitre explique comment déterminer le prix d’un article en fonction de ses caractéristiques quand on connait le prix d’autres articles. A la fin du chapitre, on utilise l’API de eBay pour connaitre le prix final d’enchères concernant des ordinateurs portables et pour prévoir le juste prix d’enchères en cours. En jouant avec le programme, je me suis ainsi rendu compte que les variables les plus importante sont la taille de l’écran du portable et… la date de fin d’enchère !

Bref ce livre est vraiment génial. L’auteur utilise tout au long du livre la même technique pédagogique qui permet de bien comprendre chaque sujet abordé:

• D’abord fixer un objectif (par exemple, connaitre la liste des films qui sont susceptible de me plaire)
• Ensuite décrire et expliquer l’algorithme qui permet d’atteindre cet objectif
• Enfin la réalisation d’un petit programme en Python illustrant le concept et permettant de jouer sur les différents paramètres de l’algorithme étudié. Si vous ne connaissez pas Python, c’est une bonne occasion pour s’y mettre !

En conclusion, si vous œuvrez dans le monde du Web 2.0, ou si vous êtes juste curieux de nature, procurez-vous ce livre d’urgence.

La nouvelle version du site est esthétiquement plus léchée. Par contre, c’est une catastrophe au niveau de l’ergonomie. C’est clair, maintenant à chaque fois que je me connecte sur le site de ma banque, je peste. Je peste contre l’ergonomie de ce foutu site qui me fait cliquer pour m’afficher des pages que je ne veux pas voir.

Des explications s’imposent. Commençons par la page qui s’affichent une fois que l’on a passé la page de login.

Mon Espace

Cette page ne m’intéresse pas !

Elle comporte 3 grandes zones de contenu. La première zone intitulée Vous et votre agence m’indique le nom de mon conseiller financier et le nom de mon agence. Vous trouvez vraiment que c’est une information super capitale ? Personnellement, mon agence je la connais. C’est là que j’ai ouvert mon compte ! Idem pour mon conseiller financier. A la rigueur, la seule information intéressante de cette première zone est la date de ma dernière connexion, pour me permettre de savoir si quelqu’un a piraté mon compte.

La seconde zone intitulée Vos coordonnées est encore plus dénuée d’intérêt. Elle m’affiche mon numéro de téléphone et mon adresse email. Il faudra que je m’en souvienne… Si un jour j’oublie mon numéro de téléphone ou mon adresse email, je sais maintenant où je peux les récupérer !

Et on termine avec la troisième et la pire zone, sobrement intitulée Actualités, mais qui n’a jamais affiché autre chose que de la publicité.

Bref, la page d’accueil au lieu de contenir les informations qui m’intéresse, comme le solde de mes comptes, m’affiche des trucs complètement inintéressants. Ce portail me permet tout de même d’aller sur l’onglet Mes Comptes qui affiche ce qui m’intéresse.

Mes Comptes

Cette page m’interesse, mais elle m’énerve au plus haut point !

Elle liste dans un tableau tous mes comptes bancaires. Le tableau comporte:

• une colonne non cliquable avec le numéro du compte
• une colonne non cliquable avec le type du compte
• une colonne cliquable intitulée Intitulé personalisable
• une colonne cliquable avec le solde du compte (ici 999 999,99 euros)

Non je n’ai pas gagné au loto ! J’ai juste retouché l’image

Mais revenons à nos moutons. A chaque fois que je visite ce site, je clique sur le lien Compte Principal espérant arriver sur la page listant les opérations que j’ai effectuées sur mon compte. Et invariablement, j’arrive sur la page suivante:

D’où ma frustration… à chaque fois j’arrive sur la page qui me permet de changer l’intitulé de mon compte. Pourtant je le sais… mais à chaque fois, je fais l’erreur. En fait, il faut cliquer sur le solde du compte pour avoir le détail des opérations. C’est pas anti-intuitif ça ? C’est pas anti-ergonomique ?

Si on réfléchit 5 minutes, il est évident que tout le monde doit faire la même erreur que moi. Nous sommes dans la page de gestion des comptes, on nous présente un lien qui porte le nom du compte que l’on veut voir… alors forcement on clique dessus !

A mon avis, la meilleure solution pour cette page est de laisser la colonne Intitulé personalisable mais de la rendre non cliquable, ou alors de la laisser cliquable mais avec le même lien que la colonne Solde, puis d’ajouter un lien Personnaliser les intitulé de vos comptes en dessous du tableau, pour personnaliser tous les intitulé d’un coup.

Et selon vous, comment cette page devrait-elle être conçue ?

Voici donc un petit billet juste pour vous dire qu’actuellement, je passe du bon temps en jouant aux échecs grâce à Flex, Java et ChessCube.

Pour passez un bon moment la recette est donc la suivante:

• Prenez un jeu ancestral qui a fait ses preuves (les échecs)
• Ajoutez-y un peu de Flex et de Java
• Mélangez le tout
• Arrosez le tout d’un peu de Web 2.0 avec de la gestion d’amis

Et pour ceux qui n’aiment pas les échecs, je vous propose une recette équivalente à base de Tetris. Le site s’appelle I’m in like with you et permet de jouer à plusieurs petits jeux dont Blockles, un Tetris-like aussi bon que celui de la GameBoy.

Attention, c’est démoniaque et ne vous fera pas Gagner en efficacité. Au contraire… votre productivité risque de chuter sérieusement ! Je vous aurais prévenu.

Ce genre de bouquin, c’est le fondement de la société américaine, c’est le rêve Américain à porté de main, c’est ce que l’Amérique sait faire de mieux. Bref le pays de l’oncle Sam regorgent de bouquins de ce genre. En voici quelques exemples pêchés sur Amazon.com

• Think Like a Billionaire, Become a Billionaire (Pensez comme un milliardaire, devenez un milliardaire)
• Think BIG and Kick Ass in Business and Life (que l’on pourrait traduire par “Pensez GRAND et déchirez au boulot et dans la vie”)
• How to Get Rich (Comment devenir riche)
• How to Win Friends & Influence People (Comment se faire des amis et influencer les gens)
• Maximum Achievement: Strategies and Skills That Will Unlock Your Hidden Powers to Succeed
• Et cetera, et cetera

Bref, ce genre de livre est une spécialité du pays de l’ongle Sam, mais celui-ci semble avoir été écrit par un français: le Dr Patrick M. Georges. C’est un neurochirurgien, également un professeur de management, ou alors l’inverse !

Ce livre se lit très facilement. La première partie dresse une bonne liste de conseils réparties en plusieurs chapitre. Comme l’auteur l’explique dans son ouvrage, tous les conseils ne s’appliquent pas à tout le monde, mais ils semblent tous pertinents. La seconde partie est une serie de situations où il faut retrouver et appliquer les conseils de la première partie. Bref, cette seconde partie n’apporte rien, de même que la troisième qui n’est qu’un résumé des conseils énumérés lors de la première partie.

Mais revenons aux conseils de la première partie. J’en connais et j’en respecte déjà certains (waouh, trop fort le gars). Voici donc les conseils que j’applique déjà à la lettre.

Buvez moins d’alcool

Bon d’accord celle-ci est facile. Mais bon c’est pas de ma faute si je préfère un Orangina bien frais à un Chateau Margaux. Je sais je fais honte à tous les vignerons français.

Protegez-vous des voix ! Elles perturbent fortement votre intelligence.

Je suis 100% d’accord avec ce conseil et l’appliquer n’est pas un mince affaire. Je milite pour ne pas travailler dans un open-space mais je travaille malgré tout dans un bureau de 6 personnes. Aussi, lorsque je veux m’isoler pour travailler, je mets mon casque de walkman (même sans musique parfois).

Un visage humain dans votre champ visuel et votre intelligence est perturbée

Idem que ci-dessus, ne pas travailler dans un open-space me permet d’éviter les distractions des gens qui passent. Et j’ai investi dans un grand écran 24″ pour ne pas voir la personne qui est en face de moi (et accessoirement pour avoir plus de pixels pour travailler).

Le livre contient également un grand nombre de conseils auxquels J’adhère complètement et que je compte mettre en pratique à partir de la rentrée. Je ne sais pas si j’arriverais à tous les appliquer, mais je compte m’y employer. Ces bons conseils sont les suivants

Organisez une pause privée par jour

Je sais que je ne prends pas assez de temps pour réfléchir dans la journée. J’agis beaucoup, je ré-agis (aux mails, aux sollicitations, etc), mais je ne réfléchis pas assez. Je vais essayer de m’aménager une pause d’une demi-heure dans ma journée de travail “coupé” du monde pour réfléchir. Bill Gates avait sa Think Week, je vais essayer d’avoir ma demi-heure de réflexion.

Ne commencez pas votre journée par la lecture de votre courrier. Vos objectifs ont priorité sur ceux des autres.

Là j’ai tout faux car je fais ça tous les matins depuis 3 ans. C’est mon rituel, je réponds à mes mails le matin avant de commencer le travail. Comme, je fais ça le plus souvent au calme chez moi, Je sais que je pourrais consacrer ce temps où ma concentration est maximale à faire des travaux nécessitant de la concentration.

Je vais repousser la lecture de mes mails à la fin de la matinée. La demi-heure juste avant le repas étant régulièrement propices à dérangements (collègues qui reviennent de réunions, faim qui commence à se faire sentir, etc.)

Donnez à votre équipe un objectif mesurable toutes les semaines.

Le stress et la démotivation prennent racine dans l’incertitude. J’ai suffisamment participé à des projets sans roadmap pour avoir intégré cette notion. Je vais donc essayer de ne pas connaitre cette erreur et toujours fixer un objectif mesurable pour la semaine suivante.
Ce conseil est facile à dire mais pas évident à tenir à mon avis ! Rendez-vous dans 3 mois pour un premier debriefing.

Il y a encore plein d’autres conseils que je pourrais mettre en pratique mais je ne voudrais pas spolier l’auteur de son travail, ni me fixer des objectifs trop ambitieux.
En conclusion, je vous conseille donc vivement ce livre qui se lit d’un trait, mais qu’il faudra conserver comme livre de chevet et relire régulièrement pour être sur de bien appliquer les quelques conseils que vous pensez important.

Je pense vraiment que chacun peut s’améliorer en appliquant quelques uns des conseils présents dans ce livre.

Ne laissez pas sortir le cochon qui est en vous

Même avec les plus belles intentions du monde, il est rare de tenir ses bonnes résolutions plus longtemps que quelques semaines. Aussi, même si vous avez décidé d’être un peu plus perfectionniste à l’avenir, vous n’êtes pas a l’abri d’un moment de faiblesse. Moment de faiblesse qui vous amènerait a écrire du code de cochon: pas relu, bourré de bugs, mal indenté, …

Pour vous mettre a l’abri de ce genre de relâchement, ne prenez qu’une seule bonne habitude:
Faire relire votre code par une personne autre que vous.

Lorsque vous estimez avoir terminé une tache ou une fonctionnalité, présentez vos travaux à une personne pour qu’elle prenne le temps avec vous de les relire. Cette personne peut être un collègue plus expérimenté ou moins expérimenté que vous, une personne travaillant sur un autre projet, peu importe.

Cette validation a plusieurs bénéfices:

• Pendant que vous développez, elle agit comme une épée de Damoclès, pour vous empêcher de laisser sortir le cochon qui sommeille en chaque développeur
• Après le développement, elle permet de trouver des bugs ou des situations auxquels vous n’aviez pas pensé.
• Elle permet aux autres personnes de savoir ce que vous avez développé et permet l’échange entre développeurs

Je vous conseille également, lorsque vous sentez que vous avez cerné comment implémenter la fonctionnalité ou la tache que l’on vous demande (après la phase “casser la faisabilité”), d’aller voir un de vos collègues et de lui exposer votre manière de résoudre le problème. Cela permet parfois de mettre en lumière des problèmes dans la solution originale, et cela permet souvent de trouver une solution meilleure que celle initialement envisagée.

Cherchez a progresser

C’est bête a dire, mais je connais beaucoup de développeurs qui cherchent “juste” a faire leur travail du mieux qu’ils peuvent. C’est une stratégie qui marche bien à court-terme. Néanmoins, ils ne progresseront que de leurs erreurs, c’est à dire pas beaucoup.
Si vous voulez vraiment progresser en tant que développeur, je vous encourage vivement à lire des livres sur votre temps libre.
Il existe quelques classiques que tout développeur doit avoir lu.

Je vous encourage, par exemple a aller voir la liste que conseillait Jeff Atwood en 2004 sur son blog, ou la liste de ses 5 livres indispensables. Le blog de Joël Spolsky passe également en revue des livres recommandés.

Lisez également des journaux, magazines, ou autres blogs qui vous permettrons de mieux appréhender le développement en général.
Lire régulièrement vous permettra de faire évoluer vos connaissance car l’industrie informatique évolue très vite. Une bonne partie vos connaissances actuelles sera démodé dans 5 ans et complètement obsolète dans 10 ans.

Répétez vos gammes

En fait, c’est un peu faux. Il y a certaines choses qui ne seront pas forcement obsolètes dans 10 ans. Je pense aux bases de l’informatique: ce qu’on apprend dans les cursus informatiques.

Voici quelques notions que je considère importante pour faire un bon boulot de développeur:

• A quoi sert, comment fonctionne, et comment est implémenté: un tableau, une liste chaînée, une pile, une queue et une table de hachage
• A quoi sert et comment fonctionne un ramasse-miettes
• A quoi sert et comment fonctionne un thread; comment partager des ressources entre plusieurs threads (sémaphores, mutex, lock, …)
• Comment marche les réseaux et Internet: TCP/IP, DNS, DHCP, SMTP, POP, VPN, SSL, HTTP, FTP, etc.
• Connaître les principales attaques informatiques: Cross-Scripting, SQL injection, Buffer overrun, etc.
• Savoir se servir d’une machine linux

Tout le monde peut devenir un bon développeur

Dans une entreprise, la différence entre un bon et un médiocre développeur n’est pas à mon sens une affaire de neurones. Une brute en algorithmie peut finalement se relever être un développeur tout ce qu’il y a de plus mauvais pour une entreprise.
C’est plutôt dans l’attitude que l’on reconnaît les bons développeurs.

Apprenez à maîtriser plusieurs langages

Une personne parlant déjà couramment Français, Anglais et Allemand aura plus de facilité à apprendre le Néerlandais, qu’une personne ne parlant que le Français. Avec les langages de programmation, c’est pareil, plus vous en maîtrisez, plus il est facile d’en apprendre de nouveaux.

Je vous conseille donc de sauter sur l’occasion si on vous propose de participer à un projet utilisant un langage que vous ne connaissez pas encore. Si l’occasion ne se présente pas, provoquez-la en apprenant par vous même un langage à la mode.

L’idéal pour un développeur est de connaître au moins 1 ou 2 langages dans chacune des catégories suivantes:

• Langages bas niveau: C, assembleur, …
• Langages Orienté Objets; Java, C#, Eiffel, …
• Langages de Script: Python, JavaScript, Groovy, …
• Langages Fonctionnel: Ruby, Erlang, Caml, …

Le fait de connaître plusieurs langages vous permettra de vous sentir à l’aise avec tout type de code, de connaître les forces et les faiblesses de chaque langage pour en tirer la quintessence.
Le bon développeur sait donc qu’on ne programme pas de la même façon en Java et en C.

Soyez Perfectionniste

Je connais trop de gens qui se satisfont d’une interface graphique médiocre ou d’une fonction à moitié développée. Je répète souvent à l’envi que lorsqu’on développe une fonctionnalité, écrire le code qui fonctionne ne représente même pas la moitie du travail.

Prenez l’exemple d’une épreuve de philosophie lors du bac, il y a une différence entre rendre un brouillon et rendre une copie propre et relue (OK, ça ne vous empechera pas de vous prendre un 4/20, mais ça c’est une autre affaire).

A titre d’exemple, voici les étapes minimum que je m’essaye de m’imposer lorsque j’écris une nouvelle fonctionnalité:

1. Casser la faisabilité, obtenir un premier code qui marche dans le cas nominal, en écrivant des tests unitaires si besoin.
2. Pour chaque instruction, relire le code et gerer tous les cas d’erreurs qui pourraient se presenter
3. Refactoriser et si besoin optimiser le code si besoin
4. Mettre au propre:
   - Enlever les bouts de code commentés qui ne servent plus à rien.
   - Revoir le nommage des variables et des noms de méthodes
   - Enlever les warnings de compilation si besoin
   - Commenter les bouts de code qui ne sont pas triviaux à comprendre
5. Committer le code sur l’outil de gestion de sources (CVS, SubVersion, …)

Inutile d’etre perfectionniste quand ce n’est pas necessaire, sur un prototype jetable par exemple.
En revanche, ne faites pas l’erreur classique d’abaisser votre niveau d’attente envers vous-même parce que le projet est en retard. C’est justement quand on est pressé que le premier jet est bourré de fautes !

Mais au fond, qu’est-ce qu’un mauvais développeur? Intuitivement, nous savons les reconnaître quand nous les voyons (ou quand nous voyons leur code).

Parce que bon, le mauvais développeur, il doit écrire un programme, et ben, il code, tandis que le bon développeur, il doit écrire un programme, bon… il code. Mais bon, c’est un bon développeur

Au passage, si vous ne savez pas différenciez le bon chasseur et le mauvais chasseur, commencez par revoir vos classiques.

Et donc, d’après Thibault, le mauvais développeur a une furieuse tendance à:

• Recoder ce qui existe déjà
• Écrire un code illisible
• Écrire beaucoup de commentaires
• Optimiser à mort

Mais pas seulement. Je rajouterais qu’il a aussi quelques autres mauvaises habitudes:

Il aime chercher les ennuis

Il parle en français, il écrit en français (enfin un dialecte qui y ressemble, les fautes d’orthographe et de grammaire en plus), donc notre mauvais développeur code en français.

String enlèveLesAccents(String chaîne) {
	String résultat = "";
	for (int conteur = 0; conteur < chaîne.length; conteur++) {
		char caractère = chaîne[i];
		if (caractère == 'é' || caractère == 'è' || caractère == 'ê') {
			caractère = e;
		} else if (caractère == 'à') {
			caractère = a;
		}
		résultat += caractère;
	}
	return résultat;
}

Pour celui qui est derrière, c’est juste pénible de taper les accents.
Il aime donc nommer ses variables et ses méthodes dans la langue de Molière avec les accents et tout et tout. Mais parfois il code quand même en anglais…

C’est un adepte du copier/coller

Et oui, notre mauvais développeur code parfois en anglais… quand il pompe du code sur internet ! Ca ne le dérange pas de mettre l’une en dessous de l’autre deux méthodes qui ne sont pas codé dans la même langue, qui n’ont pas la même indentation, les mêmes conventions, etc.

String enlèveLesAccents(String chaîne) {
	String résultat = "";
	for (int conteur = 0; conteur < chaîne.length; conteur++) {
		char caractère = chaîne[i];
   // Remove german accents
   char c = caractère;
   switch (c)
   {
   case 'ü': c = 'u'; break;
   case 'ä': c = 'a'; break;
   case 'ö': c = 'o'; break;
   }
		caractère = c;
		if (caractère == 'é' || caractère == 'è' || caractère == 'ê') {
			caractère = e;
		} else if (caractère == 'à') {
			caractère = a;
		}
		résultat += caractère;
	}
	return résultat;
}

Il aime la concision

Le mauvais développeur aime les noms de variable et de méthode concis.

Franchement on comprend tout de suite que la méthode qui suit enlève les accents de la chaine passée en paramètre. Non?

elvAct(String c) { ... }

Le mauvais développeur adore donc les acronymes et les abréviations, surtout quand peu de personnes les connaissent.

int calcPZT(int p1, double p2, double p4) { ... }

Et quand l’imagination fait défaut, le mauvais développeur sait toujours s’en sortir pour nommer ses variables: v1, v2, v3, …

int calcPTU(int p1, int p2, double p3) {
	double v1;
	int v2;
	String v3;
	byte[] v4;
	v2 = p2 + 7;
	v1 = p1*4.12d + p3;
	v3 = "" + v2;
	v4 = v3.getBytes("UTF-8");
	return 1 + v4.length;
}

Il aime les mystères

Le mauvais développeur aime tester plusieurs versions de son algorithme, et aime laisser des lignes commentées sans qu’on sache pourquoi, ou bien indiquer ce qui ne marche pas sans explications.

int calcPTU(int p1, int p2, double p3) {
	int v2 = p2 + 7;
//	if (v2 < 9) {
//		v2 = 9;
//	}
 
	double v1 = p1*4.12d + p3;
	String v3 = "" + v2;
	byte[] v4 = v3.getBytes("UTF-8");
// TODO: Si p1 vaut 7, alors la fonction ne retourne pas le
// bon résultat, il faudrait corriger ça dans une prochaine version.
	return 1 + v4.length;
}

Remarquez le test sur v2 commenté sans qu’on sache le pourquoi du comment. Le mauvais développeur aime être mystérieux !

La réponse est certainement non, si vous ne connaissez pas votre temps sur 400, 200 ou 100 mètres. L’avantage d’un athlète, c’est qu’il s’est déjà chronométré des centaines de fois sur ces distances. Avec tout cet historique, il est capable d’estimer avec précision le temps qu’il va mettre pour courir la distance en se référant au temps qu’il avait mis un jour comme celui d’aujourd’hui (même état de forme, même conditions climatiques, …) et en l’extrapolant légèrement si besoin.

Et l’informatique… c’est comme la course à pied. La première étape pour faire une bonne estimation du cout d’une nouvelle fonctionnalité, c’est d’avoir des données objectives sur le cout réel d’une tâche similaire.

Si vous n’avez pas l’habitude de noter toutes les estimations que vous faites, puis de les comparer avec le temps que vous avez effectivement mis pour réaliser cette tache, vous pouvez grandement améliorer vos estimations en suivant les quelques conseils suivants.

Avant de commencer une tache, je vous conseille donc de faire une estimation du temps requis pour effectuer cette tache. Ensuite réalisez la dite tache, puis notez le temps que vous avez mis pour effectivement réaliser la tache. Lorsque vous aurez réalisé une dizaine de tache de la sorte, vous aurez assez d’information pour calculer votre qualité relative d’estimation.

Une qualité d’estimation relative supérieure à 1 signifie que vous êtes généralement un peu optimiste dans vos estimations. Si a l’inverse votre qualité d’estimation relative est inférieure à 1, vous êtes plutôt du genre pessimiste. Dans tous les cas, plus vos estimations sont justes, plus votre qualité d’estimation relative est proche de 1.
Ne soyez pas surpris ou frustré si au début, votre qualité d’estimation est de l’ordre de 3 ou de 0.33, elle s’améliorera au fil du temps.

Une fois votre première qualité d’estimation relative calculée, lorsqu’on vous donnera une nouvelle tache à estimer, faites votre estimation en âme et conscience, puis calculez une estimation corrigée.

Cette estimation corrigée devrait normalement être plus proche du résultat final car elle compense votre relative pessimisme ou optimisme. Faites ainsi pour les 5 taches suivantes que vous donnera a réaliser, puis recalculez votre vélocité relative.

Et ainsi si de suite… jusqu’à ce que vous n’ayez plus besoin de compenser vos estimations tellement elles se révèlent exactes !

Pourtant estimer est une tache difficile qui mérite qu’on s’y attarde un minimum. Voici un petit quizz inspiré de celui que vous pouvez lire dans Software Estimation de Steve McConnel. Essayez d’y répondre de telle sorte que vos estimations vous donne 90% chance d’avoir la bonne réponse. Si vous ne connaissez pas une réponse, n’allez pas voir sur Wikipedia mais faite plutôt une estimation suffisamment large pour englober la bonne réponse avec 90% de chance.

Faire le quizz

Si vous avez 9 bonnes réponses ou plus, bravo !
Vous savez estimer avec une certitude de 90%.

Si vous avez 8 bonnes réponses ou moins, vous avez été un peu trop optimiste dans vos estimations. Vous avez essayé sur certaines questions de mettre une fourchette qui se rapproche au maximum de la bonne réponse. C’est tout à votre honneur mais mieux vaut toujours une estimation trop large qu’une estimation fausse !

Le developpeur est en effet une espèce (allez savoir pourquoi) de nature plutot optimiste. Quand on lui demande combien de temps ca lui prendra de rajouter la fonctionnalité n°245, il vous répondra qu’il suffit d’ajouter un bouton ici, un bout de code là et que le tour est joué. En bref: “En 2h c’est bouclé !”.
Dans la réalité au bout de 3h de travail, c’est presque fini.. mais pas complètement: “Donnes-moi encore 15 minutes pour boucler l’affaire”. Au bout de 4h, ça y est ! C’est fini… sauf qu’il reste encore 2 ou 3 bugs à corriger pour que ça puisse être livré. Classiquement, il aura fallu 1 journée de travail pour implémenter la fonctionnalité alors que la tache avait été estimée à 2h.

Pourquoi se mettre dans une situation comme ça tout seul? Quand on vous demande d’estimer une tache, n’essayez pas de faire votre kéké pour impressionner la galerie (genre, moi je code plus vite que tout le monde) et essayez de faire l’estimation la plus juste.

Quelques conseils pour terminer:

• Si vous manquez d’information pour faire votre estimation, prenez le temps de réunir les informations qu’il vous faut. Ça peut être de faire un mini prototype, d’aller regarder le temps effectivement pris pour faire une tache similaire, etc.

• Si votre chef insiste pour vous faire baisser votre estimation, ne soyez pas politiquement correct. Dites-lui que vous pensez sincèrement que votre estimation est juste et qu’il peut consulter ses archives pour voir qu’une tache de ce genre prend effectivement le temps que vous avez estimé (et si votre chef ne garde pas un historique de chaque tache, avec l’estimation et le temps effectivement requis, demandez-lui de commencer à le faire.

Et quand vient l’heure d’ajouter un bouton à l’application, je me pose toujours la question de savoir s’il vaut mieux mettre un bouton qui ressemble à un…bouton, ou bien un bouton qui ressemble à un hyperlien.

On peut considerer que les hyperliens ont pour unique fonction d’amener l’utilisateur sur une nouvelle page HTML dans le navigateur. C’est leur vocation première et devrait donc rester leur vocation unique. Mais les applications Internet riches ont de ceci de particulier qu’elles n’ont en fait qu’une seule page qui peut changer du tout au tout. Un clic sur un bouton dans une telle application peut donc - meme si l’adresse de la page ne change pas - amener sur une autre interface graphique que l’on pourrait considérer comme une nouvelle page.

On pourrait donc utiliser les hyperliens dans les applications Internet riches quand l’action qui se trouve derrière le bouton va le faire changer d’interface graphique.

Au niveau de l’ergonomie, on peut aussi remarquer que les boutons sont beaucoup plus voyant que les hyperliens. On pourrait donc réserver les boutons aux actions que l’on veut mettre en valeur, et mettre des hyperliens pour les actions que l’on ne veut pas mettre en avant.

Regardez l’interface de Google Analytics permettant de choisir une date et remarquez comme la commande Apply utilise un bouton et la commande Cancel, un hyperlien (Et pour mettre cette dernière encore moins en avant, notez que le mot cancel ne commence pas par une majuscule).

Que pensez-vous de cette utilisation des hyperliens dans les applications Internet riches ? Est-ce intuitif ?