Joel on Software

Joel on Software   Joël à propos de logiciel

 

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

 

Cinq Mondes


Par Joël Spolsky
Traduit par Gilles Mantel
Vérifié par Thomas Leveque
6 Mai 2002

Quelque chose d'important n'est presque jamais mentionné dans toute la littérature sur la programmation et le développement logiciel, et comme résultat nous nous comprenons parfois mal les uns les autres.

Vous êtes un développeur. Moi aussi. Mais nous n'avons peut-être pas les mêmes buts et exigences. En fait il y a plusieurs mondes différents du développement logiciel, et des règles différentes s'appliquent aux différents mondes.

Vous lisez un livre sur la modélisation UML, et nulle part il n'est dit que ça n'a aucun sens pour programmer des pilotes de périphériques. Ou alors vous lisez un article disant que "le runtime de 20Mo [requis pour .NET] n'est PAS un problème" et il ne mentionne pas l'évidence : si vous écrivez du code pour un pager de 32Ko de ROM c'est réellement un problème !

Je pense qu'il y a cinq mondes ici, se recoupant quelquefois, mais souvent non. Les cinq sont :

  1. Emballé
  2. Interne
  3. Embarqué
  4. Jeux
  5. Jetable

Quand vous lisez le tout dernier livre sur l'Extreme Programming, ou l'un des excellents livres de Steve McConnell, ou Joel on Software, ou le magazine Software Development, vous voyez beaucoup d'affirmations sur comment développer du logiciel, mais vous voyez rarement mention de quelle sorte de développement ils sont en train de parler, ce qui est malheureux, parce que quelquefois on a besoin de faire les choses différemment dans des mondes différents.

Parcourons brièvement les catégories.

L'Emballé est du logiciel qui a besoin d'être utilisé "dans la nature" par un grand nombre de personnes. Il peut en fait être emballé dans du cellophane et vendu à CompUSA, ou il peut être téléchargé depuis internet. Il peut être commercial ou shareware ou open source ou GNU ou quoi que ce soit -- le point important ici est que le logiciel sera installé et utilisé par des centaines de millions de personnes.

L'Emballé a des problèmes spéciaux qui dérivent de 2 propriétés spéciales :

  • Puisqu'il y a tellement d'utilisateurs qui ont souvent des alternatives différentes, l'interface utilisateur doit être plus simple que la moyenne pour rencontrer le succès.
  • Puisqu'il s'exécute sur tellement d'ordinateurs, le code doit être exceptionnellement résistant aux variations entre les ordinateurs. La semaine dernière quelqu'un m'a envoyé un message au sujet d'un bug dans CityDesk qui apparaît seulement avec le Windows polonais, à cause de la façon dont le système utilise Right-Alt pour rentrer des caractères spéciaux. On a testé Windows 95, 95OSR2, 98, 98SE, Me, NT 4.0, Win 2000, et Win XP. On a testé avec IE 5.01, 5.5, ou 6.0 installé. On a testé le Windows américain, espagnol, français, hébreux, et chinois. Mais on n'avait pas encore tout à fait trouvé le temps pour le polonais.

Il y a trois variations majeures de l'Emballé. Le logiciel Open Source est souvent développé sans que personne ne soit payé pour le développer, ce qui change beaucoup la dynamique. Par exemple les choses qui ne sont pas considérées comme "marrantes" ne sont souvent pas faites dans une équipe de volontaires uniquement, et, comme Matthew Thomas l'a fait remarquer de façon éloquente, ça peut nuire à l'ergonomie. Le développement a beaucoup plus de chance d'être dispersé géographiquement, ce qui résulte en une qualité de communication d'équipe radicalement différente. Il est rare dans le monde de l'open source d'avoir une conversation face à face autour d'un tableau blanc en dessinant des boîtes et des flèches, donc le genre de décisions de conception qui tirent profit du dessin de boîtes et de flèches sont habituellement mal prises sur ce type de projet. Le résultat est que les équipes géographiquement dispersées ont fait bien mieux pour cloner des logiciels existants là où peu ou aucune conception n'était nécessaire.

Le Consultingware est une variante de l'Emballé qui requiert tellement de personnalisation et d'installation que vous avez besoin d'une armée de consultants pour l'installer, à un coût scandaleux. Les solutions de CRM et de CMS tombent souvent dans cette catégorie. On a le sentiment qu'en fait elles ne font rien, elles sont juste une excuse pour s'attirer une armée de consultants facturant 300$ de l'heure. Bien que le consultingware soit déguisé comme l'emballé, le fort coût d'une implémentation signifie qu'il ressemble vraiment plus à du logiciel interne.

Le Commercial web-based software comme Salesforce.com ou même le plus commun eBay ont malgré tout besoin d'être facile à utiliser et exécuté sur beaucoup de navigateurs. Bien que les développeurs aient le luxe d'avoir (au moins) un peu de contrôle sur l'environnement de "déploiement" -- les ordinateurs dans l'infocentre -- ils doivent traiter avec une large variété de navigateurs web et un grand nombre d'utilisateurs donc au fond je considère ça comme une variation de l'emballé.

Le logiciel Interne doit seulement marcher dans une situation sur les ordinateurs d'une société. Ça le rend beaucoup plus facile à développer. Vous pouvez faire beaucoup d'hypothèses sur l'environnement dans lequel il s'exécutera. Vous pouvez imposer une version spécifique d'Internet Explorer, ou de Microsoft Office, ou de Windows. Si vous avez besoin d'un graphique, laissez Excel le faire à votre place ; tout le monde dans votre département possède Excel. (Mais essayez ça avec de l'emballé et vous éliminez la moitié de vos clients potentiels.)

Ici l'ergonomie est une priorité moindre, parce qu'un nombre limité de personnes a besoin d'utiliser le logiciel, et ils n'ont aucun choix sur le sujet, et ils devront faire avec. La rapidité du développement est plus importante. Comme le poids de l'effort de développement n'est répartie que sur une société, le montant des ressources de développement qui peut être justifié est significativement moindre. Microsoft peut se permettre de dépenser 500.000.000$ à développer des systèmes d'exploitation qui valent seulement à peu près 80$ pour l'utilisateur moyen. Mais quand Detroit Edison développe une plate-forme de marché pour l'énergie, cet investissement doit avoir du sens pour une société toute seule. Pour obtenir un retour sur investissement raisonnable vous ne pouvez pas dépenser autant que vous pourriez le faire avec de l'emballé. Donc malheureusement beaucoup de logiciels internes sont assez merdiques.

Le Logiciel Embarqué a la propriété unique qu'il termine dans un composant matériel et dans la plupart des cas ne peut jamais être mis à jour. Les exigences de qualité sont bien plus grandes, parce qu'il n'y a pas de seconde chance. Vous pouvez avoir affaire à un processeur qui tourne considérablement moins vite que le processeur de bureau type, donc vous pouvez passer beaucoup de temps à l'optimisation. Le code rapide est plus important que le code élégant. Les périphériques d'E/S qui vous sont disponibles peuvent être limités. Picture of Hertz Neverlost GPSLe système GPS de la voiture que j'ai louée la semaine dernière avait un E/S tellement pathétique que l'ergonomie était lamentable. Est-ce que vous avez déjà essayé de saisir une adresse sur un de ces trucs ? Ça affiche un "clavier" à l'écran et il faut utiliser les flèches de direction pour choisir les lettres depuis 5 petits tableaux de 9 lettres chacun. (Suivez le lien pour plus d'illustrations sur cette IHM. Le GPS de ma voiture a un écran tactile ce qui rend l'IHM considérablement meilleure. Mais je m'éloigne).

Les Jeux sont uniques pour deux raisons. D'abord, les aspects économiques du développement de jeux sont axés sur le hit. Certains jeux sont des hits, beaucoup plus de jeux sont des échecs, et si vous voulez gagner de l'argent dans les jeux vidéos vous devez l'admettre et vous assurer que vous avez un portefeuille de jeux de manière à ce que les cartons commerciaux rattrapent les pertes des échecs. C'est plus comme le cinéma que le logiciel.

Le plus gros problème avec le développement des jeux c'est qu'il n'y a qu'une seule version. Une fois que les utilisateurs auront finit Duke Nukem 3D, ils ne vont pas se procurer Duke Nukem 3.1D juste pour avoir quelques corrections de bugs et de nouvelles armes. A peu de choses près, une fois que quelqu'un a joué à un jeu jusqu'au bout, c'est rasoir d'y rejouer. Donc les jeux ont les mêmes exigences qualité que le logiciel embarqué et un incroyable impératif financier de faire bien du premier coup. Les développeurs de l'emballé ont le luxe de savoir que si 1.0 ne répond pas aux attentes des gens et ne se vend pas, peut être que 2.0 le fera.

Finalement le code Jetable est du code que vous créez temporairement uniquement dans le but d'obtenir autre chose, que vous n'aurez plus jamais besoin de réutiliser une fois que vous avez obtenu cette chose. Par exemple, vous pourriez écrire un petit script shell qui convertit en entrée un fichier que vous avez dans le format dont vous avez besoin pour autre chose, et ceci est une opération d'une fois.

Il y a probablement d'autres sortes de développement logiciel que j'oublie.

Voici une chose importante à savoir. Lorsque vous lisez l'un de ces livres sur les méthodes de programmation écrits par un consultant/gourou du développement logiciel à plein temps, vous pouvez mourir assuré qu'ils sont en train de parler de l'Interne, le développement logiciel d'entreprise. Pas du logiciel emballé, pas du logiciel embarqué, et certainement pas des jeux. Pourquoi ? Parce que les entreprises sont les gens qui engagent ces gourous. Ils payent la note. (Croyez-moi, id software, l'éditeur de Doom et Quake notamment, n'est pas près d'embaucher Ed Yourdon pour parler de l'analyse structurée.).

La semaine dernière Kent Beck prétendait que vous n'aviez pas réellement besoin d'une base de données de suivi des bugs quand vous faites de l'Extreme Programming, parce que la combinaison du binôme de programmation (avec de la revue de code en continue) et du développement dirigé par les tests (garantissant une couverture de code de 100% des tests automatisés) signifie que vous avez rarement des bugs. Ça sonne faux pour moi. J'ai regardé dans notre propre base de données de suivi des bugs ici à FogCreek pour voir quels genres de bugs la tenaient occupée.

Et voilà que je découvre que très peu de bugs là-dedans auraient été découvert par la programmation en binôme ou le développement dirigé par les tests. Beaucoup de nos "bugs" sont en fait ce que XP appelle des stories -- au fond, juste des demandes de fonctionnalités. Nous utilisons notre système de suivi des bugs comme un moyen de nous souvenir, prioriser, et gérer toutes les petites améliorations et les grandes fonctionnalités que l'on veut implémenter.

Un bon nombre des autres bugs ont été découverts après beaucoup d'utilisation sur le terrain. Le truc du clavier polonais. Il n'y a pas moyen que la programmation en binôme trouve ça. Et les erreurs logiques qui ne se sont jamais produites que lorsque des fonctionnalités différentes travaillent ensemble. Plus le programme est grand et complexe, plus il y a d'interactions entre les fonctionnalités dont vous n'avez pas idée. Une séquence improbable de caractères ({${?, si vous voulez savoir) qui déroute l'analyseur lexical. Certains serveurs ftp renvoient une erreur lorsque vous effacez un fichier qui n'existe pas (notre serveur ftp ne se plaint pas donc ça ne nous est jamais arrivé.)

J'ai soigneusement étudié chaque bug. Sur les 106 bugs que l'on a corrigé pour la sortie de la version service pack de CityDesk, exactement 5 auraient pu être évités par la programmation en binôme ou la conception dirigée par les tests. On avait en fait plus de bugs dont on avait connaissance et qu'on ne pensait pas significatifs (seulement à corriger par nos clients !) que de bugs qui auraient pu être débusqués par la méthode XP.

Mais Kent Beck a raison, pour les autres types de développement. Pour la plupart des applications développées en interne, aucun de ces trucs ne serait considéré comme un bug. Le programme plante lors d'une saisie erronée ? Redémarrez-le, et cette fois faites attention à vos {${?'s! Et on a seulement une sorte de serveur FTP et personne dans la société n'utilise le Windows polonais.

La plupart des choses dans le développement logiciel sont les mêmes peu importe le genre de projet sur lequel vous travaillez, mais pas tout. Quand quelqu'un vous parle de méthodologie, pensez à comment ça s'applique dans le travail que vous faites. Pensez à d'où vient la personne. Steve McDonnell, Steve Maguire, et moi venons tous d'un coin très étroit : le monde du marché de masse des applications de tableurs sous emballage écrits à Redmond, Washington. Comme tel nous avons des barres plus hautes pour la facilité d'utilisation et plus basses pour les bugs. La plupart des autres gourous en méthodologie vivent de consulting pour le développement de logiciel maison, et c'est de ça dont ils parlent. Dans tous les cas, nous devrions tous être capable d'apprendre quelque chose les uns des autres.



Cet article est paru en version originale anglaise sous le titre Five Worlds  

Joël Spolsky est le fondateur de Fog Creek Software, une petite société éditrice de logiciel située à New York. Il est diplômé de l'Université de Yale et a travaillé comme programmeur et manager chez Microsoft, Viacom et Juno.


Le contenu de ces pages représentent l'opinion d'une personne.
Contenu protégé par le copyright ©1999-2005 par Joël Spolsky. Tous droits réservés.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky