Juillet 2015
Volume 30, numéro 7
Arriviste - pourquoi il est difficile de parler de Tech
Par Ryder Donahue | Juillet 2015
La partie la plus difficile sur le développement de logiciels peut être en parler. Chaque jour, les développeurs doivent articuler détails techniques approfondies et grands concepts logiques, souvent aux gens avec seulement une compréhension qui passe de quoi ils parlent.
Je vois la lutte du peuple avec ça tout le temps et je ne pense pas que c'est parce qu'ils sont mauvais communicateurs ou ont de mauvaises idées. C'est parce que parler de quelque chose d'aussi abstrait que le code est extrêmement difficile. Cela ne serait pas un problème si les communications étaient un fait rarissime en génie logiciel, mais en fait, le contraire est vrai. Une communication efficace est au cœur de tout effort de développement de logiciel efficace, axée sur l'équipe.
Même si vous êtes un programmeur freelance, essayer de comprendre et de livrer ce qu'un client veut peut être un travail pénible. Le défi est encore plus difficile sur de grands projets avec de nombreux développeurs, où chaque membre de l'équipe travaille sur les différentes pièces d'un puzzle qui doit s'emboîtent.
Quelqu'un montrant certains code ou même pseudo-code, peut être un excellent moyen pour obtenir vos idées dans l'ensemble, mais parfois, le code n'est pas disponible, ou il est trop volumineux pour être immédiatement saisie par d'autres au cours d'une conversation. En conséquence, nous sommes souvent reléguées à la main en agitant et descriptions de nobles.
Un autre écueil est lorsque les développeurs supposent les gens à qu'ils parlent sont familiarisés avec le jargon et acronymes, qu'ils s'insèrent dans leurs explications, ou que d'autres ont la connaissance préalable des fonctions d'assistance qui est référencé. Si l'autre partie possède une connaissance fragile de ces concepts, il va ralentir, voire arrêter complètement — le voyage vers la compréhension. Dès qu'une personne entend un acronyme inconnu, une grande partie de la boîte de dialogue suivante est perdue pour eux dans leur lutte pour le contexte.
Plus largement, un dialogue fructueux sur la programmation exige que les deux parties détiennent un plan similaire dans leur esprit au début de la conversation. Ce modèle peut être le contexte du code que vous écrivez ou même l'architecture de l'ensemble du projet. Même si ce bit est habituellement expliqué par nécessité, il n'est pas toujours très bien expliqué, diagrammes UML sont normalement trop gênantes et souvent il n'est pas simplement le temps d'examiner toutes les structures de données et les objets en détail. Le résultat : Équipes souvent ne parviennent pas à satisfaire aux exigences de conduire à des décisions éclairées, et pourtant nous avons tous continuer à faire de toute façon.
La communication est un défi difficile et celle avec qui j'ai personnellement du mal. Mais c'est une faiblesse qui, si reconnu, peut être travaillée. En tant que développeurs, nous devons nous rappeler que d'autres ne peuvent pas suivre notre train de pensée aussi près que nous croyons. Sur le revers, nous devons être disposés à laisser les autres savoir quand nous avons du mal à comprendre un concept avant la conversation passe à la rubrique suivante.
Compte tenu de toutes ces difficultés, je trouve qu'il est un triomphe du génie logiciel qu'un produit comme Windows fonctionne même à tous, étant donné les milliers d'ingénieurs qui ont travaillé au cours des années.
Peut-être parler de tech sera toujours difficile, ou peut-être avec la maturation de la discipline relativement jeune de développement de logiciels, nous allons voir des méthodes plus efficaces de communication développer. La solution réside peut-être dans la technologie elle-même, avec les meilleurs outils de collaboration et plus concentré et évolué de langages de programmation. Si les langages de programmation du futur sont conçus avec une syntaxe claire et intuitive et en finir avec les bagages verbeux reportés de langues primitives, nous pouvons voir code que nous pouvons lire plus rapidement et dont la signification est plus facilement absorbée. Peut-être que partie de la solution réside dans la plus récentes, la meilleure programmation de paradigmes, qui permettront de mieux les explications axées sur l'analogie de programmation orientée-objet même peut maintenant fournir.
Une chose est claire, celui qui crée et adopte ces solutions gagnera un avantage significatif sur ceux qui continuent à errer dans la tempête de sable d'acronymes et de la main en agitant qui caractérisent le génie logiciel aujourd'hui.
Ryder Donahue est un ingénieur développeur de logiciels chez Microsoft. Originaire de Hawaii, il réside maintenant à Redmond, Washington, avec sa fiancée et leur chat, marbres.