Discussion :

[didier.cabale]

En ce qui vous concerne en tant que développeurs, quelles sont parmi les tâches citées ci-dessus, celles que vous estimez les plus difficiles dans votre métier ?

1. Concevoir une solution: même si ce n'est pas le point qui est dans 100% des cas le plus difficile, c'est *le point crucial*. De la solution envisagée dépendra toute la chaine des problématiques dépendantes: simplicité de mise en œuvre des tests, facilité de maintenance (modification du code, débogage), etc ..
Ce point nécessite à la fois une très bonne connaissance du Framework, des librairies potentielles et du métier en question.
Si vous travaillez sur un gros projet, avec une maintenance active, les *économies résultant de ce point peuvent être considérables*.
2. Travailler avec le code de quelqu'un d'autre : ça, c'est la *bouteille à l'encre* du développement informatique. Si le code précédemment réalisé est mal découpé, pléthorique et /ou inutilement complexe, vous *vivrez l'enfer*, sans pour autant pouvoir modifier structurellement l'existant, sous peine de créer une kyrielle d'effets indésirables, bugs, ..

[Kiloastein]

Estimer le temps nécessaire

[mumen]

1. Nommer correctement les choses.
2. Nommer correctement les choses.
3. Nommer correctement les choses.

Je plaisante à peine, selon moi, la tâche dont découlent toutes les autres, c'est de nommer tout, les entités, les procédures, les modules, les requêtes, etc. Il faut être capable de revenir sur un nommage - capable veut dire : comprendre les conséquences et avoir les outils. Quand on nomme mal, on se dit "ceci veut dire cela qui n'a pas vraiment de nom pour moi, je m'en rappellerai", mais cela ne marche jamais, on oublie et on galère à retrouver, on désagrège de la puissance de travail pour le vrai travail du jour. Le travail d'analyse en clientèle est parfois une torture pour l'esprit (du client, oups), mais en programmation, comme partout ailleurs, en science, en philosophie, etc., le nommage correct est la fondation, le socle de toute construction.

Je comprends donc très bien les 50% du camembert à ce sujet.

[BugFactory]

Intéressant, le sondage de Developpez.com n'obtient pas du tout les mêmes résultats que celui de Quora. Je me demande pourquoi?

[tchize_]

Toutes les decisions de groupe.

Déterminer le resto où aller à midi
Déterminer la dose de café a mettre dans le filtre de la cafetière
Retrouver la tablette de test
Nettoyer les tables après le lunch
Vider le lave vaisselle

[Invité]

Les choses les plus difficiles pour moi en tant que programmeur pour moi c'est travailler sur un projet déjà fait et surtout vérifier les bugs du projet déjà entamé. Mais c'est vrai que respecté les délais c'est la chose le plus délicate.

[Kaamui]

La tache la plus compliquée pour un développeur en France c'est de se faire payer correctement pour son travail.

[midonet7]

Pour moi, c'est l'estimation du temps nécessaire pour effectuer les tâches, c'est pour cette raison il faut penser toujours à faire des macro-chiffrages des tâches avant de communiquer officiellement l'estimation finale au client.

Cordialement,

[Gunny]

Je suis content qu'il y ait l'option "Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord" parce que je trouve ça vraiment frustrant. Quand ça touche vraiment à la technique ça ne me dérange pas, parfois je ne suis pas forcément d'accord avec la solution de l'architecte ou de mes collègues devs, et à ce moment là on discute, et même si ma solution n'est pas retenue et bien ce n'est pas dramatique : au moins on en a parlé. Par contre, quand vient "d'en haut" une demande clairement contre-productive, stupide, ou myope, et que toute discussion sur le sujet est impossible, bref quand on m'impose de faire ce qui serait considéré par n'importe quel professionnel comme du mauvais travail, j'ai un peu de mal.

[tp1024]

Je pense qu'il manque un choix:

* Obtenir toutes les informations utiles pour concevoir la solutions technique et/ou réaliser le chiffrage.

De mon expérience, le pb ne concerne pas le client, mais les relais entre le client et l'équipe technique.

[IronBibs]

Pour ma part:
- Estimer le temps nécessaire pour effectuer des tâches
- Expliquer ce qu'on fait (ou ne fait pas)

L'estimation du temps nécessaire est un classique contre lequel on se heurte beaucoup, surtout en début de carrière où l'on est souvent plein de bonne volonté, on veut absolument bien faire et dans un temps donné court, et un peu trop naïf car on ne voit souvent qu'une partie de l'iceberg quand on s'interroge sur la charge de travail.
Je suis assez content de voir que l'option "Expliquer ce qu'on fait". C'est bien plus complexe pour moi d'expliquer par des mots ce que je fais de manière naturelle en codant. Surtout quand on est pris à froid et qu'on ajuster son discours à quelqu'un d'externe au projet. A mes yeux, c'est bien plus difficile à faire que de la documentation par exemple.

[Guikingone]

Personnellement je pense que bosser sur le code de quelqu'un d'autre et définir un délai de livraison précis et chose ardue, durant le développement tout peut se passer à merveille et le temps estimé peut se raccourcir mais si les choses se compliquent, on perd du temps pour rien et les soucis relatif au fait de bosser sur le code de quelqu'un d'autre arrivent durant cette phase.

Rédiger une documentation ? Oui aussi, cela prend du temps pour pas grand chose parfois mais il faut y passer.

Je pense aussi au fait de versionner son code, tout le monde n'y pense pas forcément mais cela prend du temps en fin de compte si on compte les heures passés à coder suivi des heures passées à signaler ce que l'on a fait, les changements de branches, les ajouts, les suppressions, c'est peu pratique au final si on y pense et cela prend du temps qui pourrait être utilisé de façon plus utile.

[nirgal76]

La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant

[mister3957]

La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant

Mais une fois en qualif il devient subitement très très très précis sur les exigences.

[Mat.M]

bonjour les tâches les plus difficiles essentiellement pour un développeur c'est de

comprendre précisément le métier du client dans le service informatique
si vous travaillez dans la banque il faut comprendre un minimum les métiers de la banque.

pouvoir conceptualiser , aller dans l'abstraction...avoir une vision globale d'un projet...

de ce qui est indiqué précédemment analyser un problème complexe et le décomposer en problèmes simples donc découper en modules.
reprendre le code de quelqu'un d'autre surtout s'il y a des tonnes de copier-coller avec du code redondant et aucun refactoring.

ce qui quelque part rejoint les avis précédents.
Etant donné que "ce qui se conçoit aisément s'énonce clairement" effectivement nommer ce que l'on fait peut être difficile je ne suis pas étonné par les résultats du graphique

Et si on inclut les 16% de "Expliquer ce qu'on fait", ça pourrait vouloir dire que 65% des développeurs ne savent pas ce qu'ils font et n'en n'ont même pas conscience.

des projets que l'on est pas capable d'expliquer j'ai déjà participé à ce genre de projets..
à la base le projet est mal défini, n'a pas de fonctionnalités pertinentes et c'est pour satisfaire les ambitions d'un DSI

[Franck.H]

Pour ma part, c'est surtout travailler avec le code d'autres développeurs, surtout dans mon cas, celui de mes prédécesseurs qui ont codé un peu comme des cochons

• Code pas clair et peu mis en forme
• Aucune documentation sur le code et les schémas de données

Il n'y a pas pire pour perdre un temps énorme pour faire des choses simples.

[psychadelic]

Je pense qu'il manque un choix:
* Obtenir toutes les informations utiles pour concevoir la solutions technique et/ou réaliser le chiffrage.
De mon expérience, le pb ne concerne pas le client, mais les relais entre le client et l'équipe technique.

La chose la plus difficile que j'ai à faire pratiquement tous les jours, c'est savoir précisément ce qu'il faut faire. LA demande client se résume bien souvent à "j'voudrais un machin qui fait des trucs...combien de temps il te faut ?"...c'est lassant

C'est pour ça que j'ai répondu : " Traiter avec d’autres personnes ".

Parce que pour rédiger un bon cahier des charges on est obligé d'interviewer des gens qui souvent ne savent même pas ce que peut être un raisonnement cartésien; voire qui croient toujours que la terre plate (si, si, c'est du vécu).

Et tout le reste en découle :
- Recenser et documenter les fonctionnalités devient une chasse aux œuf de Paques
- Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord complétement inutile(s)

Quand à estimer le temps, c'est souvent une question piège, mais avec l'expérience (non pas du métier ou de moi même) mais des sournoiseries des "dirigeants" je sais quoi répondre, et par une autre question :

Vous voulez quoi ?
Le temps de réalisation avec ou sans la documentation ? , avec ou sans les tests et les retours utilisateurs ? avec ou sans relecture du code et de ses commentaires par un autre dev ?

Ps on a souvent essayé de me la faire, et ça me fait tout sauf rire : 15 jours hommes c'est pas 2 semaines, mais 3 semaines, sinon faut payer en heures sup et salaire au double pendant les week-end.

Quand à relire le code d'un autre, ça dépends surtout de la qualité d'écriture du premier codeur, parfois c'est un plaisir, mais c'est rare...

[Cincinnatus]

bonjour les tâches les plus difficiles essentiellement pour un développeur c'est de

comprendre précisément le métier du client dans le service informatique
si vous travaillez dans la banque il faut comprendre un minimum les métiers de la banque.

pouvoir conceptualiser , aller dans l'abstraction...avoir une vision globale d'un projet...

de ce qui est indiqué précédemment analyser un problème complexe et le décomposer en problèmes simples donc découper en modules.
reprendre le code de quelqu'un d'autre surtout s'il y a des tonnes de copier-coller avec du code redondant et aucun refactoring.

ce qui quelque part rejoint les avis précédents.
Etant donné que "ce qui se conçoit aisément s'énonce clairement" effectivement nommer ce que l'on fait peut être difficile je ne suis pas étonné par les résultats du graphique


des projets que l'on est pas capable d'expliquer j'ai déjà participé à ce genre de projets..
à la base le projet est mal défini, n'a pas de fonctionnalités pertinentes et c'est pour satisfaire les ambitions d'un DSI

Pour moi les éléments que tu listes font partie du boulot de développeur, en ce qui me concerne j'aime bien certains (conceptualiser, découper en modules...) et il vaut mieux comprendre le métier du client (ça peut être plus ou moins difficile selon ce métier et sa propre expérience). Il ne s'agirait donc pas (pour moi) de tâches difficiles mais importantes.

Quant à reprendre du code pourri, malheureusement ça existe. Le mieux étant de réécrire et virer ce code.

[Cincinnatus]

• Rédiger un cahier des charges
• Estimer le temps nécessaire pour effectuer des tâches
• Expliquer ce qu'on fait (ou ne fait pas)

Il arrive que les fonctionnalités demandées soient vagues ; alors le temps nécesssaire ne peut pas être estimé au début de façon fiable. Après tout, les méthodes agiles ont été créées suite à ce constat.
Expliquer ce que l'on fait à quelqu'un qui n'est pas de la partie est assez compliqué aussi (la compréhension du message dépend de l'émetteur mais aussi du destinataire, qui a peut-être des idées préconçues). Pire : expliquer les développements actuels à quelqu'un qui a fait du développement (pas à temps complet) il y a un certain temps et qui n'a pas suivi les évolutions (évolution hiérarchique) mais croit connaître .

[el_slapper]

(.../...)
Quant à reprendre du code pourri, malheureusement ça existe. Le mieux étant de réécrire et virer ce code.

souvent, le budget n'est pas en face. Ça nécessite des tests automatiques de partout, et tout le monde ne les a pas. Quand on m'a demandé de le faire, j'ai du d'abord faire tous les tests automatiques avant d'arriver à quelque chose.