De retour de vacances, c’est la rentrée.
Plein d’idées d’articles pour cette nouvelle saison, mais je vais commencer simplement avec un petit ‘quizz’.
Imaginons que l’on vous demande de catégoriser une application en fonction de sa taille, en nombre de lignes de code (LOC) ou en nombre d’objets. Quelle est votre estimation d’une application de petite taille ? Quand dites-vous qu’une application est grosse ? A partir de quels nombres pensez-vous qu’elle est ‘monstrueuse’ ou hors normes ?
Dans notre dernier post, nous avons expliqué la notion d’élasticité, en tant que capacité à déplacer des ressources au sein d’une infrastructure virtuelle afin de répondre avec la meilleure réactivité possible aux demandes métier et aux pics d’activités, ces derniers pas toujours prévisibles.
Mais il ne s’agit pas seulement de pouvoir ‘gonfler’ l’infrastructure en ajoutant les ressources qui s’avèrent nécessaires, sinon – et surtout – de pouvoir ‘dégonfler’ celle-ci en réaffectant ces ressources par ailleurs. A l’image d’un ballon, plus l’infrastructure est élastique, plus elle est facile et rapide à gonfler et dégonfler.
Encore faut-il que les applications veulent bien s’y prêter.
Comme nous l’avons vu dans un post précédent – La qualité dans le cloud – la réduction des coûts reste la motivation principale pour la virtualisation et le cloud, suivi ensuite de l’aptitude á délivrer la capacité.
Lorsqu’il s’agit de dimensionner une infrastructure physique et un budget d’exploitation pour celle-ci, le modèle est le suivant :
Je dois vous faire un aveu : je me suis toujours méfié de la notion de dette technique. Cela m’a toujours paru un concept marketing.
C’est comme si vous décidiez d’acheter une voiture, que le vendeur vous remette fièrement les clés et ajoute avec un petit sourire : « vous devez déjà 10 000 $ ». Et il ne parle pas du crédit auto, non, il veut simplement dire que la voiture que vous venez d’acheter comporte certains défauts qui vont devenir de plus en plus apparents au fil du temps, fatigueront le moteur, la carrosserie, voire même probablement le conducteur.
Quelle serait votre réaction si un vendeur vous disait cela ? Accepteriez-vous d’acheter cette voiture ?
J’ai été invité cette semaine à un évènement comportant des tables rondes entre utilisateurs sur les thèmes du Cloud et de la virtualisation.
J’ai non seulement appris beaucoup de choses, mais surtout découvert la vision du monde de la production et de l’exploitation sur … la qualité des applications.
Avis aux équipes de développement: mangez votre pain blanc tant qu’il est encore temps. Continuer la lecture
Nous avons vu dans le post précédent ‘Cas d’utilisation – Ensemble et sans heurts‘ quels use cases sont les plus souvent appliqués avec un outil d’analyse de code, et permettent d’en tirer le plus grand bénéfice:
Nous avons vu dans les deux posts précédents qu’un certain nombre de cas d’utilisation – assez fréquents – ne nécessitaient qu’un nombre restreint de métriques. Ces cas d’utilisation sont les suivants :
La question posée en commentaires du premier post est la suivante : quelles sont ces 10 ou 20 métriques les plus importantes ? Continuer la lecture
Le Nouvel An est toujours une bonne occasion de renouer des contacts et j’ai appelé un ami avec lequel je n’avais pas parlé depuis quelques temps. Il est également consultant, donc nous nous sommes retrouvés assez vite à échanger sur notre activité, et je lui ai demandé s’il avait des nouvelles d’une société dans laquelle nous avions travaillé ensemble.
Il m’a dit que leurs projets étaient si chaotiques qu’ils ont décidé d’externaliser leurs applications. Ils ont reconnu qu’ils ne parvenaient pas á maintenir un code source correct: trop complexe, trop de difficultés à mettre en œuvre des évolutions, trop de bugs, les plannings ne sont pas respectés, les budgets sont dépassés et l’image de l’IT et sa crédibilité sont en baisse.
Ma première pensée a été qu’ils avaient fait un grand pas en avant: ils savent qu’ils ne savent pas. Continuer la lecture
Noël approche, avec chaque année la même préoccupation : quels cadeaux offrir ? Idéalement, ce qui fera le plus plaisir et qui ne va pas nous ruiner.
J’étais sur un forum en train de rechercher de l’information au sujet d’un lecteur MP3 lorsqu’un post a attiré mon attention : quelqu’un avec un problème sur une console de jeux demandait si le remplacement du composant fautif allongerait la durée de vie de sa console.
J’étais déjà surpris : j’ignorais même qu’on pouvait remplacer un composant sur une console. Si un condensateur de votre PC tombe en panne, vous changeait la carte-mère complète. Et le plus souvent, vous finissez par changer complètement de machine si celle-ci est un peu ancienne. Au-delà de 3 ans d’âge, il devient difficile de trouver des pièces de rechange, et de toutes façons, il est souvent plus intéressant financièrement d’acheter un modèle plus récent. Continuer la lecture
A la suite du post précédent Quelle est la première question ? au sujet des deux questions majeures – coûts vs. risques – quelqu’un m’a demandé si existaient quelques processus ou best practices qui permettent d’atteindre ces deux objectifs.
Existe-t-il un “best of both worlds” afin de produire du code de qualité sans dépasser budgets et plannings ?