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 jjl (site web personnel) . Évalué à 10.
bon ok, je vais me coucher -> |=---|
[^] # Re: Une autre raison ...
Posté par tinodeleste . Évalué à 7.
[^] # Re: Une autre raison ...
Posté par ptitlouis . Évalué à 10.
[^] # Re: Une autre raison ...
Posté par Florent Bayle (site web personnel) . Évalué à 9.
J'en connais même deux :
- TeX dès que Donald Knuth sera mort
- hello.c
[^] # Re: Une autre raison ...
Posté par Dring . Évalué à 1.
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 pierthi . Évalué à 2.
- Nada
- Poudre verte
- MultiDeskOS
Donc bon, l'honneur est sauf.|
[^] # Re: Une autre raison ...
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
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 mmMMOoooOMMmm . Évalué à 5.
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 tinodeleste . Évalué à 10.
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 scand1sk (site web personnel) . Évalué à 2.
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 Anonyme . Évalué à 1.
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 Matthieu Moy (site web personnel) . Évalué à 4.
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 Thomas . Évalué à 3.
http://thedailywtf.com/forums/thread/74323.aspx
[^] # Re: Logiciels pas optimisés
Posté par Guillaume Knispel . Évalué à 5.
De quelle distribution GNU/Linux tu parles ? ;))
# De l'origine des bugs
Posté par Croconux . Évalué à 10.
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 Laurent J (site web personnel, Mastodon) . Évalué à 3.
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.