Les bénéfices du développement logiciel “Model-First”

avril 19, 2013 Poster un commentaire

Livre blanc CodeFluent Entities – Version 4.0 – Avril 2013

SoftFluent-ModelFirst-WhitePaper_FR

L’objectif de ce livre blanc est de décrire le défi que représente le développement logiciel, clarifier les causes.

 

La première partie du document explique les grands enjeux de ce marché et pourquoi c’est un problème économique difficile. Cette partie est largement applicable par toute personne intéressée par le développement logiciel indépendamment de notre offre.

 

La seconde partie de ce document expose la solution que nous avons élaborée pour répondre structurellement à ce défi à l’aide l’approche ‘Model-First’ de CodeFluent Entities.
Lire le livre blanc CodeFluent Entities

En savoir plus sur CodeFluent Entities

Classé dans Actualités, CodeFluent Entities, Développement .NET Tag(s) associé(s) : , , , , , , , ,

.NET ou Java : comment choisir ?

mars 29, 2013 Poster un commentaire

J’ai souvent vu cette question sur des forums et/ou des réseaux sociaux, j’ai donc décidé de partager mon point de vue sur le blog officiel de SoftFluent.

Je me présente, de 1992 à 1997, j’ai travaillé pour une société rachetée par IBM. De 1997 à 2005, j’ai travaillé pour Microsoft, en charge de l’évangélisation développeur en France, principalement autour de .NET entre 2001 et 2005. J’ai ensuite créé ma propre société SoftFluent. J’ai souvent conseillé les ISV dans l’évolution de leur stratégie, parfois en dehors de la plateforme Microsoft. J’ai eu à auditer l’organisation du développement de certaines sociétés orientées Java en travaillant étroitement avec Zenika sur le domaine technique et architecture, Zenika étant l’un des meilleurs prestataires en consulting Java en France.

J’ai donc été amené à côtoyer des évangélistes des 2 côtés et plus important encore, j’ai vu les résultats sur des projets réels sur ces plateformes. Cela dit, sur quel critère devriez-vous baser une décision de plateforme.

Premièrement, lorsque vous développez un logiciel, c’est souvent pour qu’il soit utilisé sur une longue période. En fait, vous ne savez jamais vraiment quand il sera remplacé. La preuve en est, tous ces programmes Cobol toujours au cœur de beaucoup de systèmes bancaires. Il est donc essentiel d’évaluer la viabilité des choix et d’essayer de comprendre où va le marché au-delà des considérations purement techniques.

C’est la raison pour laquelle je parle surtout de .NET et Java. Ces 2 plateformes ont une taille critique et il est peu probable de voir disparaître l’une d’elles dans un futur prévisible. Ce qui pourrait ne pas être le cas en choisissant une plateforme plus exotique.

#1: Applicabilité de la plateforme pour vos scenarios

C’est le premier élément à prendre en compte. Je n’entrerai pas dans le débat de la performance dans la mesure où les 2 plateformes ont fait leur preuve dans presque tout type d’applications. La question se pose plus en termes de conception d’application.

Si l’exécution au-delà de Windows est une vraie exigence (ce qui n’est pas si souvent le cas), il faut choisir Java, étant donné que le support multi-plateforme de .NET est uniquement basé sur des initiatives à risques, pas entièrement soutenues par Microsoft. Microsoft n’est pas une plateforme neutre et ne le sera probablement jamais.

Cela dit, depuis que la plateforme Windows domine de manière significative, pour de nombreux cas, ce n’est pas un problème.

#2: Efficacité de la plateforme de développement pour vos scenarios

Si vous n’avez pas une réelle contrainte multi-plateforme, que vos applications fonctionnent sur Windows, et surtout si votre budget et votre calendrier sont réduits, opter pour la Plateforme .NET. Il est clairement plus facile d’implémenter des applications .NET pour une raison simple : .NET est totalement intégré et les mises à jour de version s’effectuent globalement. Vous disposez d’un Framework unique d’environ 25 000 classes de base qui évoluent simultanément, avec un environnement de développement intégré.

Alors que dans le monde Java, non seulement vous aurez à vous procurer différents Framework provenant de différents fournisseurs ou de la communauté mais vous aurez certainement besoin d’ajuster ce choix au fil du temps. C’est un investissement important en argent et en temps pour les projets Java. Sans parler du risque de choisir un Framework qui sera obsolète ou incompatible avec d’autres briques dans le futur. C’est la raison pour laquelle la dependency injection est déterminante sur la plateforme Java alors qu’elle n’est généralement pas nécessaire sur la plateforme Microsoft à l’exception de quelques scénarios très spécifiques (que je développerai dans un autre billet).

C’est évidemment une vision un peu simpliste, il y a matière à développer les avantages de Java pour les applications embarquées ou de .NET lorsque vous avez besoin d’une intégration à Microsoft Office, mais c’est le point le plus important à comprendre sans se perdre dans les détails.

#3: Disponibilité des compétences dans votre organisation et sur votre marché

Une autre considération importante qui peut peser dans la décision, ce sont les compétences des personnes dans votre organisation. Si 80% de vos ressources de développement sont à l’aise avec une plateforme quelle qu’elle soit, il serait suicidaire de choisir l’autre.

Non seulement vous aurez à les former mais très souvent, les développeurs sont d’un côté ou de l’autre. Il n’est pas si facile pour bon nombre de développeurs de passer de l’une à l’autre et je ne parle pas des ‘comportements religieux’ en particulier pour ceux tournés vers l’open-source.

J’ai pu observer que la plupart des ingénieurs ‘intelligents’ ont tendance à se tourner vers l’éco-système Java. Quand je dis ‘intelligent’, je parle du potentiel intellectuel. Le problème est que cela va souvent de pair avec un état d’esprit non-pragmatique qui mène à des sur-architectures et des désastres économiques. A lire ce billet excellent de Joel Spolsky pour comprendre.

Malheureusement, ces sur-architectes ont tendance à investir le monde .NET dans la mesure où il gagne du terrain sur le haut du marché. Et cette complexité tend même à investir la plateforme .NET, Microsoft étant à l’écoute de la communauté. Est-ce que le modèle unique de programmation promu au lancement de .NET passera l’épreuve du temps ? Ce n’est pas évident quand on constate les réelles différences d’implémentation entre ASP .NET Webforms et MVC, Silverlight et WPF etc …

#4: Spécificités additionnelles relatives au marché

Enfin et surtout, le marché peut influencer une telle décision. Si vous développez un produit packagé pour les petites entreprises, il est probable que votre client soit en quelques sortes ciblé par Microsoft, par conséquent, choisir la brique Microsoft peut créer des opportunités de partenariat spécifique.

En revanche, si votre marché est principalement Java comme dans les télécommunications ou les secteurs du gouvernement, il est vraisemblable qu’il soit plus facile de vendre un produit développé sur Java.

#5: Utilisation de plusieurs plateformes ?

Dans certains cas, il pourrait être pertinent d’utiliser plusieurs plateformes pour des scénarios hétérogènes. Si vous avez des équipes mixtes et la taille critique pour cela, ça peut être un bon moyen de créer de l’émulation entre les équipes et réaliser des scénarios qui impliquent l’interopérabilité.

Par ailleurs, il est vraisemblable que l’on ait à faire face à des compétences multiples afin que les nouvelles plateformes attirent par le biais de la mobilité et des réseaux sociaux. iPhone est devenu incontournable pour beaucoup d’entreprises et une plateforme comme Facebook pourrait attirer des développeurs dans un futur relativement proche.

N’hésitez pas à commenter ce billet ou partager votre expérience pour compléter mon point de vue.

Daniel COHEN-ZARDI

Classé dans Développement .NET Tag(s) associé(s) : , ,

La génération de code : un bien ou un mal ?

mars 7, 2013 Poster un commentaire

Combien de fois ai-je entendu des débats sans fin sur les avantages ou les risques de la génération de code. Les développeurs débattent en toute bonne foi sur ses vertus et ses dangers avec un niveau de passion qui frôle parfois le niveau des guerres de religion.

La vraie question

Après avoir passé 20 ans dans le logiciel, je peux affirmer avec détermination que cette question est mal posée. La question n’est pas ‘devriez-vous’ ou ‘ne devriez-vous pas’ générer du code ? La question serait plutôt de savoir quand et comment ?

Consciemment ou pas, en tant que développeur, vous utilisez certainement les mécanismes de génération de code à différents niveaux avec vos outils.

Voici quelques exemples dans le monde .NET :

  • ASP.NET est lui-même un générateur de code. Des classes intermédiaires sont générées et compilées à la volée.
  • Le concepteur de Windows Forms est un générateur de code. Il crée des classes C# ou VB.NET à partir de l’éditeur de formulaires graphiques.
  • Le concepteur XAML designer est un générateur de code. Il crée des fichiers .G cachés de l’éditeur graphique XAML.
  • La class XmlSerializer, utilisée massivement pour la sérialisation XML, est un générateur de code implicite. Elle crée du code et le compile pour améliorer la performance de la sérialisation.
  • Certains fichiers de Visual Studio comme les .RESX (fichiers de ressources) ou .SETTINGS (fichiers de configuration) sont utilisés par l’environnement de développement pour générer des classes utilitaires.
  • Les fichiers .EDMX d’Entity Framework (Entity Data Model) sont utilisés pour générer des classes ObjectContext d’Entity Framework.

En réalité, la génération de code n’est jamais un problème tant que :

  • Soit elle est transparente (vous ne savez même pas que vous l’utilisez),
  • Soit vous faites confiance au générateur (et vous n’avez pas besoin de vérifier ce qu’il génère).

Les avantages de la génération de code

Pour comprendre quand vous devez l’utiliser, commençons par souligner les bénéfices qu’elle peut vous apporter. Correctement utilisée, la génération de code vous permettra d’automatiser des tâches de programmation qui devraient être faites à la main. Ce n’est pas très différent de n’importe quel processus d’automatisation de tâches répétitives.

Par conséquent, quand la programmation devient-elle répétitive ? Surtout lorsque vous avez besoin de suivre une structure et d’implémenter des motifs ("patterns") de la même manière pour un nombre significatif d’éléments.

En règle générale, quand vous implémentez une application métier, vous avez plusieurs entités métiers et avez besoin de structurer votre application en couches. En faisant cela vous aurez besoin de mettre en œuvre l’accès aux données et la manipulation des méthodes, la structure du modèle objet métier, les couches services et aussi des éléments de l’interface utilisateur ou des rapports qui reproduiront les mêmes schémas d’implémentation et les mêmes principes.

Coder cela à la main, cela prend non seulement plus de temps mais c’est une source d’erreurs induisant un risque de qualité hétérogène et une dette applicative plus élevée.

image

En observant le schéma ci-dessus, on comprend aisément qu’il est moins lourd de maintenir les éléments à la source de la génération que de maintenir l’équivalent écrit manuellement.

Si cela est si évident, comment se fait-il que des développeurs chevronnés puissent le contester ?

Quand la génération de code ne fonctionne-t-elle pas ?

Le vrai problème réside dans le fait que générer du code approprié avec un niveau de flexibilité suffisant et une réelle capacité d’évolution est complexe, et la plupart du temps, ce point est sous-estimé par les développeurs, même les plus intelligents. Par conséquent certains développeurs ont souvent eu des mauvaises expériences et en sont arrivés à la conclusion que la génération de code était une mauvaise idée.

Sur le terrain, on observe 2 scénarios principaux d’échecs.

Dans le 1er cas, le développeur a essayé de développer son propre générateur. Cela commence généralement lorsque le développeur remarque qu’il effectue une tâche répétitive et qu’il essaie de l’automatiser, ce qui semble intelligent à premier vue. Mais quand la complexité augmente, ajuster le générateur avec des besoins plus riches devient plus chronophage que de coder à la main.

Si nous devions ajouter la maintenance du générateur de code dans le schéma des coûts, ils seraient sans doute bien plus élevés qu’avec le code manuel sur le long terme surtout si vous voulez un ensemble de fonctionnalités significatif et supporter les technologies dès leur disponibilité.

Ensuite, le développeur est généralement pris au piège avec comme alternative soit d’investir plus de temps dans le générateur, soit de considérer ce qu’il a fait comme une action ‘one-shot’ et essayer de maintenir directement le code généré. Pas de chance ! Les 2 approches sont des impasses.

L’investissement dans un générateur puissant et flexible croit de façon exponentielle et le développeur n’a aucune chance de maintenir le rythme de l’innovation technologique à moins que cela ne devienne son unique objectif de développement.

Maintenir le code généré à la main est également une mauvaise idée. Une base de code généré est toujours plus importante qu’une base créée manuellement, donc il est contre-productif d’utiliser un générateur si vous devez maintenir le code généré. Votre dette de maintenance sera accrue.

Le 2nd scénario est l’utilisation d’un générateur de code limité. Qu’est-ce qu’un générateur de code limité ?

Il y a différentes façons pour un générateur de montrer ses limites. La plus classique est le manque d’ouverture de beaucoup de générateurs de code. La majorité relève le défi de la complexité en réduisant vos options en tant que développeur jusqu’à limiter les possibilités pour le développeur. C’est pourquoi les capacités d’extension et de personnalisation doivent être étudiées en détail lorsque vous évaluez ce type d’outil.

De l’autre côté du spectre, il y a l’approche opposée basée sur des ‘templates’. La génération de code basée sur les templates est un mécanisme très simple et puissant pour mixer du code et du contenu. C’est typiquement ce qui a été utilisé pour la technologie “Active Server Pages”, en utilisant la syntaxe <% … %>, quand Microsoft a proposé sa 1ère approche dynamique pour le web.

Cela est très séduisant à première vue, car très ouvert puisque vous pouvez faire évoluer vos tempIates pour ajouter des fonctionnalités. Cependant, bien qu’utile dans certains scénarios, ce procédé pose des problèmes de complexité s’il est appliqué au cœur d’applications fonctionnellement riches. Ces générateurs de code apportent intrinsèquement une faible valeur dans la mesure où ils transfèrent la complexité dans les templates. Lorsque le code entre parenthèses pèse plus que les éléments de contenu, c’est un signe que vous êtes allé trop loin.

Une couche sérieuse de “Business Object Model” pour les applications professionnelles ne peut être générée avec des templates sans que ceux-ci ne deviennent très complexes. Au mieux, ces templates sont maintenables par un développeur ‘superman‘ qui les conçoit. Au pire, ils ne peuvent plus évoluer.

C’est exactement pour cette même raison que Microsoft a abandonné ASP qui fonctionnait pour des sites web simples et peu dynamiques et a développé la Plateforme ASP .NET. Cette nouvelle approche était rendue nécessaire pour une plateforme d’applications web plus riches et un niveau de maintenabilité approprié.

Les attributs d’une génération de code qui fonctionne

Avec toutes ces manières d’échouer dans la génération de code, comment donc réussir ?

De notre point de vue, les attributs clé d’une génération de code efficace pour les applications métiers sont les suivants :

  • Le générateur de code est fourni pour une équipe responsable et distincte de l’équipe qui développe l’application métier,
  • Idéalement, le générateur de code est maintenu par une société extérieure qui en a fait son métier et ses affaires,
  • Le générateur est suffisamment fiable pour que vous puissiez concentrer vos efforts de maintenance uniquement sur les éléments sources de la génération,
  • Le code généré reste lisible et suffisamment simple pour ne pas introduire un niveau de complexité supérieur au code manuel,
  • La génération de code des parties centrales et back-end (base de données et modèle métier) permet de maitriser la complexité à travers une modélisation puissante des concepts,
  • La génération de code basée sur les templates est uniquement utilisée sur les composants qui implémentent plus d’éléments visuels et de contenu que de logique métier, typiquement les composants frontaux tels que les interfaces utilisateur et les rapports.

Comme à l’accoutumée, n’hésitez pas à commenter de vos propres expériences.

Daniel COHEN-ZARDI

Classé dans CodeFluent Entities, Développement .NET Tag(s) associé(s) : , , , , , , , , ,

Techdays 2013 – Session couronnée de succès

février 27, 2013 Un commentaire

IMG_1718

Antoine et Pablo, 2 de nos consultants, ont eu le plaisir d’animer la session ‘Améliorez votre productivité avec Visual Studio 2012’. Tous 2 passionnés par les technologies Microsoft et par CodeFluent Entities, le générateur de code orienté ‘Model-First’ directement intégré à Visual Studio, ils pratiquent Visual Studio au quotidien mais sont un peu moins habitués des salles de conférence. Quelle ne fut pas leur surprise de constater que cette session était prévue dans l’amphi bleu, une salle de 800 personnes ! Mais la surprise a atteint son paroxysme lorsque l’amphi s’est rempli jusqu’à faire salle comble. Cette session a été enregistrée et nous ne manquerons pas de vous transmettre le lien pour visionner le Webcast prévu pour fin mars.

Classé dans Actualités, Développement .NET Tag(s) associé(s) : , , ,

Les bénéfices du développement logiciel “Model-First”

février 8, 2013 Poster un commentaire

Livre blanc CodeFluent Entities

Model-First_FR

L’objectif de ce livre blanc est de décrire l’enjeu du développement logiciel et clarifier les causes principales de cette difficulté intrinsèque.

La première partie du document explique l’enjeu du marché et pourquoi ce problème est si difficile. Cette partie concerne quiconque s’intéresse au développement logiciel et est indépendante de notre offre.

Dans la deuxième moitié du document, nous expliquons comment SoftFluent répond à cet enjeu au travers de sa fabrique logicielle “Model-First” CodeFluent Entities et la méthodologie associée.

Lire le livre blanc CodeFluent Entities

En savoir plus sur CodeFluent Entities

Classé dans Actualités, CodeFluent Entities, Développement .NET Tag(s) associé(s) : , , , , , , , , ,

Générer des services web JSON à partir d’une base existante avec CodeFluent Entities

février 6, 2013 Poster un commentaire

Cet article publié sur CodeProject (US) vous montre comment générer une couche de service web basée sur JSON à partir d’une base de données existante à l’aide de CodeFluent Entities. Nous générerons également un “back-office” Web à l’aide de “l’assistant d’import”.

Un scénario courant

Imaginons que nous devons faire face au scénario suivant :

  • Nous disposons d’une base de données que nous voulons exposer à l’aide d’une couche de service web basée sur JSON, fournissant des opérations CRUD (Create, Read, Update and Delete).
  • Nous devons construire un back office pour gérer et administrer les données de notre base.
  • Nous aurions probablement besoin dans le future d’accéder de différentes façons à notre base, par exemple depuis un client intelligent ou en exposant une couche de service web SOAP (de nouveaux besoins se font jour régulièrement).
  • Nous devons déployer ce système au plus vite.

Commençons donc, et nous devons alors:

  • Construire une couche d’accès pour charger les données, créer de nouvelles données, mettre à jour ou supprimer les données existantes (et nous assurer du bon fonctionnement).
  • Gérer la validation des données (et nous assurer du bon fonctionnement).
  • Construire la couche de service web JSON :
    • Construire chaque contrat de service et opération.
    • Configurer nos contrats de service pour supporter JSON.
    • Héberger nos services.
    • Nous assurer du bon fonctionnement
  • Construire un client web (et nous assurer du bon fonctionnement).
  • Disposer les fondations pour que les évolutions futures et les architectures à venir puissent être supportées, incluant l’accès mobiles par différents types d’appareils et téléphones.
  • Et tout ce que nous avons pu oublier.

Ou… Nous pouvons utiliser CodeFluent Entities pour faire la plomberie et être sûr que cela fonctionne.

Dans l’assistant de démarrage, nous voyons quelques-unes des architectures prédéfinies que l’on peut générer à l’aide de CodeFluent Entities, et bien sûr vous pouvez imaginer votre propre architecture en créant un projet spécifique CodeFluent Entities projet avec le jeu de producteurs qui vous convient.

clip_image002

Le scénario que nous mentionnons ici est détaillé "étape par étape" dans l’article complet en anglais sur CodeProject.

Classé dans Actualités, CodeFluent Entities, Développement .NET Tag(s) associé(s) : , , , , , ,

Meilleurs vœux pour l’année 2013 !

janvier 24, 2013 Poster un commentaire

SoftFluent vous présente ses meilleurs vœux pour 2013, avec beaucoup de succès dans tous vos projets de développement. Nous vous souhaitons d’être chez vous de bonne heure tout en produisant des applications au sommet de l’état de l’art grâce à CodeFluent Entities !

Cliquez sur l’image ci-dessous pour l’animation complète de nos vœux!Windows8FR

Classé dans Actualités, Développement .NET Tag(s) associé(s) : , , , , ,

Le mythe du "mois-homme indien"

janvier 7, 2013 7 Commentaires

Introduction

Depuis longtemps, il est établi que la mesure des résultats du développement logiciel ne peut pas se réduire à une unité de temps passé de type mois-homme. En 1975 déjà, le ‘mythe du mois-homme’ est devenu un livre célèbre qui expliquait ce point de différentes manières, en évoquant par exemple que l’ajout de ressources à un projet logiciel en retard ne faisait qu’accentuer celui-ci. Le livre a été édité de nouveau en 1995, confirmation de sa pertinence mais aussi une preuve que la nécessité d’expliquer cela à des personnes extérieures au logiciel reste complètement d’actualité 20 ans après. Je n’ai pas de doutes sur le fait qu’il faille encore répéter le message en 2015, dans la mesure où la production de logiciels reste une discipline largement méconnue des décideurs.

Dilbert_Man-month

Beaucoup de gens continue à comparer cela à l’industrie physique où le même élément doit être produit des milliers ou des millions de fois avec le même processus. Dans le logiciel, un code source est produit une seule fois car il est immatériel et peut être copié autant que nécessaire à un coût marginal quasiment nul. Et même en comparant avec l’industrie, est-ce qu’une équipe de 10 hommes équipée de pelles creuse un trou plus rapidement et à moindre coût qu’une équipe de 3 hommes équipée de bulldozers ? Il n’est donc pas difficile à comprendre que chaque métier évolue en méthode et en outillage. Le logiciel est probablement encore plus concerné compte-tenu de sa complexité technologique et de la rapidité d’évolution.

L’émergence de l’off-shore

Pourtant, depuis l’émergence du modèle off-shore dans les années 90, l’accent mis sur le taux horaire des développeurs a atteint un sommet avec peu de voix dans l’industrie du logiciel pour défier ces nouveaux modèles de production de logiciels.

Le raisonnement est aussi simple que le suivant : la majeure partie des coûts de développement correspond au salaire des développeurs dans la mesure où c’est une activité chronophage, ce qui est vrai. Donc, en allant vers des pays où le temps est moins coûteux, cela coûtera moins cher au final. On néglige ainsi totalement l’importance de la méthodologie, en particulier le processus d’interaction entre les développeurs et les utilisateurs ou la gestion produit, les compétences ou encore l’outillage mais qui s’en soucie ?

Lors, le développement des méthodes de réduction des coûts combiné au pouvoir donné aux départements des achats, à leur méthode basique de comparaison et à l’absence d’une métrique pertinente pour mesurer la production de logiciel (au-delà du seul mois-homme) a fait de ce raisonnement la tendance générale de l’industrie. C’est ce qui nous a mené à ce que j’appelle le "syndrome du mythe du mois-homme indien", les développeurs indiens ayant des salaires moins élevés que leurs équivalents des pays occidentaux, même si cela tend à s’ajuster.

Malgré la prise de conscience de nombreux échecs sur le terrain (vous pouvez lire cet article de 2004 à titre d’exemple tout en notant la prudence du titre), la tendance s’est poursuivie jusqu’à ce jour. Dans une certaine mesure, les compétences et une partie de la méthodologie de production se sont bien sûr améliorées dans les pays off-shore mais le point le plus important relatif à l’interaction avec les utilisateurs demeure.

20% d’économie "lorsque ça marche"

En tant que Président de la commission R&D de l’ AFDEL (Association Française des Editeurs de Logiciels), j’ai eu la chance d’animer une session de partage d’expériences à propos de l’off-shore. Avec les responsables de différents départements de R&D, nous n’avons pas seulement évoqué les nombreux échecs. Le point qui m’a le plus frappé est que les projets réussis parlent d’une économie de 20% à la fin incluant tous les coûts cachés nécessaires pour le faire fonctionner. Il a également été évoqué la nécessité d’une montée en puissance de 2 ans pour en faire un succès.

Fait intéressant, j’ai trouvé cet article du CIO magazine qui confirme cette observation faite dès 2003 ! Cet article a le mérite de lister une partie des coûts ainsi que d’expliquer cette réalité d’une "économie de 20% dans les cas les plus favorables".

La compréhension de la dure réalité de l’off-shore devrait être sans surprise, à l’image du commentaire de cet article que j’affectionne :

Il est très difficile pour les utilisateurs et les informaticiens qui résident dans le même pays de travailler sur les contraintes qu’exige le logiciel et de mener à bien un projet. En fait, certaines statistiques disent que 80% des projets ne parviennent pas à atteindre leurs objectifs. Dès lors, imaginez déplacer l’équipe technique à des milliers de km avec un horaire de travail à l’opposé de leurs utilisateurs finaux, une autre langue maternelle, une culture et des mœurs radicalement différents. Avec le sarcasme dont je suis capable, je dois dire que rien de tout cela semble intuitivement augmenter les chances de succès mais présente "l’avantage" d’être réellement bon marché.

Payer moins cher quelque chose qui ne répond pas à votre besoin est à coup sûr une mauvaise dépense!

Probablement plus de 100% de coûts supplémentaires dans les autres cas

Revenons à l’expérience terrain, l’off-shore ‘en soi’ n’est pas la solution aux nombreux défis auxquels le développement logiciel a à faire face. C’est pourquoi nous observons de nombreux échecs sur le terrain où nous estimons que les coûts représentent aisément le double de ce qu’ils devraient être, non seulement à court terme mais sur le long terme également.

Ce n’est pas la question de savoir si les développeurs sont bons ou pas dans certaines zones géographiques (bien qu’il existe des zones avec plus ou moins de compétences) mais souvent la nature du développement logiciel qui rend difficile un travail réalisé à trop forte distance des utilisateurs.

Les méthodes agiles qui sont dans la tendance sont assez intelligentes pour mettre l’accent sur la proximité du rôle de gestion du produit. Nous avons développé l’importance de l’alignement dans une série de billets sur "mesurer la performance du développement logiciel", qui développent 5 dimensions critiques :

  1. Alignement
  2. Productivité
  3. Qualité
  4. Minimisation de la dette
  5. Prédictibilité

Si l’équipe est conséquente, vous pourriez vous retrouver du bon côté du spectre à 80% de coût grâce à l’économie d’échelle, cela constituant néanmoins un réel un défi. Mais nous avons vu aussi de nombreux clients faire marche arrière et embaucher des ressources locales.

Il existe également un grand tabou qui fait que beaucoup de projets en échec sur le terrain sont parfaitement justifiés par les équipes techniques, profitant de la difficulté des décideurs à se faire une vraie idée. Ce point est déjà courant dans cette industrie et se trouve bien sûr amplifié avec les complexités d’une équipe distante.

Au delà des coûts

Au delà des coûts, pousser trop loin l’off-shore a souvent pour conséquences :

  • Des limites de compétences qui se traduisent par des solutions techniques non optimales,
  • La perte de contrôle, car vous risquez de dépendre d’un partenaire externe dont les intérêts ne sont pas les mêmes que les vôtres,
  • Une perte d’agilité, car il se peut qu’un simple besoin de modification d’une règle métier prenne des semaines,
  • Des risques accrus de différentes natures en raison de la distance, de la langue, de la culture et parfois de risques légaux concernant la protection de la propriété intellectuelle.

En fin de compte, à trop externaliser vos développements, vous allez perdre les compétences, jusqu’à ne plus savoir évaluer si vous faites bien ou pas. On pourrait également mentionner l’enjeu citoyen dans son pays mais ce n’est même pas mon propos.

C’est pourquoi, même si l’off-shore est souvent un échec, peu de gens l’admettent et il en résulte une hypocrisie significative qui contraste avec les discussions d’experts lorsqu’ils confrontent leurs expériences en privé et individuellement.

Sérieusement, en tant que décideur éclairé, prendriez-vous le risque de perdre le contrôle de vos développements pour une hypothétique économie potentielle de 20% ?

Personnellement, je n’ai jamais pensé une seule fois à l’externalisation de notre propre développement logiciel, par exemple.

Comme nous l’avons écrit dans un précédent billet, ce n’est qu’avec la contribution des ingénieurs logiciel que vous pouvez faire la différence sur le marché à long terme dans la mesure où ils sont capables de faire des choix cruciaux. Certains choix peuvent impacter les coûts de développement logiciel d’un facteur 10 tout en produisant la même valeur !

Donc assurez-vous de garder au moins quelques compétences locales, sans quoi vous prenez un risque élevé de perdre le contrôle à un moment ou un autre.

Daniel COHEN-ZARDI

Classé dans Développement .NET Tag(s) associé(s) : , , , , , , ,

La programmation va-t-elle se simplifier ?

décembre 4, 2012 Poster un commentaire

Il y a déjà quelques mois, je répondais à un sondage Code Project à propos de la simplicité de la programmation et des tendances associées.

Alors que l’on pourrait penser que l’innovation technologique ne devrait exister que pour nous simplifier la vie, y compris notre vie en tant que développeur, les statistiques des réponses rendues visibles après participation au sondage montrent que 2 fois plus de développeurs pensent que la programmation va se complexifier par rapport ceux qui pensent qu’elle va se simplifier.

Option

%

La programmation va devenir extrêmement simple

4.83

La programmation va devenir plus simple

10.19

Les spécificités vont changer mais globalement la complexité du travail va rester la même

55.58

La programmation va devenir plus complexe

14.27

La programmation va devenir tellement complexe qu’elle va nécessiter une montée en compétences

15.13

Total

100%

En fait, cela correspond à notre constat de terrain chez SoftFluent, car la complexité gagne du terrain sur la simplicité. Ce qui est instructif dans ce sondage, c’est que cela se perçoit comme une tendance à long terme jusqu’au niveau du développeur.

Dans notre analyse, beaucoup d’outils de génie de logiciel (description en anglais) ont apporté de la simplicité dans l’espace client-serveur dans les années 90s, mais depuis l’explosion du web et des interfaces utilisateurs riches, il a été très difficile pour ces outils de faire face à l’innovation technologique avec le même niveau de simplicité.

En effet, construire un outil d’édition pour une technologie qui mélange profondément interface utilisateur et code métier (telles que HTML, Ajax, XAML, etc…) est un réel défi. Le WYSIWYG est loin d’être imaginable pour un développeur web, car ce que vous voyez n’est *jamais* ce que vous obtenez de manière précise, sans parler des différences liées aux navigateurs, dont la fragmentation du marché est repartie à la hausse ces dernières années.

Et depuis que les développeurs ont diminué l’emphase mise sur les ateliers de génie logiciel et langage de quatrième génération pour retourner à des langages de programmation de niveau 3 tels que Java ou C#, il semble que chaque nouvelle technologie apporte son lot de défis pour le développeur ; sans parler de la difficulté de faire un choix pertinent.

Souvenez-vous de l’effet d’annonce LightSwitch de Microsoft censé faire du développement Silverlight un jeu d’enfant…juste avant que Microsoft ne déplace l’emphase de Silverlight vers HTML 5 ! Même si Silverlight sera encore supporté pour un moment, cela ne facilite pas les choix stratégiques d’investissements.

Et avec l’avènement de Windows 8, c’est l’unicité du modèle de programmation .NET qui en prend un coup, avec le retour possible de C++, un lien plus fort avec la plate-forme Windows et de nouvelles APIs à maitriser pour le développeur.

Ci-dessous, le schéma de la plate-forme avec ses principales options :

clip_image002

Et encore, il s’agit d’une image simplifiée :

  • Voir le billet Doug Seven’s blog post pour une image plus précise,
  • Notez que cela ne couvre pas les options web telles que ASP.NET Webforms, MVC ou Silverlight
  • Et souvenez-vous que nous ne parlons que de la plateforme Windows !

Alors que la réalité des clients doit intégrer de multiples systèmes, des terminaux mobiles, et des progiciels qui sont souvent le cœur des systèmes d’information, souvent avec leur propre langage, on comprend la complexité réelle retraduite au niveau du terrain.

En fin de compte, ce sont beaucoup d’options possibles et autant de risques pour le client qui doit investir dans la technologie.

Par conséquent, pour nous il reste clair comme de l’eau de roche que la programmation est de plus en plus complexe aujourd’hui, et qu’il y a un besoin énorme de simplification au travers de méthodes et d’outils pour concevoir en amont des couches sous-jacentes.

Par construction, le mouvement de mode vers le "code-first" au niveau des développeurs ne permet pas cette abstraction et cette simplification. Il induit une dépendance à la couche du moment et diminue le niveau d’évolutivité, contrairement à une approche de modélisation qui permet de rester agile au niveau de l’architecture et des plates-formes cibles.

Nous sommes persuadés que ce mouvement sera suivi d’un retour à des méthodes de conception permettant la pérennisation des modèles métier, l’échec relatif de ces méthodes sur certains projets ayant souvent été dus à des outils trop abstraits ou complexes, alors qu’il n’y a aucune raison fondamentale de complexifier la conception d’applications de gestion, les concepts principaux étant disponibles depuis des années voire des décennies, certains datant de la bonne vieille méthode MERISE !

C’est notre préoccupation première depuis plusieurs années et nous continuons d’œuvrer pour que les développeurs du futur cochent la première case du sondage CodeProject.

Daniel COHEN-ZARDI, SoftFluent

Classé dans Développement .NET Tag(s) associé(s) : , , , , , , , , , ,

Interfaces utilisateurs générées par CodeFluent Entities

octobre 22, 2012 Poster un commentaire

Lors de précédents articles publiés sur le blog http://blog.codefluententities.com, nous vous avons montré comment utiliser certains producteurs d’interface utilisateur fournis par défaut avec CodeFluent Entities :

Dans cet article, nous allons mettre l’accent sur le fait que CodeFluent Entities est totalement indépendant de l’interface utilisateur. Afin d’illustrer ce propos nous allons vous montrer toutes les interfaces utilisateurs que CodeFluent Entities est capable de générer depuis le même modèle grace à ses différents producteurs. En effet, depuis un même et unique modèle, vous pouvez générer des écrans qui seront exécutés sur la plateforme de votre choix.

Notez que les applications générées dans cette exemple ne sont pas seulement un ensemble d’interfaces utilisateurs mais des applications complètement interactives partageant le même modèle, la même base de données et  qu’elles sont 100% fonctionnelles.

Pour cet article, nous avons utilisé le modèle « ContactManager Sample Model » fournit par CodeFluent Entities.

ContactManagerModel

Voici le modèle « ContactManager » en question :

ContactManagerSurface

Etant donné que nous avons déjà vu comment utiliser les producteurs fournis par CodeFluent Entities dans de précédents articles, nous allons directement présenter les interfaces utilisateurs générées sans s’attarder sur leurs configurations.

 

Interface utilisateur générée en utilisant le Windows 8 Store Producer :

La page d’accueil générée par défaut, liste tous les espaces de noms et les entités qu’ils contiennent :

Windows Store (1)

Cliquer sur une entité vous emmène sur la page de l’entité en question.

Sur cette page vous trouverez une capture de l’entité depuis laquelle cette page a été générée.

En faisant un clic droit ou en utilisant le raccourci « Ctrl+Z » un menu contenant la liste des actions disponibles pour cette entité apparait en bas de l’écran. Ces actions correspondent aux méthodes métier fournies par l’entité.

Windows Store (2)

L’écran suivant est l’écran affiché pour l’entité « Contact » lorsque l’on clique sur le bouton « LoadAll » puis en sélectionnant un des contacts de la liste se trouvant sur la gauche.

Windows Store (3)

Clic droit ou « Ctrl+Z » fera de nouveau apparaitre un menu en bas de l’écran qui permettra de créer, modifier ou supprimer une entrée.
Windows Store (4)

Voici par exemple l’écran d’édition qui apparait après avoir cliqué sur le bouton « Edit » :

Windows Store (5)

 

Interface utilisateur générée en utilisant l’ASP.NET MVC Producer :

La page d’accueil générée par défaut, liste tous les espaces de noms et les entités qu’ils contiennent :

ASP NET WebApp (1)

Cliquer sur une entité vous emmène sur la page de l’entité en question.

Sur cette page vous trouverez une capture de l’entité depuis laquelle cette page a été générée.

Sur la partie gauche de la page se trouve un menu contenant la liste des actions disponibles pour cette entité. Ces actions correspondent aux méthodes métier fournies par l’entité :

ASP NET WebApp (2)

L’écran suivant est l’écran affiché pour l’entité « Contact » lorsque l’on clique sur le bouton « LoadAll ». Cet écran liste tous les contacts grâce à une table HTML et permet de les trier. Depuis cette page vous pouvez détailler, éditer ou supprimer un contact.

ASP NET WebApp (3)

Cliquer sur le lien « Details » permet d’afficher l’écran suivant :

ASP NET WebApp (4)

Cliquer sur le lien « Edit » permet d’éditer le contact choisit :

ASP NET WebApp (5)

 

Interface utilisateur générée en utilisant l’ASP.NET AJAX Producer :

La page d’accueil générée par défaut, liste tous les espaces de noms et les entités qu’ils contiennent :

ASP NET AJAX-JSON (1)

Cliquer sur une entité vous emmène sur la page de l’entité en question.

Sur cette page vous trouverez une capture de l’entité depuis laquelle cette page a été générée.

Sur la partie gauche de la page se trouve un menu contenant la liste des actions disponibles pour cette entité. Ces actions correspondent aux méthodes métier fournies par l’entité :

ASP NET AJAX-JSON (2)

L’écran suivant est l’écran affiché pour l’entité « Contact » lorsque l’on clique sur le bouton « LoadAll ».

Cet écran liste tous les contacts grâce à une grille Ajax supportant le tri et la pagination. Depuis cette page vous pouvez détailler, éditer ou supprimer un contact.

ASP NET AJAX-JSON (3)

Cliquer sur le bouton « Edit » permet d’éditer le contact choisit :

ASP NET AJAX-JSON (4)

 

Interface utilisateur générée en utilisant l’ASP.NET WebForms Producer :

La page d’accueil générée par défaut, liste tous les espaces de noms et les entités qu’ils contiennent :

ASP NET WebForms (1)

Cliquer sur une entité vous emmène sur la page de l’entité en question.

Sur cette page vous trouverez une capture de l’entité depuis laquelle cette page a été générée.

Sur la partie gauche de la page se trouve un menu contenant la liste des actions disponibles pour cette entité. Ces actions correspondent aux méthodes métier fournies par l’entité :

ASP NET WebForms (2)

L’écran suivant est l’écran affiché pour l’entité « Contact » lorsque l’on clique sur le bouton « LoadAll ». Cet écran liste tous les contacts grâce à une table HTML et permet de les trier. Depuis cette page vous pouvez éditer ou supprimer un contact.

ASP NET WebForms (3)

Cliquer sur le bouton « Edit » permet d’éditer le contact choisit :

ASP NET WebForms (4)

 

Interface utilisateur générée en utilisant le Smart Client (WPF) Producer :

Le premier écran généré par défaut liste tous les espaces de noms et les entités qu’ils contiennent :

SmartClient (1)

Cliquer sur une entité charge toute les données correspondantes, ici l’entité « Contact ». Depuis cet écran, vous pouvez créer éditer ou supprimer un contact.

SmartClient (2)

Cliquer sur un contact permet d’ouvrir une nouvelle fenêtre permettant de l’éditer.

SmartClient (3)

Interface utilisateur générée en utilisant le SharePoint WebParts Producer :

La page d’accueil générée par défaut, liste tous les espaces de noms :

SharePoint (1)

Cliquer sur un espace de nom liste toutes ses entités :

SharePoint (2)

Cliquer sur une entité charge la page d’entité, ici l’entité « Contact ». Cet écran liste tous les contacts grâce à une WebPart. Depuis cette page vous pouvez créer, détailler, éditer ou supprimer un contact.

SharePoint (3)

Cliquer sur un contact permet d’en afficher le détail :

SharePoint (4)

Cliquer sur le bouton « Edit » permet d’afficher l’éditeur :

SharePoint (5)

 

Comme vous pouvez le voir, à partir d’un seul et même modèle nous avons pu généré des interfaces utilisateurs à la fois différentes et consistantes.

Ajoutons que grâce au Platform Independent Form Editor il est aussi possible de définir directement un formulaire basé sur une entité. Celui ci sera ensuite transformés en écrans par les producteurs d’interfaces utilisateurs. Vous trouverez plus d’information dans cette article (Anglais).

Enfin, dans le cas où vous ne trouveriez pas le producteur répondant à vos besoins, souvenez vous que vous pouvez créer votre propre template et l’utiliser avec le Template Producer ou même créer votre propre producteur.

Pour résumer, CodeFluent Entities est capable de générer des application 100% fonctionnelles avec les interfaces utilisateurs de votre choix grace à sa logique de “producteurs”.

Classé dans CodeFluent Entities, Développement .NET Tag(s) associé(s) : , ,

← Articles Précédents

Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 30 followers