[Sondage] Quelles sont les tâches les plus difficiles pour un développeur ?

**Michael Guilloux** · 22/10/2015, 08h23

Quelles sont les tâches les plus difficiles pour un développeur ?
Venez partager vos avis et expériences

On peut définir la programmation informatique comme l'ensemble des activités qui permettent l'écriture des programmes informatiques. La programmation, au sens strict, se résume donc à l’écriture de code source mais se situe au cœur d’une activité plus large qu’est le développement informatique. Cette précision nous permet dès le départ de faire une distinction entre programmeur et développeur.

On pourrait donc définir le développement informatique comme un ensemble d’activités incluant la construction ou la programmation (l’écriture du code dans un langage de programmation bien défini), mais également bien d’autres activités clés. Il s’agit notamment de l’analyse qui recense et documente chaque fonctionnalité, la conception qui consiste à déterminer les solutions techniques qui permettent de satisfaire le cahier des charges, et la recette au cours de laquelle divers contrôles sont effectués avant que le logiciel soit livré.

Toutes ces activités regroupent un certain nombre de tâches qui peuvent être plus ou moins redoutables pour les développeurs, sans parler des problèmes liés au travail en équipe ou avec d’autres métiers. Un sondage réalisé par l'entreprise web Quora, et qui a enregistré plus de 4500 votes, a permis de classer les tâches les plus difficiles pour les programmeurs. Les résultats sont donnés par le graphique suivant :

Dans notre cas, nous nous intéressons au développeur au sens large du terme, c'est-à-dire qui peut jouer le rôle d'analyste par exemple, et bien d'autres rôles qui dans certains cas sont dissociés de son métier : c'est le cas de la rédaction du cahier de charges. Parmi les tâches exécutées par les développeurs et que ces derniers pourraient redouter, nous pouvons donc citer :

Rédiger un cahier de charges ;
Faire l'analyse du projet : recenser et documenter chaque fonctionnalité ;
Concevoir une solution ;
Ecrire les tests ;
Rédiger la documentation ;
Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord ;
Travailler avec le code de quelqu'un d'autre ;
Traiter avec d’autres personnes ;
Estimer le temps nécessaire pour effectuer des tâches ;
Expliquer ce qu'on fait (ou ne fait pas) ;
Nommer correctement les choses.

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 ? Vous avez la possibilité de faire plusieurs choix. N’hésitez pas non plus à les commenter, et préciser d’autres tâches que vous estimez difficiles mais qui ne figurent pas parmi les éléments listés ci-dessus.

Les résultats de l'enquête initiale de Quora ont été publiés sur imgur.com

Voir Aussi

Forum Général Développement

**grunk** · 22/10/2015, 08h52

Estimer un temps est quelque chose de très compliqué pour ma part.
La plus part du temps on nous demande une estimation sans connaitre totalement tous les paramètres et parfois ce qui peux paraître anodin à un non technique peut vite se transformer en jours de travail (surtout que c'est toujours amener au milieu du projet -_- ).

**jopopmk** · 22/10/2015, 09h06

Clairement : estimer le temps de dev, même si reprendre le code d'un autre dev peut poser souci dans certains cas.
Les autres points peuvent au pire faire suer, mais ne sont pas nécessairement "difficiles".

Pour ce qui est de "nommer les choses", si on n'arrive pas à exprimer un problème -et sa solution- de manière claire il y a de forte chance qu'on ait raté un truc.

**shkyo** · 22/10/2015, 09h19

Perso mon triplet gagnant est clairement:
1- Estimer le temps nécessaire (car on a jamais toutes les billes au début...)
2- Bosser avec le code d'un autre (tout le monde est loin d'avoir la même logique et c'est parfois à s'arracher les cheveux!)
3- Rédiger la documentation (on n'a jamais le temps, ni la motivation...)

Pour le reste, ça va à peu près...

**transgohan** · 22/10/2015, 09h24

Pour ma part ce sont deux choses :
- La documentation, je mets toujours un temps fou pour trouver mes mots et rédiger des phrases. Alors même en connaissant parfaitement le sujet j'ai du mal. Et quand en plus il faut que cela soit une documentation accessible à tout un chacun !

- Estimer le temps nécessaire à la réalisation d'une tâche, je fais toujours de l'à peu-près et en deux ans je me suis toujours rendu compte que ce n'était jamais correct. Toujours une demi-journée de moins pour réaliser la tâche, ou bien pire une semaine de plus... Le fait que les tâches ne soient pas entièrement identifiées y est pour quelque chose, mais même avec une tâche clairement décrite je pense que je ne serai pas non plus correct.

**TiranusKBX** · 22/10/2015, 09h29

mon tiercé perso dans l'ordre:

Rédiger la documentation
Estimer les temps de développement
utiliser/modifier le code d'un autre

bon on pourrait aussi mettre "OBTENIR un cahier des charges définitif"

**Sat7121** · 22/10/2015, 09h59

Pour ma part en temps que développeur :

- Difficulté d'expliquer au Chef/Client... que le temps de développement fluctue à plus ou ~~moins~~ quelques jours près car on trouve toujours un manque ou une coquille dans la spécification. Je n'ai jamais trouver une spécification parfaite (Si on est chef/client, on pourrait mettre la difficulté de rédiger une spécification parfaite).

- Difficulté de rédiger la documentation : Vu qu'on perd du temps en développement dû au difficulté, problème rencontré (Voir ci-dessus), on a jamais le temps de la faire.

- On perd aussi du temps de développement dû à la difficulté de reprendre le code d'une autre personne.

Conclusion : Pour un projet les difficultés dépendent surtout de la qualité de l'amont : Cahier des charges, rédaction des spécifications, création de la solution etc...
Si l'amont n'est pas de bonne qualité alors on aura des difficultés à faire le reste.

Le plus dur a réalisé dans un projet est la communication entre les différentes parties : Bien définir son besoin et savoir le communiquer au reste de l'équipe/sous-traitant.
Malheureusement je connais aucun Client/Chef de projet "parfait" permettant d'occulté ces problèmes malgré tous les outils mis en pratique (Agile, UML, etc...).

Je m'excuse pour mes fautes d'orthographe (Je me suis pas relu).

**Gulien** · 22/10/2015, 09h48

Pour moi le plus dur n'est pas dans le sondage :

-Endurer la répétition d 'opérations faites maintes et maintes fois :
Création de classe, de table, d'entité, de DTOs BO, DTOs FO, Formulaires FO ...

Alors que tout ça c'est du vu et revu.

Il n'y a plus que le code métier qui m'amuse (enfin un tant soit peu).

**grunk** · 22/10/2015, 16h06

Envoyé par Gulien

Pour moi le plus dur n'est pas dans le sondage :

-Endurer la répétition d 'opérations faites maintes et maintes fois :
Création de classe, de table, d'entité, de DTOs BO, DTOs FO, Formulaires FO ...

Alors que tout ça c'est du vu et revu.

Il n'y a plus que le code métier qui m'amuse (enfin un tant soit peu).

C'est justement pour se concentrer sur le code métier que les framework sont là en général

**G'Optimus** · 22/10/2015, 11h31

Estimer le temps nécessaire pour effectuer des tâches.

MikeRowSoft · 22/10/2015, 11h46

Envoyé par Michael Guilloux

Rédiger un cahier de charges ;
Rédiger la documentation ;
Mettre en œuvre une fonctionnalité avec laquelle on n'est pas d’accord ;
Travailler avec le code de quelqu'un d'autre ;
Expliquer ce qu'on fait (ou ne fait pas) ;
Nommer correctement les choses.

L'accord que se sont ceux qui ont besoins de savoir quoi faire qui doivent enseigner la méthode pour bien communiquer.

**melka one** · 22/10/2015, 11h51

jour

la tache la plus difficile ? je dirait réfléchir

MikeRowSoft · 22/10/2015, 11h59

Envoyé par melka one

jour

la tache la plus difficile ? je dirait réfléchir

Méthodiquement? Réfléchir (raisonnement) est un principe biologique cérébrale ayant pour départ une inconnue et permettant de bouger une entité pour actionner des trucs avec ou sans méthodes, mais des mécanismes biologiques. Sauf si tu confond avec un miroir.
Le rendre artificiel, c'est le domaine des pros de la recherche et de la recherche dite public, mais pas forcément utile.

Réfléchir sur un projet, je crois que les choses vont s'améliorer.

**melka one** · 22/10/2015, 12h05

j'ai vraiment du mal

MikeRowSoft · 22/10/2015, 12h12

Envoyé par melka one

j'ai vraiment du mal

Non, tend que sa? Il te manque peut-être des expériences de vies humaines.

**Eaques** · 22/10/2015, 12h26

Bonjour,

Si je dois réaliser un tierce :
1. Traiter avec d'autres personnes pour établir le cahier des charges et l'analyse. Pas facile de trouver des personnes compréhensives dans la boite
2. Rédiger la documentation. Essayer d'être le plus compréhensif possible en etant facile à lire. Je tricotes et détricotes pas mal tant que je suis pas satisfait !
3. Travailler avec le code de quelqu'un d'autres. Chacun a sa logique et ses manies

**stalline 12** · 22/10/2015, 13h41

Concevoir une solution

**melka one** · 22/10/2015, 14h04

Non, tend que sa? Il te manque peut-être des expériences de vies humaines.

goulou goulou dans la case ?

**autran** · 22/10/2015, 14h55

Estimer le temps nécessaire :
Je commence par faire l’estimation honnête de mon travail. Ensuite j’applique une surcote de 30% (coefficient de sécurité)

**mister3957** · 24/10/2015, 09h37

Sortant d'une expérience en SSII assez douloureuse, je ne me sens pas assez objectif pour participer à ce débat

Juste que les réponses proposées sont très très limitées, on pourrait rajouter par exemple :

- "Assumer les manques de responsabilités de la hiérarchie"
- "Assumer de coûter un peu plus de 3 pesos"
- "Assumer de jouer avec la merde que le commercial a vendu"
- "Assumer le fait de ne rien pouvoir dire car le client est roi, le commercial rapporte, toi tu coûtes et trop cher pour juste faire joujou avec des ordinateurs"

- Et bien d'autres avant de parler de notre métier de développeur / d'ingénieur qui n'a strictement plus rien à voir dans ce contexte là.