La création de nouveaux logiciels est-elle généralement une partie importante de la plupart des emplois de programmation?
Je travaille dans le développement de logiciels depuis plus de 10 ans maintenant, et il me vient à l'esprit que j'ai rarement la possibilité de créer quelque chose de "nouveau". Je me rends compte que "nouveau" est un terme vague, mais je le définirais comme allant d'un nouveau projet à grande échelle évident à une nouvelle fonctionnalité de grande taille dans un projet existant (disons quelque chose qui nécessiterait une certaine réflexion dans sa conception, et qui pourrait prendre 2 semaines ou plus pour terminer). Peut-être qu'une directive approximative est quelque chose de nouveau si elle nécessite une spécification écrite. Je pense que la plupart des programmeurs savent de quoi je parle - vous êtes dans la zone, écrivant une tonne de code à un rythme rapide.
Quoi qu'il en soit, en repensant à ce que j'ai fait, j'estimerais que moins de 10% de mon temps est consacré à de "nouveaux" travaux. Il y a des choses comme "adapter ce système existant pour fonctionner dans ce nouvel environnement", ce qui nécessite certainement beaucoup de planification, mais le codage réel et les "nouvelles choses" se résument à faire de minuscules changements à de nombreux endroits dans le code. De même pour les petites demandes de fonctionnalités - si je sais quoi faire, celles-ci peuvent souvent être terminées en moins d'une heure, et si je ne le fais pas, c'est juste beaucoup de lecture de code et de détermination de ce qu'il faut faire (ce qui me frustre parce que j'apprends beaucoup mieux en faisant, pas en lisant).
En général, j'ai l'impression de ne rien créer la plupart du temps. J'ai en quelque sorte supposé que c'était le cas dans la plupart des endroits - un nouveau produit sortirait assez rapidement et à ce moment-là tout le monde serait excité et frapperait le code à un rythme rapide, mais une fois en direct, il passerait en mode maintenance, où quelques-uns des changements ultérieurs seraient considérés comme "nouveaux et créatifs".
Ai-je tort? Suis-je en train de décrire avec précision la plupart des tâches de programmation ou la plupart des programmeurs ont-ils l'impression de créer souvent de nouvelles choses?
Une grande partie du travail logiciel est la maintenance. Aucun responsable du recrutement ne vous le dira, bien sûr, mais c'est certainement le cas.
Oui, votre perception est exacte. C'est un truisme absolu que beaucoup plus de temps, d'argent et d'efforts sont consacrés à la maintenance des systèmes qu'à la création de nouveaux systèmes. Donc, évidemment, l'allocation de temps de la plupart des programmeurs va refléter cela.
Cela s'explique en partie par le fait que beaucoup de gens, lorsqu'ils arrivent à faire du "nouveau et créatif", le font mal, de sorte que la maintenance du système est difficile (cela est particulièrement probable s'ils n'ont jamais fait de maintenance eux-mêmes - personne qui a constamment travaillé sur de petits projets entièrement nouveaux ne peut vraiment prétendre être compétent).
Une autre raison (probablement plus importante) est que la plupart des systèmes sont conçus pour être continuellement utiles, pas seulement pour un événement ponctuel. Ils continuent donc à s'habituer beaucoup plus longtemps qu'il n'en a fallu pour les développer. Mais pendant ce temps, les exigences changent (et s'ajoutent) en raison de changements dans la législation, sur le marché, dans la recherche, chez les utilisateurs, peu importe. Et cela signifie des travaux de maintenance.
Les systèmes hérités sont ceux qui réussissent. Ils ont survécu au processus de développement initial où 50% des projets échouent (même après que le succès a été redéfini!). Ils ont survécu à un environnement commercial en mutation. Ils ont probablement survécu à une dizaine de propositions de jeunes programmeurs naïfs de réécrire le tout en Java ou tout ce qui était à la mode à l'époque. Ils ont eu la chance que quel que soit le département, l'entreprise ou l'agence que le logiciel servait a survécu aux diverses coupes budgétaires, réorganisations, fusions, etc.
Probablement moins de 5% des logiciels écrits fonctionneront encore dix ans plus tard.
Donc, plutôt que de gémir à ce sujet, voyez-vous comme un privilège de travailler sur une telle réussite darwinienne et une opportunité d'apprendre ce qui fonctionne dans le monde réel et pourquoi.
Le terme qui est souvent utilisé pour les nouveaux projets qui ne dépendent pas d'un développement plus ancien est projet greenfield. Vous pouvez parfois voir le terme dans les listes d'emplois - sachant que vous pouvez recommencer à zéro plutôt que d'hériter de l'échec de quelqu'un d'autre peut rendre un travail plus attrayant.
Les projets logiciels réussis passent généralement beaucoup plus de temps à être entretenus qu'à construire en tant que nouveaux projets, il n'est donc pas du tout surprenant que vous n'ayez pas à faire beaucoup de choses complètement "nouvelles".
De plus, créer quelque chose complètement nouveau est un lot de travail. Même sur un projet entièrement nouveau, vous choisirez probablement un certain nombre d'outils pour vous aider: plateforme, compilateur, frameworks, bibliothèques, etc. Dès que vous faites ces choix, vous avez imposé certaines contraintes à votre projet. Cela ne veut pas dire que vous ne faites plus de nouveaux travaux, seulement que "nouveau" est un terme relatif ici. Ce n'est pas un grand pas à partir de là pour voir l'ajout d'une fonctionnalité ou d'un module à un projet existant comme "nouveau" même si vous ne l'appeleriez pas un projet greenfield.
Cela dépend du travail que vous recherchez.
Je n'ai travaillé qu'une seule fois pour une société de produits logiciels purs où j'ai travaillé sur leur seule application plaquée or dans une petite équipe de démarrage.
Sinon, j'ai travaillé pour des entreprises technologiques qui avaient besoin de logiciels pour prendre en charge leur R&D interne ou leurs produits externes.
L'avantage est que je peux construire des produits complets de début à fin et construire à peu près ce que je veux. Parfois, vous pouvez également essayer des technologies plus récentes que si vous étiez bloqué en ajoutant des fonctionnalités à une application leader du marché existante.
L'inconvénient est que vous faites partie du coût, pas du produit. J'ai donc eu des projets en conserve parce que "nous ne faisons pas de logiciel"/"le logiciel n'est pas le cœur de métier" = c'est incroyable de voir comment les entreprises pensent qu'elles peuvent vendre une machine-outil de 100 K $ sans logiciel pour l'exploiter!
Plutôt que de voir le code hérité comme un nettoyage continu du gâchis de quelqu'un d'autre, regardez-le comme une opportunité de travailler sur de nombreux nouveaux projets.
Pensez-y, chaque nouvelle fonctionnalité ajoutée à un système est un petit projet en soi. Vous devez toujours appliquer l'intégralité du SDLC afin de vous assurer que vous avez terminé le travail correctement. Bien sûr, on vous donne probablement une spécification pour la fonctionnalité, mais généralement les petits détails ont été laissés, il vous appartient donc d'analyser le problème comme indiqué, de concevoir la meilleure méthode pour appliquer le changement, le tester, le coder, puis relâchez-le sur votre système de contrôle de version et maintenez-le très probablement à l'avenir.
D'après mon expérience, vous ne travaillez pas souvent dans un domaine complètement vert, et souvent lorsque vous avez la chance de le faire, vous serez censé voir le projet à travers une bonne partie de sa maintenance et peut-être même pour la durée de vie du produit ou pendant toute la durée de votre séjour avec un employeur donné. En effet, votre expérience intime avec un produit signifie que vous devenez un référentiel de connaissances, et il peut être considéré comme coûteux de vous déplacer vers d'autres choses. Lorsque vous démarrez sur un produit existant, c'est parce que l'employeur a récemment perdu une ressource ou a besoin de plus de ressources sur le projet, et l'entreprise doit s'assurer qu'il ne fait pas une trop grande perte sur l'investissement qu'il a fait dans son logiciel. . C'est la réalité d'être un ingénieur logiciel.
Je travaille dans l'informatique depuis près de 22 ans, dont les 15 dernières en tant que développeur de logiciels, et pendant tout ce temps, je n'ai créé que 5 nouveaux produits, la plupart de mon temps soit pour maintenir ces produits à long terme, soit pour ceux de quelqu'un d'autre. produit. Chacun m'a donné des défis et des problèmes à résoudre, et chacun a été traité non seulement comme un grand projet dont je fais simplement partie, mais aussi comme une ENORME série de micro-projets à réaliser.
C'est incroyable de voir comment une petite gymnastique mentale peut totalement changer votre perception et votre plaisir du travail quotidien que vous faites. ;-)
Je pense que de nombreux emplois de développement logiciel impliquent l'amélioration d'un produit existant ou l'adaptation du code existant à un nouveau client ou marché.
Ce n'est pas vraiment de la "maintenance". Par exemple, VMWare vient de publier la version 8, c'est une mise à niveau majeure de leur produit principal. Je soupçonne que peu de développeurs qui ont fait ce travail étaient là lorsque la première ligne de code pour VMWare a été écrite. Ils ont construit leur mise à niveau majeure sur le code écrit par des gars qui ont depuis longtemps évolué.
Je suis sûr que Google a compris que les meilleurs développeurs veulent être présents lors de la création de nouveaux produits logiciels et se lasseront éventuellement d'années d'années à ajouter de petites fonctionnalités et à peaufiner les interfaces graphiques pour la prochaine version.
En ayant les projets à 20%, je spécule que le développeur de Google ne voudra pas rester pour améliorer les projets de Google, car il peut toujours avoir le plaisir d'être là au début de quelque chose de nouveau.
Je dirais que cela dépend de l'entreprise pour laquelle vous travaillez.
Mon premier travail a été une société de logiciels de comptabilité dont le produit principal était un système ERP, en concurrence à peu près au même niveau que Great Plains ou Peachtree (comme vous l'avez fait depuis QuickBooks ou latéralement lorsque vous vous êtes fatigué du schéma obscurci de GP ou de tout ce que vous pensiez être incorrect avec PT, puis vous avez complètement quitté le niveau dans un package comme SAP). sans changer fondamentalement la façon dont le logiciel fonctionnait ou ce qu'il pouvait faire. J'ai quitté l'entreprise lorsque le PDG voulait faire une réécriture page un du système, ce qui aurait été cool, sauf qu'il a insisté sur plusieurs fonctionnalités de conception qui sont clairement anti- des modèles, tels que la plate-forme interne (permettant un degré élevé de personnalisation du programme en offrant au client un VS Designer simplifié et en personnalisant les règles métier en fournissant un langage d'expression).
Mon prochain travail après cela était une entreprise sous contrat qui faisait du "développement clé en main"; le système spécifié par le client a été construit à partir de zéro, matériel et logiciel, puis à la fin du projet, il a été remis au client qui pouvait soit le maintenir lui-même, soit retenir les services de l'entreprise moyennant des frais mensuels. Mon travail consistait à développer l'un de ces projets majeurs, et donc pendant que j'y travaillais, presque tout ce que j'avais fait n'existait pas avant de commencer. Même alors, le développement est intrinsèquement itératif; vous ajoutez toujours à ce que vous avez déjà (même si ce que vous avez n'est rien), et vous devez éviter et résoudre les problèmes de régression (de nouveaux trucs qui cassent des trucs anciens). Et une fois que le projet est passé au statut de "garantie", de nouvelles fonctionnalités étaient terminées et nous devions corriger tous les défauts détectés par le client au cours de leur UAT.
Mon travail actuel est de retour au développement interne, pour une entreprise de sécurité qui utilise la surveillance vidéo et le retour audio pour fournir une vérification du signal d'alarme et d'autres services de "garde virtuelle". Ce domaine se développe rapidement et continue de se développer; de nouveaux équipements entrent en permanence sur le marché, de nouveaux clients sont inscrits qui veulent que nous fassions de nouvelles choses, et les produits existants ne répondent plus aux normes UL et gouvernementales en vigueur. 99% de ce travail est "intégration"; écrire de nouveaux logiciels qui n'existaient pas auparavant, pour faire fonctionner un équipement ou un logiciel nouveau mais préexistant avec un autre équipement ou logiciel préexistant probablement plus ancien, afin que nous puissions faire de nouvelles choses avec les deux.
Vous passerez votre temps à créer de nouvelles fonctionnalités et à modifier les fonctionnalités du code existant afin de vous conformer à la nouvelle spécification.
D'autres appellent cela l'entretien, mais c'est un terme horrible. C'est une refonte et une refactorisation ou recodage du logiciel pour le rendre conforme à une nouvelle idée de ce que le programme devrait faire.
Je dirais que cela dépend beaucoup de la nature de votre rôle.
Je fais partie d'une petite équipe et en tant que telle, je dois maintenir et soutenir tout ce que je crée.
Il y a 5 ans, la plupart de mes activités étaient "nouvelles" - je dirais maintenant que la maintenance du code existant prend au moins la moitié de mon temps, 25% étant des "nouvelles" versions de systèmes existants.
Mais si vous travailliez uniquement en tant que développeur avec une équipe pour prendre en charge la maintenance et le support après avoir publié votre code, alors techniquement, tout serait "nouveau". Si vous pouvez trouver un travail où la maintenance de votre propre code n'est pas nécessaire, prenez-le!
Cela dépend du danger que représente votre poste: ;-)
Si vous travaillez pour une nouvelle entreprise qui développe de nouveaux produits avec un risque élevé de survie, vous créez probablement d'excellents nouveaux produits.
Si vous travaillez pour une ancienne entreprise qui a une position stable sur le marché, il est plus probable que vous codiez en mode maintenance ;-).
La création de nouveaux logiciels est toujours très tentante. La vérité, il est difficile de le faire d'une manière à droite. Faire du code maintenable n'est pas une tâche triviale.
Si vous pensez à ces tonnes d'aspects, vous devez vous assurer d'écrire du bon code: une bonne journalisation, une surveillance appropriée et l'acquisition de statistiques, une conception descriptive efficace et qui aide même des personnes peu familières à s'impliquer dans votre projet, la documentation, les tests automatiques et les développements pilotés par les tests.
Peu de gens le font correctement, nous devons donc maintenir leur code et le polir à l'état approprié. ;-)
La bonne nouvelle est que si vous êtes dans l'entreprise assez longtemps, vous pouvez avoir une influence sur la façon dont le nouveau code est écrit :-)
Que vous effectuiez principalement la maintenance ou non est au moins partiellement sous votre contrôle. Dans mon cas, la plupart de mon travail au cours des 15 dernières années a été un nouveau développement. C'est parce que je recherche des emplois qui me permettent de faire de nouveaux développements. Je ne suis pas un entrepreneur et je ne fais généralement pas de développement web. J'ai presque toujours travaillé pour de petits employeurs et je travaille habituellement dans des domaines de niche (développement d'interfaces de bureau, outils d'assurance qualité, outils de développement, marchés verticaux).
J'ai également vu et expérimenté de première main que les meilleurs programmeurs d'une équipe obtiennent généralement (mais pas toujours) les meilleurs emplois. Alors, concentrez-vous sur le fait d'être le meilleur programmeur de votre entreprise et vous commencerez à voir de nouveaux développements arriver.
Le développement de la maintenance est une tâche difficile, plus difficile à bien des égards qu'un nouveau développement. D'après mon expérience, les employeurs aiment garder un développeur en maintenance, surtout s'ils sont bons dans ce domaine. Trouver de bons développeurs de maintenance dans les technologies héritées est plus difficile que de trouver quelqu'un qui peut travailler avec les dernières technologies.
J'ai travaillé dans une entreprise divisée en une équipe produit, qui était entièrement chargée de la maintenance, et une équipe projet, qui était entièrement nouvelle. Il y avait de grands développeurs des deux côtés, mais les gars de la maintenance étaient certainement plus spécialisés et utilisaient la technologie héritée.
Puis-je vous suggérer de reculer et de demander de nouveaux travaux de développement? Et si votre employeur s'occupe uniquement de l'entretien, vous devrez peut-être continuer?
Je dirais que cela dépend de beaucoup de facteurs. Où travaillez-vous, quel type de produits fabriquez-vous, comment votre équipe est-elle organisée, etc.
Les quatre années que j'ai travaillé dans mon entreprise, je dirais que 70 à 80% de mon temps est consacré à créer quelque chose de nouveau. Probablement 50 à 60% de cette somme est consacrée à de grands projets entièrement nouveaux, tandis que le reste de ce temps est consacré à l'amélioration des fonctionnalités actuelles.
Je sais en partie comment fonctionne mon entreprise. Tout le monde dans mon équipe de développement ne passe pas autant de temps à créer de nouvelles fonctionnalités. Il y en a un certain nombre qui concentrent leur temps sur rien d'autre que la correction/la chasse aux bogues. S'il s'agit d'une toute nouvelle fonctionnalité ou si ils ont besoin d'aide, cela me sera envoyé pour enquêter. En général cependant, cette petite équipe de chasseurs de bogues est ce qui permet au plus grand groupe de développeurs de continuer sans interruption.
Je travaille depuis près de trois ans en tant que seul développeur dans une entreprise qui utilisait QuickBooks et Excel et rien d'autre lorsque j'ai commencé. Nous avons maintenant une application Windows Forms , une configuration SharePoint , SQL Server + Reports, un complément Excel et un complément Outlook.
Juste aujourd'hui , j'ai mis en place pour la première fois un système de billetterie car j'ai perdu la possibilité de gérer les demandes par e-mail à un rythme qui empêchait les utilisateurs de se plaindre, donc j'ai afficher ceci est un signe que je suis entré en mode maintenance.
Mes emplois précédents ressemblaient plus à ce que les autres ont postés, mais je pensais que je mettrais mon expérience atypique juste parce que cela montre que vous ne savez jamais ce que le prochain emploi apportera. Je suis épuisé, mais le montant que j'ai appris sur ce travail en valait la peine.
Certaines grandes organisations comme la société pour laquelle je travaille ont une politique de mise hors service des logiciels après un certain nombre d'années, peut-être parce que le langage de développement dans lequel il a été écrit n'est plus utilisé (Delphi n'importe qui?), Ou la plate-forme est remplacée (Windows XP) , ou les exigences réglementaires l'exigent. Par exemple. les programmes à deux niveaux qui communiquent directement avec une base de données sont désormais mis hors service au profit de trois niveaux qui utilisent des connexions Kerberized pour plus de sécurité.
Les utilisateurs ont toujours besoin de cette fonctionnalité originale, et donc une toute nouvelle version utilisant les techniques de pointe actuelles est développée.
Attendez-vous à un cycle de remplacement de 5 à 7 ans pour ce type de chose. Par exemple, d'ici 2020, je m'attends à ce que le logiciel WPF (client)/Java (serveur) que j'écris maintenant soit une ancienne technologie et soit remplacé par quelque chose de plus récent.