mageekblog Le blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.

Aller au contenu | Aller au menu | Aller à la recherche

cv | twitter | linkedin subversion atoum

Sous-catégories

La programmation n'est pas industrialisable

Je poursuis ici ma réflexion entamée dans mon précédent billet concernant la difficulté de certaines personnes à comprendre qu’il est impossible de quantifier finement et surtout de manière fiable le temps nécessaire à la réalisation d’un logiciel.

Plus j’y pense, plus je me dis que le problème vient du fait que la personne qui demande un tel chiffrage à un développeur pense que la création d’un logiciel est le résultat d’une industrialisation.

Dans notre contexte, la définition la plus adéquate de l’industrialisation est la suivante, d’après Wikipedia :

L’industrialisation désigne le processus de transfert du processus de création de l’offre au processus de réalisation de l’offre.

En résumé, lors de la phase d’industrialisation d’un produit, l’ensemble de la phase de conception de ce produit a été réalisé et il est donc possible de définir précisément les étapes devant être successivement suivies pour l’obtenir à l’extrémité de la chaîne de production.

De plus, puisqu’au moins un exemplaire du produit existe dans le monde réel à l’issue du processus de création, il est possible de quantifier très précisément les ressources temporelles et matérielles qui seront nécessaires pour sa fabrication à grande échelle.

Enfin, pour la même raison, ses spécifications sont clairement définies et il est donc possible de s’y référer afin d’effectuer tout au long de la chaîne de fabrication des contrôles précis pour vérifier la qualité du produit final.

Lire la suite...

Programmer, c'est jouer au Lego… ou pas !

Depuis l’avènement de la programmation orientée objet, le développement d’un logiciel suivant ce paradigme de programmation peut être assimilé à la construction d’un modèle de Lego.

En effet, tout comme le joueur de Lego manipule et assemble des briques en plastiques pour réaliser sa construction, le développeur manipule et assemble des briques logicielles pour réaliser son programme.

Mais il y a cependant quelques différences importantes entre les deux.

Lire la suite...

TDD versus BDD

De plus en plus souvent, j’entends dire que le BDD est mieux que le TDD.

Et à chaque fois je ne peux m’empêcher de sourire doucement, car un développeur qui fait du BDD fait en réalité du TDD , d’après « l’inventeur » du BDD.

Le concept de BDD est en effet apparu pour la première fois en mars 2006 dans un article de Better Software, un magazine ayant pour thème principal la qualité logicielle.

Dan North, l’auteur de l’article en question, y explique en substance que pour faire face à l’incompréhension et aux difficultés que la mise en œuvre du TDD suscitait chez les développeurs, il a eu l’idée d’en changer le vocabulaire afin de le rendre plus « accessible ».

Lire la suite...

La norme et moi

Without deviation from the norm, progress is not possible.

Cette citation de Frank Zappa, que j’ai découvert grâce à cet excellent billet à propos de l’innovation à la Française m’a touché profondément.

En effet, pour le meilleur et pour le pire, j’exerce mon esprit critique sur tout ce qui m’entoure et j’ai donc bien souvent tendance à tout remettre en cause, à sortir des sentiers battus et à dériver plus ou moins fortement de ce que tout le monde considère comme la norme.

D’ailleurs, l’un des meilleurs moyens de m’énerver est certainement de me répondre on a toujours fait comme ça lorsque je demande la valeur ajoutée apportée par un processus, un morceau de code ou toute autre chose qui me paraît à première vue complètement inutile, pour ne pas dire stupide.

Et à ce jour, le résultat le plus beau et le plus visible de cette attitude est sans nul doute atoum.

Je vous invite donc à méditer cette autre citation de Frank Zappa que je me sens bien obligé de qualifier de grand philosophe :

Si tu en arrives à une vie misérable et ennuyeuse parce que tu as écouté ta maman, ton papa, ton professeur, ton curé et je ne sais pas quel mec à la télévision qui t’a expliqué comment mener ta barque, c’est que tu le mérites.

Nous faisons tous des erreurs #1

Nous faisons tous des erreurs lorsque nous développons un logiciel.

Ces erreurs peuvent avoir des origines diverses et variées, être petites ou énormes ou bien avoir des conséquences plus ou moins importantes.

Mais fondamentalement, ce n’est pas l’important.

L’important est d’analyser le processus qui a conduit à l’erreur afin de trouver une solution permettant de ne plus jamais la reproduire à l’avenir et ainsi entrer dans un processus d’amélioration continue.

Cette pratique, connue sous le nom de « rétrospective » dans les méthodes agiles, est redoutablement efficace, même si elle demande parfois beaucoup d’humilité.

Et elle est encore plus efficace lorsque nous pouvons profiter des erreurs d’autrui et plus particulièrement des leçons qu’ils en ont tirées.

Et des erreurs, j’en ai commis dernièrement.

Lire la suite...

- page 1 de 12