Christian Rondeau

Since I can’t find enough time to elaborate on full-length articles (I have a few ideas but no time to put them together), I decided to start a Twitter account. That’s my way of conveying ideas without the need to spend hours dwelving in the details. If you’re interested, I’m trying to stay focused on topics such as software development, software architecture, people management, leadership and other topics.

http://twitter.com/c_rondeau

Also note that I’m currently working on an XNA game with a friend, Marc-André Desilets (http://twitter.com/cyberm4d), a professional 3D artist. I might be tweeting about this too. If there’s interest, I’ll put together more details on the project!

An english version will follow

Bonjour,

Cela fait déjà plus d’un an que je n’ai rien écrit dans ce blog. Notez qu’il ne s’agit nullement d’un manque d’intérêt, mais plutôt de trois points importants.

It’s been more than a year since I’ve been posting in this blog. Take note that it’s not caused by a lack of interest, but by three specific points.

1. La culture

J’ai pris la décision d’écrire ce blog en français pour la simple raison qu’il s’agit de ma langue natale, donc celle que je maîtrise le mieux. Je crois aussi fermement qu’au Québec, le français devrait être utilisé pour toute communication, qu’elle soit d’entreprise ou personnelle. Toutefois, j’entre de plus en plus en communication avec des gens qui ne parlent pas français, des gens avec qui je désire avoir plus de connexions. Je pense donc sérieusement, dans l’optique ou je recommencerais à écrire, à le faire en anglais.

2. Le temps

La raison pour laquelle j’écris moins est principalement le temps; mes priorités changent, et le travail me demande la majorité de ma plage horaire. Je dois donc prioriser intelligemment mais abandonner mon blog n’est pas ce que je crois être un bon choix. Entre temps, j’ai commencé à utiliser Twitter (http://twitter.com/sherlockdotnet), puisque le micro-blogging me permet d’exprimer découvertes et de partager mes connaissances acquises sans nécessiter plusieurs heures.

3. Le contenu

Je m’éloigne de plus en plus du développement logiciel pur pour m’approcher de la gestion. Une grande partie de mon expertise migre, et de cette manière le contenu « pertinent » sur lequel je désire écrire change. Comme je suis encore junior dans ce nouveau domaine, je n’ose pas trop m’avancer, mais n’ayez crainte, ça viendra bien assez vite!

Bref, j’aimerais votre opinion sur ce sujet; contactez moi ou répondez ci-dessous!

ENGLISH VERSION

1. Culture

I took the decision to write in French simply because it’s my native language, therefore the one I master. I also firmly believe into that fact that within Quebec, the French language should be nurtured as a part of our culture in everyday life as well as at work. However, I’m meeting more and more people outside of Quebec who don’t speak French, with whom I’d like to further connect. I’m seriously thinking about switching this blog to English if I do start writing again.

2. Time

My main reason for not writing as often as before is time. My priorities changed, and my work doesn’t allow much time for other things. I then have to prioritize carefully, and I don’t believe abandoning blogging is a wise decision. In the meantime, I’ve began using Twitter (http://twitter.com/sherlockdotnet) as it doesn’t require as much involvement as this blog, and micro-blogging allows for quickly sharing discoveries and knowledge.

3. Content

I’m getting away from pure software development with time, getting into management. A large part of my expertise is switching, therefore the pertinent content that I want to write about is also changing. Because I’m still a beginner in that field, I don’t want to be too loud about things I’m not confident about, but don’t worry. It’ll come fast enough.

In short, I want to hear your opinions;

Même si je dois avouer que garder la maison propre n’est pas mon point fort, lorsqu’il est question de conception la structure est de mise. Peut-être justement parce que je sais pertinemment que je vais oublier des tests unitaires et laisser traîner des stubs. Un point central de cette structure est la gestion d’exceptions. Jusqu’ici, cette bonne habitude s’avère payante, puisque les erreurs sont détectées rapidement, sont faciles à comprendre et sont supportés par de bons outils de suivi. Pourtant, une fois en production, ce même avantage peut être catastrophique lorsqu’on n’a pas un contrôle direct sur l’environnement final; le système plante simplement plus souvent! C’est pourquoi, dans certain cas, il est avantageux de conceptualiser en fonction d’un échec.

En fonction d’un échec? Ha! Pourquoi faire des efforts pour qu’un système fonctionne en cas d’échec, si on peut simplement les prévenir avant d’aller en production? Cette question n’est pas dénuée de sens. C’est d’ailleurs une raison d’être des tests unitaires et d’une bonne gestion d’exceptions. Pourtant, certains cas resteront toujours hors de votre contrôle. La connectivité peut tomber, la machine peut s’éteindre, les données peuvent être corrompues, et vos tests unitaires peuvent aussi être sujets d’erreurs. C’est la raison pour laquelle dans plusieurs cas un système devrait être en mesure de se sortir lui-même d’une situation problématique. Voici quelques exemples:

• Une commande passée dans un système lance une exception lors de l’évaluation des règles de flux de travail. Plutôt que de notifier l’utilisateur de l’erreur, les informations requises pour passer la commande sont gracieusement redirigées à un groupe de support, et l’utilisateur n’est pas impacté.
• Un courriel de notification ne peut pas être envoyé dans un logiciel de gestion. Le système sauvegarde simplement le courriel dans une queue pour être envoyé plus tard, tout en notifiant l’utilisateur que la réception du courriel pourrait être retardée.
• Une requête dirigée sur un serveur dans un parc de machines est perdue lorsque ce dernier flanche. La requête est donc simplement ré-exécutée par le distributeur de charge, ne faisant que ralentir un peu la requête de l’utilisateur plutôt que lui lancer une erreur inutile.

La règle générale est que l’utilisateur ne doit pas répéter une même séquence de travail à cause d’une erreur du système. Pour éviter de créer de nouvelles faiblesses, il est conseillé de:

• Prévoir un mécanisme évitant les boucles infinies lorsqu’une tâche erronée est ré-exécutée
• Prévoir un outillage de suivi efficace; les erreurs cachées doivent tout de même être réglées
• Valider les informations reçues dans tous les nœuds de communication. Quoique cette pratique soit toujours conseillée, dans ce cas elle prend une importance primordiale puisque chaque module peut modifier son comportement en cas d’erreur, et ainsi donner des informations invalides.

On doit tenter de minimiser, dans la mesure du possible, le nombre de points individuels de défaillance. Ces points sont les endroits où une erreur impliquera la défaillance complète d’un système. Dans la plupart des projets web, ces points sont plus rares; on cherchera donc surtout les points de défaillance d’une requête.

Certaines approches simples peuvent faciliter la capacité d’un système à fonctionner même si un ou plusieurs de ses éléments cessent temporairement de fonctionner. En voici quelques exemples:

• Lorsqu’une tâche logicielle sort du contexte de l’utilisateur, conserver les informations requises pour reproduire la requête
• Réduire la validation à la sauvegarde, et écrire des outils de recouvrement pour automatiquement corriger les erreurs
• Offrir des solutions logicielles de rechange lorsque possible; par exemple, si la cache ne fonctionne pas, charger directement de la base de données
• Offrir des solutions utilisateur de rechange lorsque possible; par exemple, offrir de passer la commande par courriel si le système est incapable de la sauvegarder

Le site d’eBay offre un excellent exemple de ce type d’application. Je vous conseille la lecture du document The eBay Architecture; celui-ci est simplement rédigé et reste de très haut niveau. Aussi, une courte entrevue sur le site ACM Queue, effectuée par Steve Bourne avec Bruce Lindsay, explique bien l’idée derrière ce type de conception.

Je n’ai pas eu l’occasion de voir beaucoup de systèmes résistants aux échecs. La plupart du temps, soient ils plantent aussitôt qu’une information n’est pas conforme (mon approche la plus commune), ou ils laissent passer les erreurs sans toutefois les gérer (dans ces cas j’ai les poils qui hérissent). Avec la popularité grandissante des services et de la complexité exponentielle des systèmes interconnectés, il y a de fortes chances pour qu’on trouve de plus en plus de systèmes intelligents capables de se débrouiller, même dans les situations les plus embrouillées!

J’aime beaucoup le refactoring. Ça n’a pas toujours été le cas! Pendant longtemps, j’ai cru que la façon la plus efficace d’écrire du code était de parfaitement conceptualiser l’ensemble de l’application. Un jour, pourtant, je me suis rendu compte qu’il était peut-être sage de commencer à écrire du code tôt. En effet, on peut ainsi mitiger certains risques, avoir un feedback fonctionnel plus rapide, et permettre d’établir certaines bases de travail pour une équipe.

D’un autre côté, je ne peux pas dire avoir complètement abandonné l’espoir de voir une conception solide, suivie d’un développement qui ne change vraiment qu’en surface. J’ai vu et revu le coût monstrueux d’une mentalité dans laquelle le refactoring est la réponse à tout. Écrire du code de mauvaise qualité dans la seule optique de le réécrire différemment (pardonne-moi Martin Fowler, je sais que ce n’est pas le réel esprit du refactoring) est peu productif et démotivant. Comment donc arriver à rallier résultats rapides et bonne conception? Laissez-moi présenter les racines d’une approche qui n’est ni particulièrement nouvelle ou impressionnante, mais qui fait ses preuves. Appelons ça, si vous le voulez bien, la programmation organique.

Pourquoi « programmation organique »? Simplement parce qu’on fait en sorte que l’évolution du code dans le temps se comporte comme lorsqu’on plante un arbre. La structure interne de l’arbre reste invisible et relativement stable, mais de l’extérieur la taille et la forme changent. Quant à nous, nous ne pouvons que sélectionner l’endroit où le planter et lui donner des guides.

L’élément technique central de la programmation organique est l’interface. Oui, je parle des interfaces de programmation! Celles-ci n’ont rien de nouveau et rien d’extraordinaire; je vous avais averti! Ces interfaces délimitent l’espace de chacune des plantes que composent un ensemble de classes. En tout temps, le code est écrit de la manière la plus agile qui soit, mais les interfaces seront toujours incluses dans un processus de conception solide. Quels sont les impacts d’une telle approche?

• La structure de l’application sera toujours solide
• Les impacts d’un code de mauvaise qualité ou temporaire sera mitigé
• Une liberté de développer en mode brouillon dans un contexte carré de sable

Les motifs de conception Pont et Fabrique sont beaucoup utilisés dans cette approche. Voici un exemple simple démontrant comment appliquer cette pratique.

Vous désirez développer une interface utilisateur dans laquelle on utilisera un champ texte pour entrer un chemin vers un dossier. Si le dossier existe, un bouton sera activé. La manière facile de faire ce formulaire est de placer un TextBox et un Button dans un Form, d’attacher un comportement OnTextChanged au TextBox qui modifiera simplement le Button.Enabled en fonction de l’existence du dossier. Cette approche, quoique fonctionnelle et rapide, causera certains problèmes si, en aval dans le développement:

• Le champ texte est séparé en deux (Dossier de base, et dossier relatif)
• Il y a plusieurs boutons à activer (un dans le formulaire et un dans une boîte à outils)
• On désire afficher un message qui décrit pourquoi le dossier est invalide
• On désire remplacer le TextBox par un autre type de contrôle
• On désire enlever le TextBox et utiliser directement une variable (boîte de dialogue)
• On désire ajouter d’autres validations spécifiques
• etc.

Toutes ces situations causent un changement de structure qui finit généralement par dégénérer. Voici donc comment la programmation organique peut réduire les impacts de tels changements.

Premièrement, on désire cacher le TextBox. Celui-ci peut changer, et de toute façon tout ce qui nous intéresse de celui-ci, c’est sa valeur finale. Voici donc l’interface:

public interface ITextBridge
{
  string Text {get; set;}
}

Voici l’implémentation de cette interface dans notre contexte:

public class TextBoxTextBridge : ITextBridge 
{
  private TextBox _textBox;

  public TextBoxTextBridge(TextBox textBox)
  {
    _textBox = textBox;
  }

  public string Text
  {
    get { return _textBox.Text; }
    set { _textBox.Text = value; }
  }
}

Il n’y a rien de très compliqué, mais notez qu’on a complètement découplé le champ texte de son utilisation. Si les besoins changent, on peut très bien remplacer l’implémentation pour utiliser deux champs texte concaténés, deux champs texte utilisés selon une condition ou une variable sans modifier l’interface. Faisons la même chose avec le bouton à valider:

public interface IValidationTarget
{
  void Success();
  void Failed();
}

Notez que cette interface aurait pu être différente. On aurait pu passer un message aux méthodes Success et Failed, ou n’avoir qu’une méthode qui prend un ValidationResult mais pour le moment ça sera suffisant. Pour mieux visualiser comment l’utiliser, voici l’implémentation:

public class ButtonValidationTarget : IValidationTarget
{
  private Button _button;

  public ButtonValidationTarget(Button button)
  {
    _button = button;
  }

  public void Success()
  {
    _button.Enabled = true;
  }

  public void Failed()
  {
    _button.Enabled = false;
  }
}

Maintenant on est prêts à utiliser ces deux classes ensemble. On veut pouvoir changer la source et la cible, mais aussi la validation elle-même! Voici donc l’interface qui nous intéresse:

public interface IMyActionValidator
{
  void Validate();
}

Plutôt simple, n’est-ce pas? Voici, encore une fois, l’implémentation:

public class DirectoryExistsMyActionValidator
  : IMyActionValidator
{
  private ITextBridge _textBridge;
  private IValidationTarget _validationTarget;

  public DirectoryExistsMyActionValidator(
    ITextBridge textBridge,
    IValidationTarget validationTarget
    )
  {
    _textBridge = textBridge;
    _validationTarget = validationTarget;
  }

  public void Validate()
  {
    if (Directory.Exists(_textBridge.Text))
      _validationTarget.Success();
    else
      _validationTarget.Failed();
  }
}

Jusqu’ici tout va bien? Si c’est le cas, on a presque terminé! Tous nos éléments sont en place, et on est prêts à intégrer le tout. Je n’utiliserai pas de Fabrique ici pour démontrer l’impact direct de l’utilisation massive des interfaces. Il nous faut premièrement un membre dans le Form, comme celui-ci:

private IMyActionValidator _validator;

Quelque part dans l’initialisation du Form, il faudra simplement créer la validation de cette manière:

_validator = new DirectoryExistsMyActionValidator(
  new TextBoxTextBridge(textBox1),
  new ButtonValidationTarget(button1)
  );

Il ne manque plus que l’appel! Dans l’événement TextChanged du TextBox, appellons directement:

_validator.Validate();

Évidemment, nous pourrions pousser plus loin cet article pour utiliser des fabriques qui attacheraient automatiquement le TextChanged à un module de gestion d’événements, mais je crois que l’exemple démontré ci-dessus décrit bien comment développer une structure malléable, mais toutefois solide, qui permet de facilement « coder comme ça vient » sans mettre en jeu le coût de maintenance à long terme.

Quoique cette exemple soit simpliste, son application représente bien la méthode qu’est la programmation organique. De plus, on peut appliquer cette théorie récursivement! Pour un groupe d’interfaces, il est toujours possible de cacher l’ensemble derrière une facade, qui jouerait le même rôle que le pont avec le TextBox. Je répète que malgré le drôle de nom que je lui ai affublé, il n’y a rien de nouveau dans cette technique. C’est une approche, munie de ses avantages et ses inconvénients, que j’ai eu l’occasion d’expérimenter avec succès plusieurs fois par le passé.

Si vous avez des commentaires, positifs ou non, sur cet article, ou si vous avez eu l’occasion de l’essayer et voulez me donner votre avis, je vous invite à laisser un commentaire!

J’aimerais vous présenter deux livres que j’ai lus dernièrement, et quoiqu’ils ne soient pas directement reliés au logiciel, ils possèdent certainement une excellente valeur ajoutée dans le domaine des relations sociales, et de la compréhension des systèmes.

Je dois avouer avoir entamé la lecture de The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change de Stephen R. Covey avec une pointe de doute. Quoiqu’on m’ait à plusieurs reprises donné d’excellents commentaires sur ce livre, j’y voyais surtout le discours d’un motivateur plus populaire que d’autres. Je ne dirai pas que je me suis complètement trompé, mais j’ai clairement changé d’avis après la lecture de cet excellent livre. Stephen R. Covey nous prend par la main, et en commençant par notre perception et nos habitudes personnelles, nous montre comment s’épanouir. Je dois le mentionner, le parcours est très difficile mais par l’exemple et un pas à la fois, on s’équipe de bons outils et on ancre solidement nos mousquetons à chaque étape.

La méthode utilisée présente six habitudes à prendre, desquelles découlent une amélioration de la qualité de vie, une motivation plus grande, une meilleure organisation et surtout, une plus grande efficacité autant au plan personnel que professionnel. La septième habitude est la boucle qui permet de rendre ces changements durables. Je vous invite à voir cette page du site careerdevelopmentplan.net pour un résumé du contenu de ce livre.

Sur une autre note, j’ai également parcouru le livre La cinquième discipline : L’Art et la manière des organisations qui apprennent de Peter Senge. J’y ai appris le concept de « pensée systémique », et le langage sous-jacent. Un peu comme les patterns étendent notre langage pour optimiser la communication en développement logiciel, le langage systémique présente des « séquences de base ». Celles-ci permettent de communiquer plus facilement des concepts récursifs et dynamiques. On y trouve également cinq disciplines qui permettent à une entreprise de mettre en place les éléments nécessaires à l’apprentissage en groupe. Pionnier de ces concepts, ce livre vous aidera à comprendre pourquoi certains efforts de changement sont voués à l’échec et pourquoi les meilleurs gestionnaires n’arrivent pas à prévoir certains évènements, et encore moins à en tirer parti. Vous y trouverez aussi des solutions, endossées par plusieurs entreprises reconnues telles que Shell, IBM, Apple et plusieurs autres.

Vous trouverez plus d’informations sur ce livre et sur la pensée systémique sur cette page du site thinking.net.

Ces livres affectent certainement ma manière de percevoir et de considérer plusieurs problèmes inhérents à ma profession. Leur lecture a été un investissement gagnant. Si ces sujets vous intéressent, je vous incite donc à vous les procurer.

Après de bons et loyaux services avec wordpress.com, je lève mon chapeau et déménage, un peu comme d’un appartement à une maison! La nouvelle addresse de mon blogue, la seule à être tenue à jour, sera la suivante: http://blog.christianrondeau.net. Cette acquisition me permettra de rendre disponible des exemples de code, des outils gratuits et toute un éventail d’opportunités! S’il vous plaît, mettez à jour vos favoris, et continuez à me rendre visite dans mon nouveau « chez moi »!

Cliquez ici pour être redirigé vers christianrondeau.net

Combien de fois par jour répétez-vous les mêmes actions? Copier des fichiers, vous authentifier chaque fois que vous compilez, effacer des fichiers temporaires, copier-coller des valeurs… probablement plus souvent que vous ne le croyez. Plus souvent on recommence une même activité, plus elle devient naturelle, automatique, et moins on se rend compte du temps qu’on passe à la faire. Résultat, votre temps « productif » est réduit, au profit d’actions démotivantes et répétitives. De plus, votre concentration est constamment compromise. Il existe pourtant un grand nombre d’outils prévus pour accélérer votre travail, prêts à être utilisés. Surtout, vous êtes en mesure de créer vos propres outils, plus adaptés que tout ce que vous pourriez trouver ailleurs. C’est une tâche plaisante et motivante qui optimisera votre temps, minimisera les perturbations et réduira les risques d’erreurs.

Lisez la suite de cet article sur notre nouveau site, christianrondeau.net

Suite à une épuisante journée de travail, vous entrez chez vous, éreinté. Le simple grincement de la porte vous donne l’impression que quelques neurones de plus viennent de lâcher prise, et errent désormais librement dans la masse informe qui compose votre restant de cerveau. C’est en vous affalant sur votre délicieux divan qu’un autre groupe d’employés de votre cortex décide de déserter suite à la cinglante sonnerie de votre téléphone:
- Hey! C’est Untel! (quels parents grossiers appellent leur enfant comme ça?) Je voulais juste t’inviter à souper demain, je vais faire de la lasagne! Oh, et en passant, bon show!
Le souvenir vous frappe comme une requête SQL passée en texte pur dans l’URL; vous avez un spectacle ce soir! Et l’artiste en représentation est justement le préféré d’Untel. Vous êtes mort de fatigue, et décidez donc de ne plus y aller, et de vendre vos billets.
- Bah, dites-vous en soupirant, je suis complètement à terre. Veux-tu les billets?

Lisez la suite de cet article sur notre nouveau domaine, christianrondeau.net

Dernièrement je me suis rendu compte que je lisais d’excellents livres, mais que je ne partageais pas mes découvertes. Empressé de briser cette image d’égoïsme qui me hante, me voici qui en partage quelques uns avec vous!

Lisez cet article sur christianrondeau.net

Il y a de cela quelques mois, je naviguais sur un petit site Flash qui se vantait de pouvoir deviner mes pensées. Assoiffé de mystères à élucider, me voilà qui pense à un nombre, suis les instructions et surprise! Le symbole associé au nombre auquel j’ai pensé est affiché, auréolé d’étoiles.

Lisez cet article sur christianrondeau.net

Première pensée: Ils devinent avec les mouvements des comportements de ma souris.
Mais je continue à réfléchir, et après quelques microsecondes je ris de moi-même. Je recommence donc l’exercice, sans bouger la souris, et comme je m’y attendais ça fonctionne quand même.

Le truc est simple; il fallait choisir un chiffre entre zéro et cent. Une table à droite montrait des symboles à côté de chaque nombre. Il fallait additionner les deux chiffres du nombre, et soustraire ce résultat au nombre choisi. Par exemple, si on prend 75: 7+5=12, 75-12=63. Mais reprenons le calcul avec un autre chiffre, 72: 7+2=9, 72-9=63. Ah ha! On se rend compte que peu importe le chiffre qu’on choisit, ce sont toujours les mêmes quelques résultats qui reviennent. Il s’agit simplement de mettre le tout en forme, en mettant des symboles différents à chaque fois, tant que les mêmes nombres (63, 72, 81…) donnés aient le même symbole.

Après avoir envoyé ce petit truc à quelques amis, j’ai été étonné du retour. Première réponse que je reçois par messagerie instantanée: « Facile, ça détecte le mouvement de la souris. »

Ces gens savaient pertinemment que ce n’était pas le cas. Et s’ils doutaient, valider leurs doutes ne leur aurait pris qu’une seconde. Mais ce n’est pas ce qu’ils ont fait. Alors me voilà qui réfléchis. Pourquoi ce comportement? Il ne s’agit pas que de paresse. Il s’agit de comment nous traitons les acquis.

J’ai mes théories. Chaque jour des centaines de faits viennent à notre attention. Nous ne doutons pas de la justesse de notre perception de ceux-ci à chaque fois, c’est un comportement qui me semble tout à fait normal… lorsque nous n’avons pas à prendre une décision basée sur ces acquis. Si on fait le parallèle avec la programmation, combien de fois on appelle une méthode qu’on ne connaît pas en ne se basant que sur sa signature? Qu’on corrige un bogue avant même d’essayer de le reproduire? Un classique qui me hante personnellement est lorsqu’on m’explique quelque chose et qu’une conception logicielle se dessine dans ma tête. Lorsque des informations viennent la contredire, plutôt que de simplement l’ajouter à ma compréhension du problème, j’ajuste instinctivement ma première idée en conservant ses fondements. Éventuellement celle-ci n’est plus du tout adaptée au problème, mais je suis quand même convaincu qu’elle l’est.

Mais que faire? Peut-on se débarrasser de ce problème?

Je ne crois pas, non. Mais tout espoir n’est pas perdu! On peut certainement alléger les effets de ce réflexe naturel. Je ne suis pas psychologue, mais j’ai développé quelques trucs que vous pourrez mettre en pratique lorsque vous êtes dans une situation où une solution piétinne la problématique encore immature.

Première étape, définir les moments où les préconceptions causent problème. Ils ont un point en commun; ils commencent par une écoute ou une lecture d’un problème, font fait germer des idées dans votre esprit pendant un échange qui dure aux moins quelques minutes et se terminent par une responsabilité partielle ou complète de votre part pour revenir avec une solution.

Deuxième étape, identifier les préconceptions elles-mêmes. Si on y porte attention, c’est assez facile. Dès que vous avez une conception de la solution en tête avant que la problématique soit complète, vous prenez quelque chose pour acquis.

Troisième étape, se débarrasser du fardeau de l’idée. J’ai personnellement une mauvaise tendance à croire qu’une bonne idée ne doit pas se perdre, mais pensez-y; si la description du problème a donné naissance à un concept, pourquoi prenons nous tout le mérite? Après tout, sans problèmes il n’y aurait pas de vos solutions géniales! Bref, ayez confiance en vos aptitudes et ne vous accrochez pas aux bonnes idées. Il est bon de les noter, mais oubliez les détails. Liez les toujours au problème qui vous a inspiré. Si vous n’arrivez toujours pas à vous débarrasser de l’idée, qu’elle pousse malgré vous, demandez à vos interlocuteurs de faire une pause. Prenez quelques secondes pour y penser, établissez ensuite les raisons pour lesquelles vous avez eu cette idée. Finalement, validez avec les autres personnes si votre raisonnement est bon. Ne divulguez pas l’idée elle-même, car la discussion aurait de fortes chances de tomber sur l’implémentation, et le but est justement d’éviter cette chute. Par exemple, prenez cette situation:

Jules, l’analyste principal du projet, présente à l’équipe de développement les spécifications du système.

- L’utilisateur pourra donc entrer un numéro, énonce Jules, qui correspondra au code du système ABC. Il est important que l’étiquette liée au code soit affichée lorsqu’il valide le code. Il pourra ensuite continuer à remplir le formulaire.

Marc, un des développeurs de l’équipe, perd immédiatement son attention. Il se rappelle d’un article qu’il a lu au sujet des plug-ins. Mais voilà une occasion en or d’implanter ses connaissances! Son raisonnement va comme suit : De cette manière, si on doit changer le système ABC, ou même ajouter d’autres codes, ça sera facile comme tout! Mais Marc ne se laisse pas avoir, et réfléchis aux raisons qu’il l’ont amené à cette conclusion. Premièrement, un système externe est en jeu. Celui-ci peut changer. Ensuite, il s’agit d’une question ordinaire dans un formulaire qui pourrait très bien contenir d’autres cas où les données requises sont reliées à une logique externe au formulaire lui-même. Il pose donc ces questions:

- J’aimerais avoir des précisions. Il s’agit d’une question ordinaire? Est-ce que le système ABC est sous le contrôle de notre client? Finalement, est-ce qu’on prévoit d’autres cas où on devra communiquer avec un autre système?

Les réponses de Jules pourraient être variées. Peut-être que le système ABC est en réalité la base de données que vous devrez utiliser. Peut-être qu’après avoir appris qu’il s’agit d’un webservice déjà implémenté chez le client, vous ferez simplement une question configurée pour appeler un webservice. Peut-être vous rendrez-vous compte que votre idée s’applique toujours, mais dans tous les cas vous aurez les informations nécessaires pour passer à autre chose.

Quatrième étape, prendre du recul. Revenez de temps à autres sur toutes les informations que vous avez et imaginez-vous repartir de zéro. Révisez vos informations dans le désordre. Contredisez-vous, et obligez-vous à accepter qu’une solution ne sera valide que lorsque vous aurez toute l’information en main.

Mais vous n’aurez jamais toute l’information en main. Bienvenue dans le paradoxe de la conception logicielle!