Les développeurs de systèmes d'entreprise ont une mauvaise réputation
Agile, Scrum, mots de fantaisie pour écrire un logiciel qui livre
Quelle que soit la façon dont vous le regardez, en termes généraux, les développeurs de logiciels d'applications d'entreprise ont une mauvaise réputation. Les systèmes sont presque inévitablement livrés en retard ou même pas du tout. L'utilisateur moyen d'une entreprise moyenne passera littéralement des heures chaque semaine à se plaindre des systèmes informatiques qu'il est obligé d'endurer. « Pourquoi est-ce qu'il a fait ça ? », Qu'est-ce que ça veut dire ? » sont quelques-unes des choses que j'entends quotidiennement.
J'ai passé des années à écrire des systèmes d'entreprise, dans la plupart des cas, les utilisateurs étaient positifs sur ce qu'ils obtenaient et utilisaient. Des systèmes écrits selon une spécification initiale, testés jusqu'à la mort, puis adaptés au fur et à mesure des besoins à un coût convenu si nécessaire. Un soutien continu pour le client et des revenus soutenus pour l'éditeur de logiciels étaient une combinaison gagnante. La spécification initiale basée sur une analyse détaillée des exigences serait toujours une vue d'ensemble fonctionnelle et ne contiendrait aucune spécificité de code, je pense avoir utilisé un pseudo-code une fois (lorsque j'écrivais des jeux). "C'est ce dont nous avons besoin qu'il fasse", était généralement assez bon pour moi. En dehors de cela, il y avait quelques maquettes d'interface utilisateur et beaucoup de conception de base de données et c'est parti. La phase de test et de « peaufinage » du cycle de vie du développement était très importante. Les systèmes ont généralement été livrés à temps et ont fonctionné.
De nos jours (je n'aurais jamais pensé dire ça), tout ce qui concerne les systèmes est une question de planification, de planification supplémentaire et de réutilisabilité. Ce qui me semble si étranger, c'est qu'une grande partie de cette planification ne vise pas à répondre à une exigence fonctionnelle, mais plutôt à détailler comment et pourquoi nous allons écrire ce que nous écrivons lorsque nous l'écrivons. J'espère que cela a du sens? Pourquoi écrire quelque chose en 10 lignes que vous pourriez faire en 1000 au cas où vous "pourriez" avoir besoin de le réutiliser 2 ans plus tard ? Sur le plan personnel je n'ai jamais rien écrit que je ne puisse mieux réécrire 2 ans plus tard. J'apprends et je m'améliore toujours, quand je repense au code, même à 12 mois, je grince souvent des dents. En regardant les offres d'emploi, il est facile de se perdre dans les méthodologies et les compétences demandées, est-il humainement possible pour une personne d'en savoir autant que je me demande souvent ? Une autre question est-ils jamais produire un produit ? Avec toute cette planification et cette inquiétude concernant la réutilisation du code, est-ce que quelque chose est jamais fait ? Je connais une entreprise qui a embauché des développeurs universitaires qui étaient tellement occupés à se concentrer sur la conception qu'elle a fait faillite avant même qu'aucun produit ne soit prêt, sérieusement ! Combien de retards pouvons-nous nous attendre à ce que les gens tolèrent, la phase de test n'a jamais été un problème là-bas ! Pourquoi l'entreprise qui nous paie pour un produit devrait-elle payer pour du code qui sera utilisé encore et encore dans des projets ultérieurs qui ne lui sont pas destinés ?
Ne vous méprenez pas, je ne dis pas que la planification est mauvaise, c'est une partie essentielle du développement des systèmes, mais ce n'est pas la seule partie. Peut-être que je suis de la vieille école, mais ce que j'aime, c'est en fait écrire le système et le faire fonctionner. Ok, je sais que les systèmes deviennent de plus en plus gros et complexes tout le temps. Les grandes équipes de développeurs sont la norme. C'est juste que je pense que peu importe à quel point vous planifiez, visualisez et faites un remue-méninges, quelque chose vous manquera toujours. Nous nous efforçons d'obtenir des systèmes impossibles et parfaits, mais dans le pire des cas, nous ne fournissons en fait aucun système. Vous ne me croyez pas ? Regardez Microsoft. Imaginez les heures de travail consacrées à la planification de l'une de leurs applications ? À quelle fréquence un nouveau bogue ou une nouvelle vulnérabilité est-il découvert ? Pourquoi n'ont-ils pas été débattus au stade de la conception ? Il n'a même jamais traversé l'esprit de l'équipe de développement que la "vulnérabilité X" pourrait même se produire. En termes simples, avec quelque chose de plus que les systèmes les plus élémentaires, il est presque impossible de planifier toutes les éventualités, quelle que soit votre logique. Comment se fait-il qu'ils ne soient pas trouvés lors des tests ? La solution est-elle ici le développement à l'ancienne, moins de temps à planifier (parler), plus de temps à écrire et à tester ? Moins de temps à vous soucier de la réutilisation du code, plus de temps à donner au client et au client un produit fonctionnel ? Est-ce que Microsoft serait meilleur ou pire s'il passait moins de temps à planifier et plus de temps à tester ? Pour la défense de Microsoft, ils sont très doués pour les correctifs, je suppose qu'ils pourraient être considérés comme nous utilisant comme testeurs. Peut-être que s'ils passaient plus de temps à faire des tests appropriés, nous n'aurions pas besoin de tester pour eux ?
Le pire exemple de planification excessive que je n'ai pas encore rencontré est un système financier que j'utilise quotidiennement. Ce système a coûté des millions de dollars à mettre en place, des années de planification et qui sait combien de consultants. Il est écrit par l'un des plus grands acteurs de l'industrie du logiciel, adapté par un cabinet de conseil spécialisé en logiciels. Le résultat final de ceci est un système qui est pratiquement inutilisable et pas trop loin d'être remplacé par un produit de l'étagère. C'est tellement mauvais au niveau le plus bas que même un clic de souris mal placé bloquera l'application. Je ne peux pas croire que ce système ait jamais été testé avant la remise. Il a été livré très tard tel qu'il était, la raison étant un «cycle de planification» plus long que prévu. Ce qu'il fait n'est pas si complexe, c'est juste qu'il a manifestement été planifié au point où la mise en œuvre a été précipitée après réflexion. Toute cette planification n'a même pas abouti à un système qui répondrait aux exigences fonctionnelles de base de ses utilisateurs, mais bon, je suis sûr qu'ils réutiliseront ce code quelque part sur la ligne.
Quoi qu'il en soit, je viens de commencer un diplôme pour m'aider à comprendre pourquoi il est si important d'utiliser plusieurs stratégies de planification différentes. Pourquoi écrire en 1 jour ce que je pourrais passer un mois à faire « correctement » ? Je sais que je relirai ceci dans quelques années et que je me demanderai à quoi je pensais; soit ça, soit je me dis « wow, c'est là que je terminais vraiment ce que j'écrivais ». Sérieusement, je suis sûr qu'à la fin, je comprendrai où je me trompe, en attendant, je continuerai à écrire des applications en utilisant mon style RAD (je suis content qu'il ait un nom !) qui bien que n'étant pas au goût de tout le monde, fonctionne très bien pour moi.
nb Qui l'aurait deviné mon approche du développement a un nom, c'est classé comme Méthodologie Agile ! Voici un excellent article qui explique Méthodologies Agiles dans certains détails.