Journal Pourquoi nous vendons un code contenant des bogues...

Posté par  .
Étiquettes : aucune
0
26
mai
2006
Derrière ce titre... En même temps ce n'est pas moi qui l'ai choisit...

Donc dans cet article [1], Eric Sink developpeur chez SourceGear, nous explique pourquoi il est préférable de vendre un logiciel contenant quelques bugs plutôt qu'un logiciel n'en ayant aucun.

Selon lui, le monde peu être divisé en deux parties :

  • D'un côté, ceux qui savent pourquoi de grosses boîtes vendent des logiciels avec des bogues ;

  • et de l'autre, ceux qui n'en connaissent rien du tout.


Toute modification de code apporte un coût et un risque. En effet, en corrigeant un bogue connu, on peu faire en apparaître un autre sûrement plus grave que celui que l'on vient de corriger et ainsi de suite. Il faut donc choisir les bogues qui doivent être corrigés et ceux qui sont acceptable dans le logiciel finale afin de ne pas perdre trop d'argent.

La correction d'un bogue implique 4 question :

  • Quel est son niveau de gravité ? (Gravité)

  • Quel est sa fréquence d'apparition ? (Fréquence)

  • Quels efforts doit-on fournir pour le corriger ? (Coût)

  • Quel risque implique t'il lors de sa correction ? (Risque)


C'est la réponse à ces 4 question qui déterminera si le bogue doit être corrigé ou non.

[1] http://technology.guardian.co.uk/weekly/story/0,,1781895,00.(...)

En bonus, voici un article sur les 101 dalmatiens logiciels gratuits (j'ai pas dis libres ;-) indispensables.
http://www.pcworld.com/reviews/article/0,aid,124883,pg,1,00.(...)
  • # Une autre raison ...

    Posté par  (site web personnel) . Évalué à 10.

    ... pour pouvoir vendre la version suivante ?

    bon ok, je vais me coucher -> |=---|
    • [^] # Re: Une autre raison ...

      Posté par  . Évalué à 7.

      question subsidiaire: qui connaît un logiciel sans bugs ?
      • [^] # Re: Une autre raison ...

        Posté par  . Évalué à 10.

        A ma connaissance le moteur de TeX n'a pas eu de bug depuis pas mal d'années.
      • [^] # Re: Une autre raison ...

        Posté par  (site web personnel) . Évalué à 9.

        Moi !
        J'en connais même deux :
        - TeX dès que Donald Knuth sera mort
        - hello.c
        • [^] # Re: Une autre raison ...

          Posté par  . Évalué à 1.

          Même un hello.c, tu ne peux pas garantir qu'il soit sans bug, car tu t'appuies sur :

          1) le matériel,
          2) le système d'exploitation,
          3) le compilateur,
          4) des bibliothèques.

          Et tu ne peux pas garantir que sous certaines conditions, un de ces 3 éléments ne va pas faire que ton hello.c aura un comportement non prévu.

          Il est donc IMPOSSIBLE de garantir qu'un logiciel est SANS BUG à moins de détailler très précisément l'environnement exact auquel cette déclaration se rattache, et encore, ce n'est pas une tâche aisée.
          • [^] # Re: Une autre raison ...

            Posté par  . Évalué à 2.

            Moui, mais le monsieur parlait à mon avis du programme en lui même et non de ses composants. De toute façon pour tout ces problèmes, il y a :
            - Nada
            - Poudre verte
            - MultiDeskOS

            Donc bon, l'honneur est sauf.|
      • [^] # Re: Une autre raison ...

        Posté par  (site web personnel) . Évalué à 4.

        Attention, sans bug != sans bug connu.

        Là, on parle de bug connu, bien sûr. Il me semble que MySQL ne sort que quand il n'y a pas de bugs connus (à vérifier).
  • # Logiciels pas optimisés

    Posté par  . Évalué à 5.

    Moi, je dirais que la stratégie de vendre des logiciels pas optimisés est aussi très importante. Prenons par exemple un système d'exploitation très connu qui demande un doublement du processeur et de la mémoire à chaque nouvelle version. Je trouve que ça doit être très cool de bosser pour cette société.

    J'imagine (car je n'y travaille pas) qu'on doit dire au gars : "Hé, t'occupe donc pas de la mémoire et des algos, fait juste un truc sympa visuellement et on pourra le vendre". Ceci ne sont que des supputations. Mais il me plaît à penser qu'il doit y avoir ce genre de directive pour qu'on nous ponde de tels OS, logiciels.

    Et ce ne sont pas les nouveaux matos qui vont nous encourager à optimiser.
    • [^] # Re: Logiciels pas optimisés

      Posté par  . Évalué à 10.

      c'est vrai que quand on fait tourner openoffice2+thunderbird+firefox dans le dernier KDE, on a l'impression que c'est très optimisé au niveau vitesse...

      La stratégie de tout les fournisseurs de logiciels, libre ou non, c'est de mettre de plus en plus de fonctionnalités dans tout leurs logiciels, et ca a un prix, qu'on le veuille ou non.
    • [^] # Re: Logiciels pas optimisés

      Posté par  (site web personnel) . Évalué à 2.

      Euh, je me rappelle bien de la première règle concernant l'optimisation en programmation : ne pas en faire.

      De mémoire, la deuxième règle concernant l'optimisation, mais pour programmeurs avancés uniquement, c'est de ne toujours pas en faire.

      Ceci ne dispense évidemment pas de coder proprement, avec une bonne conception de base et une bonne utilisation des API. Un code simple sera généralement robuste, et faire de l'optimisation dessus risque de rendre le tout plus plantogène pour un gain limité, et beaucoup de temps passé dessus.
      • [^] # Re: Logiciels pas optimisés

        Posté par  . Évalué à 1.

        Euh, je me rappelle bien de la première règle concernant l'optimisation en programmation : ne pas en faire.

        Il y a deux sortes d'optimisations (avec toutes sortes de nuances, mais ou que l'on se place, on peut rattacher soit a l'une catégorie, soit a l'autre) :
        - l'optimisation du code : tu vas chercher a faire en sorte de minimiser le nombre d'instructions nécessaires pour effectuer une opération.
        - l'optimisation algortihmique : tu vas mettre en place une architecture logicielle et une recherches d'algorithmes haut niveau qui vont te permettre de minimiser le nombre d'instruction général pour le fonctionnement de ton logiciel.

        Pour l'une c'est de l'optimisation du code, l'autre du logiciel, et les deux sont de l'optimisation en programmation, mais :
        - La première implique souvent d'écrire du code : illisible, mal documenté, source de bugs et avec encore moins de chances d'être portable (c'est pourquoi on dit de ne pas le faire).
        - La deuxième peut rendre l'architecture globale plus complexe et plus dure a comprendre pour les nouveaux venus, et souvent il faut beaucoup de compétences pour le faire bien. Mais ca paye, en général.

        On peu combiner les deux, particulièrement s'il on a envie de faire une usine a gaz qui devra être mise à la poubelle dans les deux année.
        • [^] # Re: Logiciels pas optimisés

          Posté par  (site web personnel) . Évalué à 4.

          Petit complément : pour les petites optimisations à deux balles dans le code, il faut aussi voir que le compilo fait souvent mieux que le programmeur.

          Donc, le mec qui passe 1h à se demander si il vaut mieux écrire

          if (x != 0) {
          y = 4;
          } else {
          y = 5
          }

          ou

          y = x ? 4 : 5;

          pour les performances, il a tout faut.

          Et d'une manière générale, il vaut mieux écrire d'abord juste, puis utiliser un profiler pour voir où ça coince, et n'optimiser que cet endroit là.
    • [^] # Re: Logiciels pas optimisés

      Posté par  . Évalué à 3.

      Parfois, pour contenter le client, on doit "désoptimiser". C'est pratique on peut par la suite faire payer la "réoptimisation"...

      http://thedailywtf.com/forums/thread/74323.aspx
    • [^] # Re: Logiciels pas optimisés

      Posté par  . Évalué à 5.

      Prenons par exemple un système d'exploitation très connu qui demande un doublement du processeur et de la mémoire à chaque nouvelle version.

      De quelle distribution GNU/Linux tu parles ? ;))
  • # De l'origine des bugs

    Posté par  . Évalué à 10.

    L'article en question met sans le vouloir le doigt sur ce qui constitue une des principales origines des bugs : Les changements de cahier des charges. Les deux exemples mentionnés ne sont pas de bugs, ce sont des demandes de fonctionnalités supplémentaires non prévues au départ. C'est l'implémentation à la va vite de ces fonctionnalités qui a généré des bugs.

    Le logiciel en question n'était sensé au départ ne fonctionner qu'avec SqlServer. Ca faisait partie des acquis. Il doit donc y avoir dans le code de nombreux endroits où on suppose que telle opération doit se comporter de telle manière parce que c'est la façon dont ça marche sur SqlServer. Il est très difficile d'adapter le logiciel dans ces conditions.

    Le deuxième problème n'est pas non plus un bug. Le logiciel n'était pas prévu pour tourner sous Linux. Ce n'était pas demandé au départ. Les développeurs ont donc du supposer que le caractère de fin de ligne etait toujours CRLF que ce soit pour écrire ou parser du texte. Ils ont du modifier en urgence le truc en collant des "if (Windows) CRLF else LF" mais forcément ils en ont oublié. Si la portabilité avait fait partie du cahier des charge dès le départ, ils auraient défini une constante "EndOfLine" dans un coin et terminé.

    Ce genre de changement est quasiment toujours problématique. Le code a été conçu en fonction de la demande initiale et il y a donc probablement dedans pas mal de suppositions. Et si en plus un commercial trouve le moyen de vendre ça en "pas de problème on vous le fait pour demain" toutes les conditions sont réunies pour l'explosion en vol.
    • [^] # Re: De l'origine des bugs

      Posté par  (site web personnel, Mastodon) . Évalué à 3.

      Ils ont du modifier en urgence le truc en collant des "if (Windows) CRLF else LF" mais forcément ils en ont oublié. Si la portabilité avait fait partie du cahier des charge dès le départ, ils auraient défini une constante "EndOfLine" dans un coin et terminé.


      C'est vrai. Mais faut vraiment être un mauvais programmeur pour ne pas utiliser cette constante EndOfLine dans les modifications "d'urgences" et utiliser à la place ce 'if(windows)'. ça ne coûte vraiment rien de déclarer cette constante. Voir même, ça permet des modifs plus rapide.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.