Mots-clé : traductions

30 juin 2014

Pourquoi les formats de fichiers de Microsoft Office sont si compliqués ? (Et quelques moyens de contourner les problèmes)

Cet article est apparu sur la page principale de Joel on Software le mardi 19 février 2008.

La semaine dernière Microsoft a publié le format des fichiers binaires d’Office. Ces formats apparaissent à première vue à la limite de l’insulte. Rien que le format de fichier pour Excel 97-2003 est un fichier PDF de 349 pages ! Attendez, ce n’est pas tout ! Il y a, dans ce document, quelques commentaires intéréssants :

Chaque collection de tableaux Excel (workbook) est stocké dans un fichier qui est une « compilation d’objets ».

Oui, vous voyez, les fichiers Excel 97-2003 sont des « compositions » de documents OLE, qui sont principalement plusieurs fichiers réunis en un seul. C’est tellement compliqué qu’il vous faut lire au minimum 9 pages de spécifications pour réussir à comprendre ça. Et ces « specs » ressemblent plus à des structures en C (« struct« ) que ce à quoi on s’attend normalement quand on lit des spécifications. C’est en réalité un système complet hiérarchique de fichiers.

Si vous avez commencé à lire ces documents avec l’espoir de passer le week-end à écrire rapidos un code qui importe des documents Word dans votre système de blog, ou qui crée des tableaux Internet qui contiennent vos données de comptes bancaires, formattés comme les feuilles Excel de votre suivi personnel, la complexité et la longueur des spécifications vous ont très certainement guéri de ce violent désir. Et vraisemblablement très rapidement. D’ailleurs un développeur normal concluerait que les formats binaires des applications Office :

sont volontairement obscurcis ;
sont le produit d’un cerveau démentiel ;
ont été crée par des développeurs anormalement incompétents ;
et sont impossibles à lire ou écrire correctement.

Vous auriez tort sur tous les points. En creusant un peu, je vais vous montrer comment ces formats de fichier sont devenus incroyablement compliqués, pourquoi cela ne reflète pas l’idée qu’on imagine de la « mauvaise programmation made in Microsoft », et ce que vous pouvez faire pour contourner ces problèmes.

La première chose à intégrer est que les formats binaires ont été conçus avec des objectifs complètements différents de ce qu’on imagine aujourd’hui (HTML). Voici ces objectifs, vous allez ainsi mieux comprendre pourquoi les spécifications sont aussi longues :

Ils ont été spécifiquement conçus pour être rapides sur les vieux ordinateurs. Dans les premières versions d’Excel pour Windows, 1 méga-octets de RAM était une taille normale de mémoire vive, et un PC 80386 à 20 MHz devait faire fonctionner Excel de manière confortable. Il y a donc plein d’optimisations dans les formats de ces fichiers qui ont pour objectif de les ouvrir et de les fermer beaucoup plus rapidement.
Ce sont des formats binaires, donc charger un enregistrement n’est qu’une question de copier directement (« blit ») une séquence d’octets, du disque dur vers la mémoire vive, où vous finissez immédiatement avec un structure de données de type C (« struct« ) qui est utilisable. Il n’y a pas besoin d’analyser ou de parcourir quoi que ce soit lors du chargement. L’analyse syntaxique et le parcours d’un enregistrement sont incomparablement, énormément, atrocement plus longs qu’un simple « blit ».
Le format de fichier est un peu tordu là où c’était nécessaire, là où on fait toutes les opérations habituelles, et cela à des fins de rapidité. Par exemple, Excel 95 et 97 ont quelque chose appelé « Sauvegarde Simple » qu’ils utilisent parfois parce que c’est une variante plus rapide sur une partie spécifique du format OLE, parce que dans les cas de sauvegarde normales, ce n’était pas assez rapide. Word a un menu appelé « Sauvegarde Rapide ». Pour sauver rapidement un long document, 14 fois sur 15, seuls les changement sont ajoutés en fin de fichier, au lieu de réécrire entièrement le document en partant de zéro. Sur les disques durs de l’époque, cela se traduisait par le fait qu’un gros document était sauvé en une seconde au lieu de trente. (Cela signifiait aussi que les données effacées dans un document ne l’étaient pas vraiment et étaient toujours présentes dans le fichier. Ce que beaucoup de gens par la suite n’ont pas apprécié).
Ils étaient crées dans le but de pouvoir utiliser des librairies. Si vous voulez écrire un « importateur » binaire, vous devez prendre en compte des choses telles que le format de métafichiers Windows (« Windows Metafile Format ») (pour dessiner des formes) et la gestion d’objets OLE embarqués (« OLE Compound Storage »). Si vous êtes sous Windows, il y a une librairie qui gère déjà tout ça et rend les choses triviales…. d’ailleurs, s’en servir a procuré un bon gain de temps à l’équipe de Microsoft. Mais si vous faites tout du début à la fin, vous devrez tout faire vous-même.Office s’accomode parfaitement avec tout ce qui est documents embarqués, par exemple, vous pouvez embarquer une feuille Excel dans un document Word. Un déchiffreur parfait de format Word devrait donc aussi être capable de faire quelque chose avec cette feuille embarquée.
Ils n’ont pas été crées avec le mot « interopérabilité » en tête. La supposition à l’époque, et c’était relativement raisonnable de penser ainsi, était que le format Word ne devait être lu et écrit que par Word lui-même. Cela impliquait que lorsqu’un développeur de l’équipe de Word devait prendre une décision sur des changements dans le format du fichier, la seule chose à laquelle il devait faire attention était que ces changements soient (a) rapides à lire et écrire et (b) prennent le moins de code possible dans le programme exécutable Word. Les choses telles que des formats standardisés SGML et HTML, n’ont jamais été pris en compte jusqu’à ce qu’Internet rende indispensable le fait de pouvoir échanger des documents qui soient compatibles entre eux. Et cela, c’est une dizaine d’années après que le format binaire de Microsoft Office n’ait été inventé. De toute façon, il était possible d’utiliser des « importeurs/exporteurs » pour s’échanger des documents. En réalité, Word a vraiment un format crée spécifiquement pour des exports destinés à d’autres programmes, appelé RTF, qui existe d’ailleurs depuis presque le début, et qui est toujours supporté à 100%.
Ils devaient pouvoir intégrer toute la complexité du logiciel. Chaque boîte à chocher (« checkbox »), chaque option de formattage, bref, toutes les possibilités offertes par Microsoft Office doivent être représentées quelque part dans les formats de fichier. Cette boîte à chocher (« checkbox »), dans le menu de Word appelée (« Paragraphe solidaire ») qui force un paragraphe à être automatiquement déplacé sur la page suivante si nécessaire afin de rester associé avec le paragraphe qui le suit ? Cela doit être présent dans le format du fichier.Et cela veut dire que si vous voulez développer un clone parfait de Word, qui peut lire correctement les documents Word, vous devez implémenter cette possibilité. Si vous voulez créer un programme destiné à écrire, qui soit compétitif, et qui a la possibilité de charger des documents Word, cela peut vous prendre une minute pour écrire le code qui va charger ce bit dans le fichier proprement dit, mais cela va certainement vous prendre des semaines à réussir à transformer tout l’algorithme de votre affichage pour que ce dernier s’adapte à ce fameux bit. Si vous ne le faites pas, les clients qui voudront ouvrir leurs documents Word dans votre clone vont voir toutes les pages sens dessus-dessous.
Ils ne peuvent que refléter l’histoire des applications. La plupart des choses compliquées dans ces formats de fichiers concernent des possibilités ou des options qui sont vieilles, compliquées, pas appréciées et rarement utilisées. Elles sont toujours là par souci de compatibilité, et parce que cela ne coûte rien à Microsoft de laisser du code. Mais si vous voulez vraiment faire un boulot complet et dans le moindre détail, et que vous voulez lire et écrire dans ces formats, vous allez devoir aussi faire le travail qu’un interne de chez Microsoft a fait il y a 15 ans en arrière. Le pire de tout c’est qu’il y a des centaines d’années-homme de développement qui se trouvent à l’intérieur de Word de d’Excel, et si vous voulez clôner ces applications complètement, vous allez devoir faire ces centaines d’années de travail. Un format de fichier et juste un résumé très concis de toutes les possibilités qu’offre une application.Juste pour le fun, voyons un exemple minuscule en détail. Un onglet Excel est un paquet d’enregistrements BIFF de types différents. Je ne vais parler que du premier enregistrement BIFF des spécifications. C’est un enregistrement appelé 1904.
Les spécifications du format de fichier Excel sont remarquablement obscures sur cet enregistrement. Elles précisent juste que l’enregistrement 1904 indique « si le système de date 1904 est utilisé ». Ah. Super. Un exemple classique de spécification complètement inutilisable. si vous être un développeur qui travaille sur le format Excel, et que vous lisez ça dans les spécifications, vous pourriez tout à fait en conclure que Microsoft essaie de cacher quelque chose. En effet, vous n’avez pas assez d’information. Il vous faut plus de connaissances pour comprendre tout cela, mais je suis gentil et je vais vous l’expliquer. Il y a deux types de feuillets Excel : ceux qui se basent sur la date de base qui est le 1/1/1900 (avec un bogue d’années bissextiles volontairement crée afin d’être compatible avec Lotus 1-2-3, mais c’est trop ennuyeux pour en parler ici), et ceux dont la date de base est le 1/1/1904. Excel supporte ces deux types de dates parce que la première version d’Excel pour Mac se servait de la date de base du système d’exploitation (c’était le plus facile), mais Excel pour Windows devait impérativement pouvoir importer les fichiers Lotus 1-2-3, qui se servaient de la date de base au 1/1/1900. Déjà rien que ça devrait vous faire pleurer de consternation. Tout au long de cet histoire affligeante, pas un seul développeur n’a pensé à faire quelque chose de correct, mais bon voilà : vous avez la chose ici, et il vous faut faire avec.Vous trouverez vraiment ces deux types de fichiers, 1900 et 1904, un peu partout, selon que le fichier soit originaire de Windows ou de Mac. Les convertir de manière silencieuse peut éventuellement générer des problème d’intégrité des données, donc Excel ne changera jamais le type pour vous. Si vous voulez parcourir des fichiers Excel il faut faudra savoir gérer les deux. Ce n’est pas juste une simple question de charger ce petit bit à partir du fichier. Cela veut dire aussi que vous allez devoir réécrire entièrement tout l’affichage des dates avec un paramètre supplémentaire pour pouvoir prendre en compte ces deux types de date de base (epochs). Comptez au minimum plusieurs jours.

Bien évidemment, lorsque vous travaillerez sur votre clone Excel, vous découvrirez plein de petits détails subtils sur la gestion des dates. A votre avis, quand est-ce qu’Excel fait la conversion de nombres en dates ? Comment fonctionne le formatage ? Pourquoi est-ce que « 31/1 » est interprété comme le 31 janvier de l’année en cours, alors que « 1/50 » est considéré comme le premier janvier de l’année 1950 ? Toute ces petites choses très subtiles qui concernent les comportements ne peuvent pas être complètement documentées à moins d’écrire un document pratiquement aussi long qui le code source d’Excel lui-même.Et c’est juste le premier enregistrement BIFF, alors qu’il y en a plusieurs centaines que vous devrez gérer. Et pour ne rien vous cacher : celui-ci est l’un des plus simples. La plupart des BIFF feront pleurer de rage un développeur expérimenté.

Une seule conclusion s’impose : c’est très gentil à Microsoft de fournir officiellement un document décrivant le format de leurs fichiers Office, mais ça ne va pas pour autant vous rendre la vie super facile si vous décidez d’écrire quelque chose qui importera ou sauvera sous le format Office. Ces applications sont affreusement complexes et subtiles, pleines de possibilités et vous ne pouvez pas simplement implémenter 20 % des fonctions les plus populaire et espérer que 80 % de votre clientèle sera satisfaire. La spécification du format binaire vous aidera à gagner quelques minutes, tout au plus quelques jours, et vous évitera de faire du reverse engineering. Rien de plus.

OK, je vous ai promis quelques solutions de contournement. La bonne nouvelle c’est que pour la plupart des applications qui veulent lire ou écrire au format Office ne font pas un bon choix. Il y a deux alternatives qu’il vous faut immédiatement étudier : soit laisser Office faire ce travail, soit écrire dans un format plus facile (ce qui ne veut pas dire moins puissant).

Laissez Office faire le boulot pour vous. Word et Excel ont des modèles objet extrêmement complets, disponibles via l’automation COM, qui vous donne la possibilité de faire tout par programmation. Dans plein de cas il est beaucoup plus pertinent de réutiliser le code dans Office plutôt que d’essayer de le ré-implémenter. Voici quelques exemples.

Vous avez une application Web qui doit transformer des documents Word en PDF. Voici comment je le ferais : quelque lignes de VBA Word pour charger le fichier et le sauver au format PDF en utilisant le convertisseur PDF intégré de Word 2007. Vous pouvez appeler ce code directement, même en ASP ou ASP.NET sous IIS. Cela fonctionnera. La première fois, il y aura un chargement de Word et ça prendra quelques secondes. Les fois suivantes, Word sera gardé en mémoire par le sous-système COM pendant quelques minutes au cas où vous en auriez besoin. C’est suffisamment rapide pour n’importe quelle application Web de taille moyenne.
Même chose que précédemment, mais vous êtes hébergé sur du Linux. Achetez un serveur Windows 2003, installez une copie de Word avec une licence pro, et mettez en place un petit Webservice qui fait ce travail. Une demi journée de travail avec C# et ASP.NET.
Même chose que précédemment, mais il vous faut être plus réactif : votre application a grossi. Mettez un « load balancer » en face de plusieurs PC que vous aurez mis en place de la même manière qu’à l’étape précédente. Aucun code supplémentaire.

Ce type d’approche pourrait fonctionner si vous avez pour objectif de faire dans vos applications des appels simples et communs à des objets Office. Par exemple :

Ouvrir une fiche Excel, mettre des informations dans les cellules, recalculer, et extraire des résultat des cellules ;
Utiliser Excel pour générer des diagrammes au format GIF ;
Extraire presque n’importe quel type d’information de n’importa quelle feuille Excel sans perdre une seconde à réfléchir au format de fichier qu’il y a derrière ;
Convertir un fichier Excel au format CSV tabulaire (une autre méthode pratique serait d’utiliser le drive ODBC d’Excel pour aspirer suck data out using SQL queries).
Editer des deocuments Word ;
Remplir des fiches Word ;
Convertir des fichiers entre tous les formats supportés par Office (il y a plein d' »importateurs » qui savent lire les formats de programmes de traitement de texte et de feuilles de calcul).

Dans tous les cas, il y a des façons de dire aux objets Office qu’il ne sont pas en dans une applications interactive, et qu’ils ne doivent pas s’occuper de rafraîchir l’écran et qu’ils ne doivent en aucun cas essayer d’ouvrir une boite de dialogue. Au fait, si vous choisissez cette solution, il y a quelques petites astuces et particularités qu’il faut bien avoir en tête, qui ne sont pas officiellement supportées par Microsoft. Parcourez la base de connaissance de Microsoft sur le sujet avant d’aller plus loin.

Utilisez un format de fichier plus simple pour écrire des fichiers. Si vous devez générer des documents Office par la programmation, il y a presque toujours une façon plus facile et plus pratique que le format binaire Office, que vous pouvez utilisez, et que Word et Excel ouvriront tout de même sans problème, le tout sans rien perdre de vos objectifs.

Si vous devez tout simplement générer des données tabulaires pour les ressortir dans Excel, utilisez CSV ;
Si vous avez absolument besoin de formules de calcul que CSV ne supporte pas, le format WK1 (Lotus 1-2-3) est incroyablement plus simple que celui d’Excel, et Excel saura le lire ;
Si vous devez vraiment, absolument, générer des fichiers natifs Excel, commencez par une très vieille version d’Excel… Excel 3.0 est un bon compromis (c’est le format juste avant que tout ces trucs imbriqués dans des trucs imbriqués n’apparaissent), et sauvez un fichier minimal qui contient uniquement les choses dont vous voulez vous servir. Utilisez ce fichier pour voir le nombre minimal d’enregistrements BIFF que vous devrez ressortir et concentrez vous, dans les spécifications, uniquement sur ces parties ;
Pour des documents Word, pensez au format HTML. Word les ouvrira de manière parfaitement transparente.
Si vous voulez vraiment générer des documents Word avec des choses particulière et originales dedans, le meilleur moyen sera presque toujours de générer un fichier RTF. Tout ce que Word peut faire peut être écrit dans un fichier RTF, et ce format est un format text simple, pas binaire, et vous pouvez même changer à la main des choses dans le fichier, et Word l’ouvrira toujours certainement sans problème. Vous pouvez créer un document sympa formatté comme vous le désirez, avec des mots-clé que vous voulez remplacer, vous demandez ensuite à Word de sauver le document au format RTF et vous remplacez à la main (ou par programmation) directement dans le fichier RTF ces champs avec les mots-clé à la volée. Et ce document, vous pourrez l’ouvrir sous Word sans aucun problème.

Pour conclure, à moins que vous ne vouliez créer un concurrent d’Office qui peut lire et écrire tous les fichiers Office parfaitement, auquel cas vous aurez des centaines d’années de travail devant vous, il y a de fortes chances que, quel que soit le problème que vous vouliez résoudre, le plus gros de votre travail soit de lire et d’écrire des fichiers Office.

26 juillet 2011

YSlow : Utiliser des domaines sans Cookie : traduction

Je viens de traduire un gros morceau du texte ici.

Lorsque le navigateur fait une requête pour une image statique, il envoie tout de même les cookies dans la requête. Le serveur ne se sert absolument pas de ces cookies. Ils créent donc un traffic supplémentaire totalement inutile. Il faut s’assurer que tous les composants statiques tels que les images sont récupérés sur des domaines sans cookie. Par exemple, il suffit de créer un sous-domaine static, et d’y mettre les composants adéquats.
Par exemple, si le domaine est www.example.org, il suffit de mettre les composants statiques sur static.example.org. Néanmoins, si vous avez déjà mis en place des requêtes sur le domaine de plus haut niveau, soit example.org, alors les cookies suivront tout de même sur static.example.org. Une solution est d’acheter un nom de domaine dédié.
Par exemple, Yahoo! utilise yimg.com, Youtube utilise ytimg.com et Amazon utilise images-amazon.com.
Un autre bénéfice concerne les proxies : certains proxies refusent de mettre en cache des composants qui ont été demandés avec des cookies. Pour la note, si vous vous demandez s’il vaut mieux utiliser example.org ou www.example.org pour votre page de base, pensez à l’impact des cookies. Le fait de supprimer www ne vous laissera pas d’autre choix que d’écrire des cookies qui seront tous diffusés sur *.example.org.
Donc, pour des raisons de performance, c’est mieux d’utiliser le sous domaine « www » et d’écrire les cookies pour ce sous-domaine.

…
Vous ne voyez pas que je suis en train de pleurer ? J’ai tout faux sur la plupart des sites Internet que j’ai crée. Bon, aujourd’hui c’est nettement moins problématique que si nous étions dix ans en arrière, mais c’est très agaçant de savoir que tout le travail mis en place est à revoir (règles de réécriture, traducteur, etc)… et le discours que je tenais qui va avec (pas la peine des www). On en apprend tous les jours !

3 novembre 2010

Traduction d’une épopée de Dwarf

Traduction d’un extrait de l’article qui relate l’histoire d’un héros.

11/07/2010 : Le paysan m’a demandé de tuer le conjoint du « Monstre Fantôme ». La tanière était un peu dégoûtante, mais en fouinant un peu, j’ai pu trouver quelques pièces de monnaie sur les restes des humains et des gobelins qui avaient été envoyés, respectivement par la Nation des Lapins et le Tic de la Construction. Le conjoint lui-même avait été expédié avec le une relative facilité. Je suis allé directement au château surplombant la rivière annoncer mes actes. Le seigneur de céans m’a envoyé pour tuer l’épouse de la créature sombre à laquelle cette dernière venait de se marier. J’ai pris une fine lame avec moi et je suis parti.

La rivière longeait les portes du château, et quand je suis sorti, nous avons eu quelques ennuis avec un alligator. En fait, c’est surtout la fine lame qui a eu plus d’ennuis que moi, et a fini au beau milieu de la rivière, à un endroit d’où je ne pouvais l’aider. L’alligator est devenu Skinnyrends et je suis reparti sur ma recherche. J’ai trouvé un bronze pectoral dans la première chambre, sans aucun signe du jeune marié autre que le désordre. Je l’ai tout de même trouvé dans la pièce suivante et j’ai coupé sa tête avec ma hache. Trop facile. Il n’était pas seul cependant. La créature sombre vivait toujours là ! Ça s’annonçait plus corsé que prévu. Après avoir réussi à planter mon arme dans son épaule, elle m’a mordu le bras et s’est mise à le secouer violemment. J’ai réussi à me libérer après avoir perdu beaucoup de sang, et c’est juste à ce moment qu’elle a décidé de prendre son hachoir à viande et me l’a planté sur le pied. Je suis parti en courant, en laissant ma hache et mon orteil derrière moi.

J’ai continué ainsi jusqu’à un marché et là un marchand généreux m’a laissé dormir sur son plancher toute la nuit. Au petit matin, j’ai troqué mes pièces, ma cuirasse et la moitié de mes vêtements contre une grande hache de bronze. Mon bras droit était encore inutile, mais je ne pouvais gérer l’arme d’une main. Je suis retourné au château près de la rivière, afin de raconter mon succès… un succès technique, de toute façon, car la recherche concernait l’époux. Alors que je longeais pas à pas les portes du donjon, j’ai assisté à une scène d’horreur. L’alligator Skinnyrends était à l’intérieur et le seigneur était à côté de sa tête sur le sol de pierre ensanglanté. L’un des soldats du seigneur tenait tête, mais j’ai réussi à mater la bête assassine moi-même. J’ai rapporté la mauvaise nouvelle à la femme du soldat, et les rumeurs sur mon dernier exploit m’ont rapidement transformé en un personnage très respecté.

Malheureusement, j’aurai besoin de voyager jusqu’à un autre château bien plus éloigné pour avoir une renommée encore plus grande. En faisant un tour dans le donjon du château, j’ai remarqué un elfe prisonnier. J’ai aussi remarqué qu’il lui manquait un nez. Après un examen minutieux du donjon j’ai fini par trouver son nez parmi les débris. J’avais besoin de quelqu’un pour m’accompagner lors de mon voyage. Quelqu’un qui m’aide à éviter les attaques, principalement de nuit. J’ai donc invité ce prisonnier. Nous avons réussi à atteindre le second château sans problème et nous avons dormi dans une de ses tours.

Au petit matin, la rumeur du personnage très respecté que je suis avait été répandue, et la dirigeante du château m’a demandé, au nom de la Nation des Lapins, de traquer un goblin hors la loi qui ne faisait plus parti du Tic de la Construction, mais était toujours le leader d’un gros groupe….

Etc etc. Vraiment impressionnant.

mes pièces, ma cuirasse et la moitié de mes vêtements pour obtenir une grande hache de bronze. Mon bras droit était encore inutile, mais je ne pouvais gérer l’arme d’une main. Je suis retourné au château par la rivière pour le rapport de mon succès … un succès technique, de toute façon, car la recherche a été l’époux. Comme je l’ai suivi pas à pas les portes du donjon, j’ai assisté à une scène d’horreur. Le Skinnyrends alligator était à l’intérieur, et le seigneur était à côté de sa tête sur le sol de pierre sanglante. L’un des soldats du seigneur tenait tête, mais j’ai réussi à mater la bête meurtrière moi-même. J’ai rapporté de mes nouvelles du conjoint pour le soldat, et avec mon secours à la fin de la garder, je suis devenu un personnage très respecté. Malheureusement, j’aurais besoin de Voyage d’un château au loin à la quête pour la gloire d’autres. En dehors de la garder, j’ai remarqué un prisonnier elfe. J’ai aussi remarqué que son nez était manquant. Un examen médico-légal du donjon a révélé la partie du corps parmi les débris. J’ai besoin de quelqu’un pour Voyage avec moi dans la nature pour aider à dissuader les attaques de nuit sur le long voyage, donc j’ai invité le prisonnier long. Nous l’avons fait au château seconde après sunfall et a dormi dans une des tours.

Google Traduction pour les :Recherches Vidéos E-mails Mobiles Chats Entrepri

4 juin 2008

Comment faire une belle démonstration ?

Vous avez fait un produit super bien. Chouette ! Maintenant, il va falloir le commercialiser, le vendre. Habituellement, c’est grâce à une démonstration, un petit tour de votre produit, de 5 minutes.

Donner accès à une démo est beaucoup mieux qu’essayer d’expliquer ce que fait votre produit avec des mots. Les gens peuvent voir exactement comment les choses fonctionnent, et c’est la façon la plus rapide de les aider à comprendre rapidement ce que fait votre produit, et comment il le fait. Il y a aussi une catégorie de gens qui peuvent être particulièrement intéressés par votre démonstration : les investisseurs. Lorsque vous cherchez des fonds, une bonne démonstration à des investisseurs potentiels peut faire un processus immédiat du « ça passe ou ça casse ». Alors, comment faire une bonne démonstration ?

Lorsqu’on cherchait des fonds pour Weebly, notre démonstration a été plutôt simple. We’d spend about an hour ahead of the meeting looking up the investor’s website, downloading the pictures and text, and importing the template into Weebly. Then, we’d spend a few minutes to practice creating the site quickly. The end result: we’d recreate an investor’s site « from scratch » in front of them in 3-4 minutes. It definitely had the intended « wow » effect.

Comment réussir à faire une belle démonstration ? Voici quelques astuces :

– Elle doit être courte. Elle devrait prendre, en entier, 5 minutes ou moins. Une vidéo en ligne ne devrait jamais dépasser une minute trente secondes.

– Elle doit en jeter plein la vue. Elle doit être vraiment, vraiment cool. La démo est un petit tour visuel, et votre audience sera complètement concentrée sur ce qu’elle peut voir. Votre objectif est de leur faire dire « Wow ! ». Les fondus et les animations deviennent rapidement lasssantes, n’en abusez pas, mais bien placées, elles peuvent faire leur effet.

– Adaptez votre démo à votre audience. Dans notre cas, il nous faut coller aux idées de l’investisseur à qui on va se présenter. La personne à qui vous faites la démonstration doit être capable de s’identifier parfaitement, lui et ses besoins, à votre produit.

– Utilisez des vraies données. Ne tapez jamais « asdfasdf » dans un champ de formulaire. C’est tellement plus facile de comprendre ce qu’une application fait lorsqu’un simule un vrai utilisateur. Les données incohérentes rendent les exemples beaucoup plus difficiles à comprendre. Assurez vous d’avoir bien pré-rempli votre votre base de données avec des données proches de la vie réelle pour mettre clairement en valeur ce que vous exposez.

– N’essayez pas de montrer toutes les possibilités. Montrez uniquement celles qui font que votre logiciel se démarque des autres, les possibilités qui vont faire sortir le « wow » de la bouche des investisseurs.

– Suivez une idée directrice. Si vous sautez du coq à l’âne, faites le souplement, calmement, et soyez le plus clair possible. C’est un peu comme conduire un véhicule : si vous voulez changer de direction, il ne faut surtout pas le faire brutalement sinon c’est l’accident assuré.

– Toujours avoir une sauvegarde prête à l’emploi. La pire des choses qui puisse vous arriver est de vous battre pendant 10 minutes avec la connection WI-FI, ou d’essayer de comprendre pourquoi quelque chose ne fonctionne pas sur votre ordinateur. Vous n’avez peut-être qu’une seule chance. Assurez vous que vous avez une carte Ethernet, si jamais le WI-FI ne fonctionne pas, ou une version qui tourne en local.

– Montrez votre produit sous son meilleur jour. Il vous faut toujours être réaliste sur les petites choses à finaliser ou qui sont en cours de finalisation, si jamais on vous le demande. Assurez vous bien de mettre le plus possible votre produit en valeur et surtout évitez de montrer quelles sont les petits problèmes éventuels et comment les soulever en pratique. De toutes les façons, si vous en êtes conscient, c’est que vous allez rapidement les résoudre, donc parlez-en le moins possible.

Finalement, soyez sûr de vous et très excité. : vous avez fait un produit vraiment cool, et il faut vraiment faire passer ce message à votre audience. Si vous ne trouvez pas votre produit enthousiasmant, pourquoi, eux, le devraient-ils ? Ayez bien en tête qu’il y a de fortes chances pour qu’ils suivent votre humeur. Ne vous déstabilisez pas et restez positif.

1 juin 2008

Jusqu'à quel point peut-on pousser la machine ? (Part. I)

Par Joel Spolsky, mars 2008.

Cet article vient d’ici. Il est en deux parties. Vous trouverez la seconde partie ici.

Première partie

Je n’ai pas beaucoup dormi lorsque j’étais dans l’armée, en Israël, malgré le fait que j’aie servi durant une brève période de paix située entre la fin des gros combats au Liban et le début de l’intifada.

C’était en 1986. J’étais dans un camp d’entraînement de six mois pour devenir sergent d’infanterie et j’étais épuisé. Durant la période d’entraînement basique, nos officiers étaient durs avec nous, mais ils nous laissaient habituellement avoir nos six heures de sommeil par nuit. L’entraînement pour devenir sergent, lui, était plus dur : les officiers nous faisaient nous coucher à minuit, et nous lever à quatre heures du matin. Et pendant ces quatres heures, nous devions tous avoir un tour de garde d’une demi-heure. Pire : comme on ne s’était pas entraîné durant le Sabbath, on s’entrainait presque 30 d’affilée du jeudi au vendredi suivant. Nous étions en permanence épuisés ; on marchait comme des zombies pendant les exercices – exercices qui impliquaient l’utilisation de balles réelles, rien de moins que ça -et le manque de sommeil commençait à avoir un impact grave sur nos performances. Les gens étaient contrariés, et c’était bien plus que le simple fait de râler parce qu’on était soldat dans l’armée.

C’est à ce moment précis, en plein milieu d’un exercice ridiculement difficile (4 jours qui d’exercices qui comprenaient marche, course, simulation d’invasions, roulements dans la boue et autres futilités telles que monter et descendre des marches sans une minute de pause), que le brigadier-général est venu nous voir. Les officiers de ce grade, dans l’armée Israélienne, étaient les gentils policiers, et étaient là afin de nous aider à nous sentir mieux, tandis que les sergents qui nous commandaient au jour le jour étaient les méchants policiers. Il était donc là pour nous faire un discours de « bienfaisance ». Durant les premières minutes, le brigadier-général nous fit un discours brillant sur la strategié qui m’a appris plus en cinq minutes que tout ce que j’ai pu apprendre de dizaines de livres traitant du commerce. Cela concernait le « fire and motion » (« tir puis avance »), une idée qui consistait à alterner l’attaque de l’ennemi et l’avancée pour gagner un peu plus de terrain. Plus tard, lorsque j’ai travaillé à Microsoft, j’ai réalisé que c’était la metaphore parfaite sur la manière dont les compagnies technologiques devaient se comporter pour gagner des parts marché sur leurs concurrents. L’idée expliquée était si intéréssante que je vais consacrer une seconde partie (qui suit celle là) uniquement dessus.

Mais pour l’instant, je vais parler de l’effet général du discours au complet de notre homme. Tout le monde a ses forces et ses faiblesses, et il n’échappait pas à la règle. Malgré le fait que son discours était bien intentionné et intéréssant, la plupart des personnes, qui étaient épuisées, se battaient pour ne pas fermer les yeux et s’endormir. Un petit plus sympa pour le compte de l’armée : on nous avait autorisé à rester debout durant ce genre de discours, si cela pouvait nous aider à rester éveillés. Tout au long du disours, les têtes se levaient et s’abaissaient comme des sousliks.

Finalement, le discours toucha à sa fin et le général nous offrit de répondre à des questions, si nous en avions. « Quels sont les problèmes que vous avez ? », nous demanda-t-il. « Je suis là pour les résoudre pour vous ».

Très noble de votre part, monsieur.

A ce moment un soldat tout au fond de la foule a levé sa main. « Nous n’avons pas assez de temps pour dormir durant ce exercice », a-t-il dit. « Nous dormons à peu près trois heures par nuit. Nous commençons à faire des erreurs vraiment dangereuses avec de vraies munitions parce qu’on n’est pas clairs du tout. »

Les troupes d’élite Israéliennes ne sont pas des mauviettes. Elle n’exagèrent jamais.

Le général sourit et dit : « Ah ! Ce n’est pas un problème. Vous pouvez toujours trouver du temps pour dormir. Par exemple, je dors dans la voiture lorsque je me déplace ». Lui non plus ne plaisantait pas et n’exagérait rien. Ce qu’il voulait dire, c’était que vous pouviez toujours trouver du temps libre et que pendant ce temps libre il fallait en profiter pour faire une sieste, ce n’était pas plus compliqué que ça pour lui. Content de son excellente réponse, le général a de nouveau souri et puis il a fait un signe d’au-revoir.

Comme vous pouvez l’imaginer, l’effet sympatique qu’il pensait avoir fait n’a eu aucun résultat. Non, mon Général, en réalité, on ne peut pas trouver de temps pour dormir, avons-nous pensé. C’est ce qu’on essaie de vous dire, mon Général. On n’a pas de temps libre, et nous n’avons pas de chauffeur non plus : nous marchons, partout, avec au minimum vingt kilos de bagages inutiles sur le dos. Lorsque vous envoyez une petite goutte de café sur votre carte, mon Général, et que vous confondez cette tache avec une colline, cela signifie une marche-détour de 20 kilomètres supplémentaires pour nous. Quelques minutes après que le général soit parti, nous étions encore sous le coup du choc : ce type était complètement désolidarisé de l’expérience de ses propres troupes. Est-ce qu’il pensait vraiment qu’on était crevés parce que nous n’avions pas pensé à dormir à l’arrière de voitures conduites par un chauffeur ?

Lorsque j’ai crée ma société avec mes propres fonds, j’avais, et j’ai encore aujourd’hui, ce discours en tête. Cette désolidarisation complète, cette incapacité de comprendre ces troufions sur le champ de bataille, concerne aussi plein de dirigeants. C’est vraiment très facile d’oublier la vie des autres dans les tranchées, quand on n’y est pas. Après plusieurs années de travail jour et nuit, week-end compris, pour construire une compagnie qui tourne, après avoir sué sang et eau à trimer sur un bureau constitué par une porte posée sur deux tréteaux, les dirigeants d’une société en oublient que les employés qui travaillent pour eux ne sont pas les co-fondateurs : ce sont des employés. Si vous leur donnez une porte pour qu’ils la mettent à plat et s’en servent comme bureau, et que vous leur demandez de travailler le week-end, ils ne vont pas du tout voir les choses comme vous les voyez.

C’est normal. Ils n’ont pas crée la compagnie. Même si vous avez été généreux en leur donnant des stock options, vous êtes celui qui pourra finir avec un hélicoptère et une gigantesque maison en bord de mer à Cannes. Si tout fonctionne à merveille, dans le meilleur des cas, ils auront une jolie petite maisonnette dans le Sud de la France et pourront payer une bonne école à leurs enfants.

Les bons employés peuvent être dévoués, bien sûr, et c’est tout à fait raisonnable de s’attendre à ce qu’ils se décarcassent. Mais, à l’inverse des fondateurs, les employés se sentent concernés par ce qu’il se passe aujourd’hui, maintenant. Ils ne sont pas super enthousiastes pour faire des sacrifices à long terme. Alors ne dites pas à votre excellent chef des ventes de rester ici, juste après un coup de fil important de ses parents qui sont à 200 km de son travail, même si c’est ce que vous avez fait lorsque vous avez démarré la société.

Bosser comme un dingue vous faisait peut-être plaisir et vous faisiez ça gratuitement en rêvant, pendant votre boulot, à la bonne retraite que vous aurez sur un magnifique bateau à St. Tropez ou bien comment vous régalerez vos petits enfants à leur raconter vos histoires du pain dur que vous avez dû manger lorsque vous avez commencé. Mais cette femme, développeur, super intelligente, que vous avez embauché pour vous construire complètement votre site Internet ? Vous pensez qu’elle n’a jamais entendu parler des excellents repas de cantine chez Google ? (NASDAQ:GOOG)

Je dis encore et toujours ces mêmes choses aux patrons qui n’ont toujours pas réalisé cela, lorsqu’ils sont déçus et qu’ils virent tous leurs employés, mauvais et bons, en demandant toujours « pourquoi Olivier (ou Jeanne) n’a pas encore fini son travail ? Je l’aurais terminé ce week-end ! »

Ce général m’a appris une autre leçon sur les subtilités de la direction. Il était arrivé dans un énorme 4×4 flambant neuf, climatisé. Son uniforme était impeccable, et (tenez vous bien, vous allez être surpris) repassé. Je ne savais pas que le fait de dormir peut automatiquement repasser les habits que l’on porte. Ça n’a fait qu’une chose supplémentaire : le démarquer encore plus de nous et de souligner le fait qu’il vivait vraiment dans un monde complètement différent.

De la même façon, lorsqu’une compagnie commence à décoller, et que son fondateur commence à gagner un peu d’argent, il doit garder à l’esprit ce que c’est que d’être salarié. Quelque soit le montant du salaire de vos employés, l’idée qu’il se feront de l’argent sera toujours différente de la vôtre. Vous ne pouvez pas montrer que vous gagnez plein d’argent et espérer qu’ils ne s’en apercevront pas. J’ai entendu parler d’un PDG, embauché dans une start-up en tant que « professionnel expérimenté », qui avait déjà fait sa petite fortune. La compagnie n’avait pas encore commencé à décoller. Bien au contraire, elle démarrait, et tout le monde faisait des sacrifices et travaillait de longues heures pour réussir à faire avancer les choses. Mise à part le PDG. Comme mon général à l’armée, il semblait être dans un monde totalement différent. Il vivait en Californie, et le business était à New York, donc il ne se donnait la peine d’être présent à son bureau que peu de jours par semaine. Il avait pourtant bien donné l’instruction à son équipe de l’appeler si jamais il y avait un problème. « Surtout ne vous inquiétez pas », leur avait-il dit, « j’ai un téléphone portable à côté de la piscine ». Quel que soit le problème, son teint hâlé est devenu le symbole même de tout ce qui n’allait pas dans la société. Imaginez comment auraient été les personnes de l’équipe si, en plus du comportement de leur PDG, ils n’avaient dormi que quatre heures par nuit.

24 mai 2008

La procrastination organisée

Cet article vient d’ici

J’ai essayé d’écrire cet article pendant des mois. Pourquoi est-ce que, finalement, aujourd’hui, je le fait ?

Parce que j’ai du temps libre ? Faux.

Je dois relire des documents, commander des livres, envoyer une demande de remboursement, finir de rédiger des brouillons.

En réalité je me suis mis à écrire cet article pour éviter de faire toutes ces choses. C’est l’essence même de ce que j’appelle la procrastination organisée, une stratégie impressionnante que j’ai découverte, et qui convertit les procrastinateurs en personnes efficaces, respectées et admirées pour tout ce qu’elles arrivent à faire en même temps et pour la bonne utilisation qu’elles font de leur temps. Tous les procrastinateurs, par définition, repoussent tout ce qu’ils ont à faire jusqu’au dernier moment. La procrastination organisée est l’art d’utiliser ce mauvais trait de caractère à bon escient. L’idée clé est que le fait de procrastiner ne veut pas dire « ne rien faire du tout ». Les procrastinateurs ne font rien que très rarement ; il font toujours des choses qui ne sont que peu utiles, telles que tailler des crayons, faire le jardin ou faire un diagramme de la réorganisation de leurs fichiers sur leur ordinateur. Pourquoi est-ce qu’un procrastinateur fait ces choses ? Parce qu’elles sont une façon d’éviter de faire des choses plus importantes. S’il ne restait au procrastinateur qu’à tailler ses crayons, aucune force sur la terre ne réussirait à le convaincre de tailler le moindre petit crayon. Néanmoins, le procrastinateur peut être motivé pour faire des choses difficiles, chronométrées et importantes tant que ces tâches sont des choses qui donnent la possibilité d’éviter de ne pas en faire d’autres qui sont plus importantes.

La procrastination organisée signifie « un moyen de gérer la structure même des tâches d’une manière qui exploite ce trait de caractère ». La liste des tâches qu’on a en tête doit être triée par ordre d’importance. Les tâches qui semblent plus urgentes et importantes sont au sommet. Mais il faut imaginer qu’il y a aussi des tâches importantes à réaliser en bas de la liste. Réaliser ces dernières tâches est un moyen de ne pas faire les autres, situées plus en haut sur la liste. Avec ce type de structuration des tâches, un procrastinateur devient un citoyen utile. Un procrastinateur peut même acquérir, comme moi, une bonne renommée, être efficace et paraître organisé.

La situation la plus parfaite que j’aie jamais eue, pour une procrastination structurée, était lorsque ma femme et moi travaillions en tant que professeurs à Resident Fellows dans Soto House, à Stanford. Le matin, nous avions des papiers à remplir, des interrogations à préparer, du travail qui consistait à résumer des réunions faites, et moi, je quittais à ce moment précis la résidence pour aller juste à côté jouer au ping-pong avec les résidents, ou parler de tout et n’importe quoi avec eux, dans leurs appartements, ou pire, juste rester assis à lire le journal. Je me suis fait rapidement une réputation surprenante, et on pensait que j’étais une des rares professeurs du campus qui était d’accord pour accorder du temps avec les jeunes et qui voulait mieux les connaitre. Quel truc bizarre et marrant à la fois : s’éclater au ping-pong pour éviter de faire des choses plus importantes, et acquérir la réputation du prof le plus sympa du campus !

Les procrastineurs suivent souvent une mauvaise tactique. Ils essaient de minimiser leurs engagements, assumant le fait que s’ils ont peu de choses à faire, ils vont arrêter de procrastiner et faire ces choses. C’est exactement contre la nature du procrastineur et détruit sa source la plus importante de motivation. S’il y a peu de tâches sur une liste, ça veut dire que par définition, ces tâches seront importantes, et que la seule chose à faire pour les éviter est de ne rien faire. C’est la manière la plus efficace de devenir un gros tas de gelée flasque, au lieu d’être quelqu’un d’efficace.
Arrivé ici, vous vous demandez : « Et alors, on fait quoi des tâches tout en haut de la liste, qu’au final, personne ne fait ? ». Je l’admets, il y a un problème potentiel ici.

L’astuce est de choisir vraiment bien les projets qu’on met en haut de la liste. La gestion idéale comporte deux caractéristiques : en premier, il faut qu’il y ait des deadlines (mais en réalité si ce n’est pas fait ce n’est pas la mort), et en second, il faut que les tâches semblent horriblement importantes (mais personne ne va mourir si on ne les fait pas). Heureusement, la vie abonde de tâches qui correspondent à ces deux critères. Dans les universités la grande majorité des tâches relèvent de ces deux catégories, et je suis sûr que c’est la même chose pour toutes les entreprises un peu grosses. Tenez, prenons par exemple la tâche que j’ai écrite juste en haut de ma liste maintenant. C’est de finir un essai sur le thème de la philosophe des langages. Il est supposé être terminé depuis onze mois. J’ai fait plein de choses super importantes entretemps juste pour éviter de travailler dessus. Il y a quelques mois, je me suis senti tellement coupable que j’ai écrit une lettre à mon éditeur en lui disant combien j’étais désolé d’être en retard et où j’ai exprimé mes bonnes intentions pour finir ce que j’ai commencé. Le fait d’écrire cette lettre était encore une façon d’éviter de travailler sur le sujet. Eh bien au final on a vu avec lui que mon planning était à peine derrière tout ce qu’il avait planifié. Mais en réalité est-ce que ce sujet est si important ? Pas tellement important, enfin pas important au point d’imaginer ne rien pouvoir faire d’autre. Lorsque je n’aurai plus rien à faire je m’y mettrai.

Un autre exemple est le remplissage de la fiche de commande de livres. J’ai écrit ça en juin. En octobre, je vais donner un cours sur l’épistemologie. La la fiche de commande de livres est à rendre depuis longtemps. C’est facile d’imaginer que c’est une tâche importante, avec un délai pressant derrière (pour les non-procrastineurs, je préfère signaler que les délais deviennent vraiment urgents une semaine voire deux, après que le délai soit écoulé). J’ai pratiquement tous les jours un beep de la secrétaire du département, des étudiants qui me demandent parfois ce qu’ils auront à lire, et la fiche de commande de livres est là en plein milieu de mon bureau, pile poil sous le sachet dans lequel était mon repas de midi de mercredi dernier. Cette tâche est presque tout en haut de ma liste. Cela me gêne et me motive tout à la fois, de faire d’autres choses utiles mais plus superficielles ou, disons, moins importantes. Mais en réalité, la secrétaire a une pile énorme fiches déjà remplies par des non-procrastinateurs, et elle n’a pas le temps de toutes les faire ! Je remplirai la mienne au milieu de l’été et tout ira bien. J’ai juste besoin de commander des livres connus d’imprimeurs connus et efficaces. Je vais sûrement accepter d’autres tâches apparemment plus importantes entre maintenant et, disons, le premier août. Je me sentirai mieux sur le plan comportemental si je me mets à remplir cette fiche le jour où ce sera vraiment un moyen d’éviter de faire ces autres nouvelles tâches plus importantes.

Le lecteur attentif pourra constater que la procrastination structurée demande une petite dose de déception, parce qu’il faut systématiquement mettre à jour sa propre pyramide des besoins et que celle-ci peut sembler fausse vue de l’extérieur. Parfaitement.

On doit pouvoir se reconnaitre et s’épanouir en exécutant des tâches avec une importance faussement gonflée et des délais irréalistes, tout en ressentant vraiment qu’elles sont importantes et urgentes. Ce n’est pas une difficulté en soi, parce que tous les procrastineurs ont une faculté rare : savoir se mentir à soi-même et y croire.

En conclusion : quoi de plus noble qu’utiliser les défauts d’un caractère pour les transformer en qualités ?

10 mai 2008

Les dix types d'entreprises les plus rentables

Article trouvé ici :

(NB : la traduction n’est pas parfaite car il y a des expressions très technique qui m’ont un peu dépassé. N’hésitez pas à me faire part de vos commentaire et j’y appliquerai les corrections si nécessaire)

Services touchant à la comptabilité
Marge moyenne : 25 %
Il est question des entreprises qui gèrent le grand livre des comptes, de celles qui conçoivent les systèmes de facturation, de fiches de paie, de remboursement, et qui préparent les bilans financiers et tout ce qui concerne les taxes. Bref tout ça fait bien bailler… jusqu’au moment où on voit le profit de ces entreprises. Trois raisons : la mainmise sur le prix de la prestation (toute entreprise a besoin d’un comptable, quel que soit l’état de l’économie en général), peu de débordements et d’embauches nécessaires, et on s’adapte facilement à la taille des entreprises, grâce à tous les clients qui ne peuvent que revenir.
Services juridiques
Marge moyenne : 21. 6%
Les avocats ont une économie plutôt prospère pour – pratiquement – les mêmes raisons que les comptables. Peu d’embauches supplémentaires induites (une secrétaire ou deux, une location de bureaux, et quelques ordinateurs, bref, une dépense acceptable). Le principal revenu se fait au travers de la représentation par l’avocat, ce qui fait qu’il n’y a aucune embauche ou coût caché. Cela maintient un coût réel faible, sachant que le fait de passer les affaires d’un état à un autre aux Etats-Unis est une source abondante de revenus (cela coûte cher – « switching costs »).
Services dentaires
Marge moyenne : 20.9%
De bien belles dents pour un sourire radieux. Et une courbe de coût très basse. C’est normal : les seuls coûts sont liés à une salle pour patient, une aide-soignante et une secrétaire. De plus, les dentistes peuvent recevoir beaucoup de patients, jusqu’à plusieurs par heure. Quelques équipement sont chers, mais globalement tout est intéressant. Mieux, la plupart des patients paient de leur propre poche. Les dentistes ont un pouvoir sur le prix que peu d’autres praticiens ont : pour les autres, les prix sont liés à la sécurité sociale (ou les assurances santé, qui serrent les boulons au maximum et imposent leurs tarifs – valable qu’aux Etats-Unis).
Services spécialisés dans le design
Marge moyenne : 17.6%
Ce melting-pot inclut les designers d’intérieur, les designers industriels (pas les architectes) et les designers graphiques. L’efficacité dérivant de la technologie, tel que le design de logiciels informatiques, ont vraiment aidé à élargir la marge du profit, dans ce business. Et maintenant, les sociétés de design vendent cher leurs talents.
Autres practiciens de la santé
Marge moyenne : 17.5%
Chiropracteurs, optometristes, pédiatres, psychothérapeutes, orthophonistes et professionnels de la santé mentale savent que ça paye, de se spécialiser. Ces practiciens de la santé ont souvent une mainmise sur leurs tarifs, bien plus que les médecins généralistes, parce que la plupart peuvent contourner les grandes organisations de l’assurance santé et consorts. C’est spécifique aux Etats Unis, mais on y viendra bientôt en France, je pense.
Centres de cures et autres
Marge moyenne : 16.9%
Les spas, les centres de soins familiaux (avortement, stérilisation volontaires etc.), les centres des soins mentaux, les centres de désintoxication, etc, tous tombent dans cette catégorie assez vaste. Les patients « séjour court » (qui restent moins d’une journée à l’hôpital) rattrapent cette catégorie : avec les nouvelles technologies, il est possible de traiter de plus en plus de personnes. Les hôpitaux spécialisés « séjour court » sont complètement débordés, et ils commencent à rattraper les « long-séjour ».
Courtiers en assurance
Marge moyenne : 15.9%
Ici, on parle des agents d’assurance, et ceux qui fournissent d’autres services tels que ceux qui gèrent les quittances de paiement. Les agents qui gagnent bien leur vie sont ceux qui font des polices avec un pourcentage de commission annuel : ils prennent une commission sur la vente d’une police d’assurance, mais aussi un certain pourcentage tous les ans, tant que la police d’assurance est valide. Des revenus additionnels sans aucun coût derrière – la formule la plus intelligente.
Médecins
Marge moyenne : 15.8%
Heureusement que les docteurs se font de l’argent : sinon pourquoi se faire suer pendant huit années d’école médicale ? Et quelque soit l’état de l’économie, nous aurons toujours besoin de soins médicaux, et il y aura toujours des gens malades. Néanmoins, aux Etat-Unis, les docteurs voient leurs tarifs pratiquement imposés par les gros assureurs de la santé.
Laboratoires de diagnostiques médical
Marge moyenne : 15.3%
Tous les équipements coûtent extrêmement cher et ce genre d’investissement peut en refroidir plus d’un. Pourtant, une fois mis en place, on rentre rapidement dans ses frais, et on fait par là-même rapidement des bénéfices. Selon le type de laboratoire, le coût caché de « refaire un autre test » reste marginal – si on choisit bien l’équipe qui gère tout ça.
Les intermédiaires liés aux dépôts de garantie et prêts
Marge moyenne : 13.6%
Ce groupe englobe les petites banques, les unions spécialisées dans les crédits (par exemple General Motors Credit Union) et les autres institutions spécialisée pour les dépôts de garantie. En moyenne, pour chaque dollar qui rentre, il y a 48 cents qui ressortent pour régler les coûts cachés et autres remboursement. Alors que la location de bails commerciaux s’est récemment asséchée ces derniers mois, ce groupe d’industrie a échappé à l’orage, mais pour combien de temps ?

25 février 2008

Les choses que vous ne devriez jamais faire

Par Joel Spolsky, le 6 avril 2000.

Vous trouverez l’original ici

Netscape 6.0 est sur le point de publier sa première version beta. Il n’y a jamais eu de version 5.0. La derniere version majeure était la 4.0, dévoilée il y a presque trois ans. Trois ans, c’est une durée horriblement longue dans le monde Internet. Pendant ce temps, Netscape était assis, sans rien pouvoir faire d’autre que de voir leurs ventes s’écrouler.

C’est un peu ingrat de ma part de les critiquer sur le temps d’écart entre les versions principales. Ils ne l’ont pas fait volontairement, n’est-ce pas ?

Eh bien si, c’était volontaire. Ils ont fait la seule et unique, la pire erreur stratégique qu’une entreprise puisse faire :

Ils ont décidé de réécrire le code en entier.

Netscape n’était pas le première société à faire cette erreur. Borland a fait la même erreur lorsqu’ils ont acheté Arago et essayé de l’intégrer dans dBase pour Windows, un projet maudit qui a pris tellement de temps que Microsoft Access a mangé leur déjeûner, et puis ils l’ont recommencé avec Quattro Pro, en repartant à nouveau de zéro, en épatant les gens sur le nombre impressionnant du peu de possibilités qu’il avait. Microsoft a fait presque la même erreur, en essayant de ré-écrire Word pour Windows à partir de zéro, dans un projet lui aussi maudit appelé Pyramid qui a été stoppé, jeté, balayé et caché sous le tapis. Par chance pour Microsoft, ils n’ont jamais cessé de travailler sur le vieux code, donc ils ont eu quelque chose à vendre, transformant tout ça simplement en un désastre financier, et non pas un désastre stratégique.

Nous sommes des développeurs. Les développeurs sont, au plus profond d’eux-mêmes, des architectes, et la première chose qu’ils veulent faire quand ils arrivent dans un chantier est de tout raser, et de faire quelque chose de grand. Nous ne sommes pas excités par la rénovation incrémentale : le bricolage, l’amélioration, et planter des parterres de fleurs.

Il y a une raison subtile qui explique pourquoi les développeurs veulent systématiquement tout jeter et recommencer. La raison est qu’ils pensent que le vieux code est bordélique. Est c’est là que vient une observation intéréssante : ils se trompent très certainement. La raison pour laquelle ils pensent que le code est un bazar, est dûe à une loi de programmation simple, cardinale et fondamentale :

C’est toujours plus dur de lire du code que de l’écrire.

C’est pourquoi réutiliser du code est si difficile. C’est pourquoi dans votre équipe, chacun a sa propre fonction, unique, qu’il aime utiliser pour casser des chaines en tableau d’autres chaines. Ils écrivent leur propre fonction parce que c’est plus facile et plus sympa à faire que d’essayer de comprendre comment on se sert de la vieille fonction.

Un corollaire de cet axiome est que vous pouvez demander à pratiquement n’importe quel développeur aujourd’hui ce qu’il pense du code qu’il sur lequel il travaille. « C’est un bordel total, » vont-ils vous dire. « La seule chose que j’aimerais vraiment est de tout jeter et recommencer proprement. »

Pourquoi est-ce un foutoir ?

« Eh bien, » vous disent-ils, « regarde cette fonction. Elle s’étale sur deux pages ! Il n’y a rien dedans qui appartient réellement à la fonction ! Je ne sais même pas à quoi sert la moitié des appels faits aux API. »

Avant que la nouvelle brochure de Borland pour Windows ne sorte, Philippe Kahn, le fondateur très coloré de Borland, a été cité souvent dans la presse en vantant à quel point Quattro Pro serait meilleur que Microsoft Excel, parce qu’il avait été entièrement ré-écrit. Que du nouveau code source ! Comme si le code source pouvait rouiller.

L’idée qu’un code nouveau est meilleur qu’un code ancien est foncièrement absurde. Le vieux code a été utilisé. Il a été testé. Plein de problèmes ont été soulévés, et ils ont été résolus. Il n’y a aucun problème avec ça. Il ne va pas créer de nouveaux bogues juste en restant assis dans le disque dur sans bouger. Au contraire, baby ! Est-ce qu’un programme est supposé être comme une voiture, il rouille inévitablement ? Est-ce qu’un programme est comme une peluche qui devient grossière et laide si elle n’est pas faite avec un nouveau matériel ?

Revenons à notre fonction qui s’étale sur deux pages. Oui, je sais, c’est juste une fonction très simple qui affiche une fenêtre, mais elle a un peu grandi et semble avoir grossi inutilement, et personne ne sait pourquoi. Eh bien je vais vous le dire, pourquoi : ce sont des résolutions de bogues. L’un deux résoud le problème que Nancy a eu lorsqu’elle a essayé d’installer le programme sur un ordinateur qui n’avait pas Internet Explorer. Un autre résoud ce bogue qui ne sort que dans les cas où on a très peu de mémoire. Un autre résoud le problème du fichier qui est sur un périphérique externe (disquette, clé USB) et qui se voit retirer en plein milieu d’une opération d’écriture. Cet appel à LoadLibrary semble pourri mais le code fonctionne aussi sur des anciennes version de Windows 95.

Chacun de ces bogues a pris des semaines et des semaines d’usage intensif en situation réelle avant qu’ils n’aient été trouvés. Le développeur peut avoir passé plusieurs jours avant de réussir à reproduire le bogue dans le laboratoire, et de l’avoir résolu. Si c’est comme la plupart des résolutions de bogues, la solution ne prend qu’une ligne, ou tout juste la modification de quelques caractères, mais un travail énorme a été fait dans ces « quelques caractères ».

Quand vous jetez du code et recommencez tout à zéro, vous jetez aussi toute cette connaissance qui va avec. Toutes ces corrections de bogues. Des années de travail de programmation.

Vous jetez en réalité ce qui fait que vous êtes en tête dans votre catégorie. Vous donnez, comme ça, gratuitement, un ou deux ans à vos concurrents, et croyez moi, c’est une durée énorme quand on parle de logiciels informatiques.

Vous vous mettez vous-même dans une position extrêmement dangereuse, dans laquelle vous allez continuer à livrer une vieille version avec du vieux code pendant encore quelques années, quelque chose qui sera donc voué à ne pas évoluer et à ne pas réagir à des nouvelles choses que le marché va demander, parce que vous ne pourrez pas intégrer un nouveau code. Si vous n’avez pas les reins solides, vous risquez carrément de couler et de fermer votre boîte.

Vous perdez une somme d’argent colossale à réécrire du code qui existe déjà.

Est-ce qu’il y a une alternative ? Il faut tout de même admettre que le vieux code de base de Netscape était vraiment très mauvais. Eh bien, dans tous les cas, il pouvait être mauvais mais vous savez quoi ? Il fonctionnait super bien sur un nombre impressionnant d’ordinateur différents, dans le monde entier.

Lorsque les développeurs vous disent que leur code est un bordel pas possible (c’est toujours le cas à un moment ou à un autre), il y a trois choses qu’il faut inspecter.

Il y a des problèmes de conception. Le code n’est pas correctement conçu. Le code concernant les échanges réseaux ouvre ses propres boites de dialogue n’importe quand ; cela aurait dû être mieux géré, et surtout ailleurs. Ces problèmes peuvent être résolus, un par un, en déplacant le code avec précaution, en le mettant à jour, et en généralisant à un seul endroit l’affichage des boites de dialogue. Un seul et unique développeur qui travaille sérieusement et qui vérifie un à un, pas à pas, chacun de ses changements, peut faire cela. Je dis un seul, pour que les autres ne soient pas dans l’impossibilité de travailler. Même les changements majeurs d’architecture peuvent être faits sans changer complètement le code. Sur le projet Juno, nous avons passé plusieurs mois à ré-architecturer autour d’un point central : simplement déplacer le code, le nettoyer un peu, créer des classes de base dont le nom et le principe de fonctionnement soit logique, et créer des interfaces d’échanges claires et précises entre les différents modules. Mais on l’a fait précautionneusement, avec notre code de base, et nous n’avons généré aucun nouveau bogue, et cela sans jeter quoi que ce soit de notre vieux code.
Les développeurs pensent que leur code n’est pas optimisé et qu’il est lent. Une rumeur disait que le moteur de rendu de Netscape était lent. Cela n’affectait qu’une petite partie du projet, qu’il était possible d’optimiser ou de ré-écrire. Il n’était pas nécessaire de tout ré-écrire. Lorsqu’on optimise pour la vitesse, 1 % du travail vous donne 99 % des résultats attendus.
Enfin, le code est devenu, avec le temps, illisible. Un projet sur lequel j’ai travaillé avait un type de données appelée ChaineEnBordel. Un autre projet avait commencé en utilisant, par convention, l’écriture de toutes les variables membres par un underscore, puis a changé plus tard pour quelque chose de plus standard, « m_ ». Donc la moitié des fonctions commencaient par « _ » et l’autre moitié par « m_ ». Ce qui rendait le code difficilement lisible. Honnêtement, c’est le type de chose que vous résolvez en 5 minutes avec une macro dans Emacs, pas la peine de repartir de zéro.

Il est très important que vous vous souveniez de cela : lorsque vous repartez de zéro, il n’y a aucune raison de croire que vous allez faire un meilleur boulot que celui que vous avez fait la première fois. Premièrement, vous n’aurez peut-être pas la même équipe de développeurs à gérer. Si cela se trouve, ce ne sera même qu’une équipe de nouveaux développeurs, et donc il n’auront pas « plus d’expérience ». Vous allez dans ce cas refaire à nouveau les mêmes erreurs, et à l’inverse créer de nouveaux problèmes qui n’existaient pas dans la version originale.

Le vieux mantra « construirez en un puis jetez le » est très dangereux, et encore plus lorsqu’il concerne des grosses applications commerciales. Si vous écrivez du code de manière expérimentale, vous voudrez peut-être supprimer la fonction que vous avez écrit la semaine précédente, parce que vous venez de penser à un meilleur algorithme. Très bien. Vous voudrez peut-être factoriser une classe pour la rendre plus facile à utiliser. Très bien aussi. Mais jeter complètement programme est une folie furieuse, et si Netscape avait eu une hiérarchie, et une hiérarchie qui supervisait le projet de manière adulte, avec une expérience dans le domaine du logiciel industriel, ils ne se seraient peut-être pas tiré une balle dans le pied si violemment.

19 juillet 2007

Est-ce si difficile de se couler ? Voilà cinq méthodes efficaces.

Cet article vient d’ici

Il y a un nombre énorme de projets technologiques qui finissent mal. C’est une nouveauté pour personne. Que vous démarriez une compagnie qui vend un programme avec plein de travaux de programmation à venir, ou que vous possédiez une compagnie pas du tout technique qui loue des consultants ici et là afin de vous aider à intégrer des choses dans votre système, vous avez dû très certainement faire face à ce problème. Délais dépassés, budgets explosés, et échecs techniques sont si courants dans le monde informatique, en réalité, que c’est pas si choquant que ça, finalement, quand un gros projet a quelques années de retard et dépasse le budget prévu de plusieurs millions.

En 2003, par example, j’avais pris l’avion pour Los Angeles afin d’assister à une des conférences que Microsoft (NASDAQ:MSFT) organise occasionnellement pour les développeurs. Pendant l’événement, Microsoft a fait tout un tas d’annonces super excitantes au sujet de nouveautés hallucinantes sur le point de sortir pour la prochaine version de Windows. En revoyant mes notes, je vois qu’une des nouveautés vraiment importantes concernait quelque chose appelé WinFS. Je vous évite les détails ennuyeux, mais grossièrement WinFS proposait de combiner un système de fichiers du système d’exploitation (stocker des fichiers et des répertoires sur disque dur) avec des possibilités de base de données (ranger des enregistrements individuels de données pour une recherche et une récupération rapide) en un seul et unique gloubiboulga « fichier-base-de-données ».

C’était une entreprise on ne peut plus ambitieuse. WinFS était, en termes techniques, globalement la réorganisation du système de transport national pour donner la priorité aux bus volants. Oui, cela détruirait les compagnies aériennes, et oui, tous les garages auraient besoin de faire d’énormes travaux pour être élargis afin de pouvoir accueillir ces autobus nouvelle génération qui auraient des ailes, mais, hé, bon, c’est rien, ou le sortira en un an. Bon, au pire deux, allez, tope là !

Trois années se sont écoulées. Un manager à Microsoft, Quentin Clark pour ne pas le nommer, a écrit sur son blog que WinFS ne pouvait tout simplement pas être livré dans les temps, et qu’il était en train de retarder le lancement du dernier système d’exploitation de Microsoft. Donc, WinFS allait être retardé et livré, « peut-être », en tant que fonctionnalité super originale dans une base de données à venir, validant par là le fait qu’il n’allait pas combiner base de données et système de fichiers, ce qui était la seule chose qui le rendait intéréssant. Donc, dites moi, comment pouvez-vous dire quand un de vos projets technologiques est destiné à être un autre WinFS ? Voici mes 5 premiers conseils qui vous assurent un échec sur un projet :

Erreur numéro 1 : débuter avec un équipe de développeurs médiocres.

Créer un programme, l’inventer et construire est une tâche difficile, et malheureusement plein de gens s’auto-proclamment développeurs et pourtant n’y arrivent pas du tout. Malgré le fait qu’une mauvaise équipe de programmeurs soit à mon sens la cause numéro 1 des échecs des programmes informatiques, vous ne pouvez pas le prédire en faisant une étude détaillée des CVs. Dans tous les domaines, en partant du programme, en passant par la logistique, jusqu’au service après vente pour le client, les gens sont beaucoup trop gentils entre eux pour parler du manque de compétence de l’un ou de l’autre, surtout s’ils travaillent côte à côte. Vous n’entendrez jamais personne dire « l’équipe n’était pas suffisamment perspicace, ou n’avait pas assez de talent pour sortir le produit. » Pouquoi blesser les gens ? C’est bien simple : si les personnes qui font partie d’un projet donné ne sont pas très bons dans ce qu’ils font, ils vont venir tous les jours au travail et malgré ça le programme ne sera pas fini. Et surtout, gardez bien en tête que cela ne sert à rien de lorgner du côté des compagnies off-shore prêtes à vous louer, ou vous trouver des personnes pour vous aider à avancer : dans la plupart des cas, je vous garantis qu’ils ne vont rien faire de plus que vous, et ne pourront pas empêcher le fait que vous embauchiez quelqu’un qui ne tient pas la route.

Erreur numéro 2 : posez un jalon par semaine.

Imaginons que vous refassiez votre cuisine. Que le type que vous avez engagé pour faire le travail a déjà fait plein de cuisines avant la vôtre, et peut estimer le coût du projet sans vous sortir les choses dans le détail. Tout ça c’est bien beau, mais il faut avoir conscience que les développeurs de programmes construisent systématiquement des choses qu’ils n’ont jamais construites auparavant. Si c’était le cas, il n’auraient qu’à vous vendre une copie sur un CD de leur programme. Des estimations à la louche sont impossibles. Ils ont un besoin impératif d’avoir un plan détaillé avant qu’ils commencent à écrire du code. Que vous soyiez le client, ou le chef de projet de l’équipe, votre boulot est de vous assurer qu’il y a un plan détaillé. Quand vous demandez à un développeur de donner une estimation à un plan, presque tous vous répondront en faisant un planning grossier, qui découpe les processus en semaines de travail. Ca pourrait sembler raisonnable, mais ça ne l’est pas. Si vous laissez une équipe faire un tel planning, avec des estimations grossières par gros paquets, (par gros paquets j’entends quelque chose qui prend plus de deux jours de développement), vous pouvez être pratiquement certain qu’ils ne prennent pas en compte chaque petit détail qui aura besoin d’être implémenté, et ce sont ces détails qui vont ajouter un énorme délai au projet.

Erreur numéro 3 : négocier la fin du projet.

Quoi de pire que d’accepter une planification dont l’échelle est si grossière qu’on parle, sur un projet informatique, en semaines ? Une chose : demander que l’équipe s’engage à terminer son travail beaucoup plus tôt que les estimations. Avec mon expérience, je vous certifice que la plupart des developeurs sont optimistes et vont vous suivre en s’engageant dans des négociations du genre « découper-tout-ça-autrement ». Vous serez super content, vous aurez un très zoli projet, sur lequel tout le monde s’est mis d’accord, et vous n’allez absolument jamais y coller.

Pensez à cela en ces termes : la mère du veau vêle entre le 15 et 16ème mois. Vous pourriez demander à cette mère de s’engager à 15 mois maximum et elle pourrait tout à fait dire « No problem ! » Ou vous pourriez dire, « Quinze mois ? Vous êtes folle ? Il nous faut ça pour dans huit mois ! » Bien sûr, beugler comme ça ne peut pas accélérer les choses, et même si vous réussissez à faire accepter ce délai à la maman, je vais vous confier un petit secret : elle ne vêlera jamais au huitième mois. Vous pouvez avoir un planning qui dit onze mois, mais vous aurez votre bébé en 15 mois, parce que dans tous les cas c’est le temps qu’il faut pour faire un veau. Seize mois, parfois.

Erreur numéro 4 : diviser les tâches équitablement.

Voilà une superbe façon de torpiller votre projet. Faites une liste de tous les travaux à faire, et, en milieu de projet, redistribuez-les à des personnes différentes afin de tout équilibrer. Si Marie a trop de travail, donnez quelques unes de ses tâches à John. Ca a l’air tout à fait logique, donc personne ne vous contredira.

Je vous promet qu’à moyen ou long terme, cela va inévitablement causer des problèmes. C’est parce que lorsqu’un développeur doit en remplacer un autre, on peut raisonnablement penser qu’il va avoir une efficacité d’un dizième par rapport à son prédécésseur. John va passer des heures entières à essayer de comprendre toutes les choses que Marie connaît déjà sur le bout des doigts dans son propre code. Et John ne résoudra jamais aussi rapidement les problèmes dans le code de Marie que Marie elle-même parce que notre Marie sait où sont cachées toutes les petites astuces et trappes à éviter.

Erreur numéro 5 : travailler jusqu’à minuit.

Imaginons qu’un projet doit prendre six mois à raison de 40 heures par semaines, pour être terminé. Si vous disiez à tout le monde de travailler 60 heures par semaine, vous pourriez finir le développement en quatre mois. L’équipe de programmation devrait même avoir envie de réussir ce challenge parce qu’ainsi ils auront la sensation d’être de vrais héros. (« Incroyable, cette équipe de mamans qui vont vêler en 4 mois, ils sont là même le week-end ! »). Ca devrait fonctionner, non ? Devinez quoi. Il y a des centaines de livres qui établissent un fait qu’on ne peut plus nier : travailler plus d’heures n’aide en rien à sortir quelque chose plus vite. Edward Yourdon, directeur d’une bonne équipe de développeurs, et écrivain, a donné un petit nom à ce genre de projet : « marche funèbre. »

Le développement d’un programme demande un gros effort intellectuel. Même les meilleurs programmeurs peuvent rarement soutenir un niveau d’effort qui atteint quelques heures par jour. Derrière tout ça, ils ont besoin de se changer les idées, car c’est une façon d’aider le cerveau à se reposer, c’est pourquoi on a toujours l’impression qu’ils sont en train de se ballader sur Internet ou en train de jouer à des jeux quand on jette un coup d’oeil à ce qu’ils font

Les forcer à passer plus d’heures devant leur ordinateur ne va jamais se traduire par plus de production, ou si c’est le cas, ce sera de la mauvaise production. Quand leurs cerveaux sont complètement frits, les développeurs créent plus de problèmes qu’ils n’en réparent, en écrivant du mauvais code ou en créant des bogues à n’en plus finir. Et si vous bannissez Internet et les jeux multijoueurs pour les forcer à garder la tête dans le guidon et à écrire du code après les heures où, normalement on se couche, eh bien, il vont très certainement démissionner. Faire une « marche funèbre » n’est pas la seule manière de faire exploser les délais, le budget ou les deux. Mais c’est une manière certaine d’y arriver.

Si ce sont toutes les choses à éviter, comment peut-on s’assurer qu’on projet va dans le bon sens ? En premier lieu, vous avez intérêt à embaucher des superstars. A Fog Creek, on lis en moyenne 400 CVs avant une embauche en CDI, parce qu’un bon développeur peut être dix fois plus productif qu’un développeur normal.

Deuxièmement, demandez une découpe très précise des tâches à faire à chaque developeur. Oui, c’est difficile pour un développeur de prédire le temps qu’il faut pour une nouvelle application. C’est pour cela qu’il faut qu’ils fassent vraiment de bons plans, bien fiables, avant chaque début de projet.

Une fois que vous avez le planning entre les mains, n’essayez pas de réduire la durée. Si le projet ne peut pas être achevé dans une durée que vous estimez raisonnable, la solution est de négocier un planning qui vous convient mieux, mais ne pas toucher à la durée totale. Ou bien éventuellement d’annuler quelques évolutions. Ou, enfin, de mettre de côté certaines options qui ne sont pas forcément nécéssaires.

Pendant le projet vous allez être tenté parfois de réassigner le travail en pensant que cela ira plus vite. Dans ce cas faites très attention. De nouveaux développeurs mettent toujours du temps avant de trouver leur vitesse de croisière et d’arriver, s’ils y arrivent, à la vitesse de leur prédécésseur. C’est bien entendu positif de faire tourner les développeurs sur différents types de travaux, ainsi de cette façon personne n’est irremplacable, mais je le fais très précautionneusement et je réserve dans ce cadre trois semaines complètes sur le planning pour le développeur qui arrive et qui prend la nouvelle place, et une semaine de plus pour celui qui s’en va car il va devoir apprendre le code à son remplacant.

Finalement, encouragez votre équipe à travailler au maximum 40 heures par semaine. Non non, je ne blague pas. Sérieusement. A part de manière vraiment occasionnelle, où nous avons des impératifs vitaux, l’équipe de Fog Creek travaille 8 heures par jour au maximum. Dans notre monde qui devient de plus en plus technologique, il est vital de considérer un gros projet comme un marathon et non pas comme un sprint.