Et si on vendait de la compote au lieu de pommes comme tout le monde ?

Internet est la Mecque des nouveaux logiciels et solutions en ligne. Il est possible de résoudre n’importe quel problème grâce à quelque chose disponible sur internet. Il suffit de savoir où chercher pour identifier la solution qui nous satisfait le mieux.

Pour s’en convaincre, il suffit de visiter le ITunes store, Google play ou la bibliothèque Steam.  Nous avons maintenant plus d’applications disponibles que jamais.  Cependant, il faut se poser un question essentielle : est-ce qu’on a vraiment besoin de tout ça ?

Publicité

Manger sa propre nourriture ou utiliser ses logiciels pour la première fois

Il existe un adage en informatique : consommez ce que vous avez préparé.  L’idée est d’utiliser nous-même les logiciels que nous distribuons à nos clients pour en améliorer la qualité et l’utilisabilité.  Après tout, il est beaucoup plus facile d’ignorer les irritants vécus par un client que ceux qui nous affligent tous les jours.

Payer ses dettes

La dette technique est un concept intéressant en informatique. Elle représente en une seule idée les coûts de modification, d’amélioration et de maintenance d’un logiciel. L’intérêt sur cette dette s’élève à mesure que le logiciel se complexifie.  Elle peut même devenir tellement élevée que tous les nouveaux développements deviennent presque irréalisables.  Mais, à la fin, est-ce qu’on peut faire banqueroute à cause de la dette technique ?

Atterrir sur la lune ou ma calculatrice est plus forte que l’ordinateur d’Apollo

Un jour deux pays ont décidé de se faire la course.  Leur but était vieux comme le monde : montrer qui est le plus fort.  Ils auraient pu choisir n’importe quel cible mais il leur fallait un objectif vraiment impressionnant, quelque chose de grandiose.  Bref un objectif qui tairait les protestataires à tout jamais.  Ils ont fait la course pour la Lune.

Les États-Unis ont été les premiers à l’atteindre.  Pour ce faire, ils ont développé plusieurs nouvelles technologies comme un charmant petit véhicule et un module d’alunissage pas tout à fait aérodynamique.  C’est un excellent exemple de l’ingénierie humaine.  Mais, par rapport à ce qu’on fait aujourd’hui, est-ce que c’est si complexe que ça ?

Poser la première pierre

Est-ce que vous utilisez Twitter?  Savez-vous pourquoi un message a 140 caractères au maximum?  Après-tout, il serait vraiment facile de faire de messages de 200, 300 ou même de 567 caractères.  Il serait beaucoup plus facile d’envoyer un message et on pourrait sûrement dire plus de choses.  Les communications seraient plus efficaces.  Pourtant Twitter n’augmente pas la taille des messages et ils ne semblent pas vouloir le faire.  Pourquoi?

Si une chose peut mal tourner, elle va infailliblement mal tourner.

J’ai dernièrement fait quelques recherches sur la génération de fichiers de diagnostiques et préparé un article sur le sujet.  Nous avons ensuite ajouté cette fonction dans un de nos programmes.  L’objectif étant de générer automatiquement un fichier MiniDump lorsque certains types d’exception se produisent.  Le fichier MiniDump est ensuite compressé et joint au message d’erreur qui est envoyé à notre système de suivi.  C’est génial!  Sauf qu’à partir de ce moment, plus personne ne pouvait nous envoyer de message d’erreur.

Mais où est passée la bible de l’informatique?

Lorsque j’ai débuté en informatique, on programmait sur MS-DOS et on parlait d’un nouveau langage très chic nommé Java.  À cette époque, Internet aurait probablement pu être exploré au complet si on avait assez de temps à perdre et la meilleure façon de s’y connaître en informatique était de s’abonner à des revues ou de lire la bible du sujet.  Je suis d’ailleurs le très heureux possesseur de la bible C++ soit près de neuf cent pages complètement dépassées.  Aujourd’hui, les revues sérieuses d’informatique se comptent sur le bout des doigts, les bibles ont été recyclées depuis belle lurette et les livres sont publiés une version en retard.  D’ailleurs le dernier livre que j’ai acheté concernant un langage de programmation remonte à presque dix ans.

Le projet est en retard, il nous faut un plan

Avez-vous déjà remarqué que la première chose qu’on nous demande de faire lorsqu’un projet est en retard est de produire une liste?  Bien sûr, cette liste est parfois habilement dissimulée par une autre appellation comme un plan d’action ou un état général de la situation.  Mais dans tous les cas, le document produit reste toujours une liste des choses à faire pour compléter le projet.

L’objectif de cette liste est de créer une stratégie claire pour la complétion du projet.  Le client va s’en servir comme étalon pour juger de l’avancement futur du projet.  Elle lui donne une sensation de contrôle parce qu’il sait ce qu’on doit faire, la direction qu’on va suivre et combien de temps on va prendre.  Elle n’existe que pour cet objectif bien particulier soit rassurer le client et lui démontrer qu’on a la volonté de compléter le projet.

On ne peut avoir qu’une seule chance pour faire une bonne impression

La première rencontre avec une nouvelle personne peut définir en grande partie notre relation future.  Il arrive qu’on tombe amoureux ou qu’on déteste profondément quelqu’un au premier regard.  La même chose peut se passer avec une application.  Les premières minutes d’utilisation sont  déterminantes pour la survie de notre logiciel sur l’ordinateur de notre utilisateur.

Et si on optimisait…

Je discutais dernièrement avec d’autres développeurs au sujet de la manière optimale pour conserver des données non-structurées dans une base de données.  Plus précisément nous cherchions à entrer données descriptives liées à un profil utilisateur.  Nous utilisions une base de données relationnelle pour le reste du projet et il me semblait normal de continuer avec le même système.  Nous avions même trouvé une structure permettant de faire le travail.  Elle était cependant un peu lourde.  Ceci a soulevé des craintes sur les performances qu’il était possible d’atteindre chez quelques personnes.  Quelqu’un a alors proposé d’utiliser une base de données non relationnelle pour cette section du logiciel.  La base de données en question était MongoDB.