Discussion :

[AoCannaille]

Bonjour,

Je viens de finir une mission où une partie de mes tâches était du maquettage IHM. Maintenant que le devoir de réserve est révolu, je peux m'amuser du choix du client de l'outils pour effectuer le maquettage : Excel.
Bien que cette solution ai des avantages :
- possibilité de copier/coller,
- de calcul de taille en pixel,
- de dynamisation facile des labels

elle propose un maximum de contraintes qui rendent le choix difficile à cerner :
- Gestion d'impression complexe,
- limitation au niveau du rendu,
- impossibilité de faire des éléments complexes ( menus déroulants etc...),
- maquète 100% statique
- etc, etc...

sans parler du fait qu'on m'imposait une taille de cellule rectangulaire (carré aurait été tellement plus simple...)

Je sais qu'on peut toujours trouver moins adapté, mais là ils ont fait fort et entre collègues prestataire ça nous fait bien rire!

Et vous,quel est votre pire souvenir d'une association tâche-techno imposée très mal adaptée?

[Zirak]

Bonjour,

Je viens de finir une mission où une partie de mes tâches était du maquettage IHM. Maintenant que le devoir de réserve est révolu, je peux m'amuser du choix du client de l'outils pour effectuer le maquettage : Excel.
Bien que cette solution ai des avantages :
- possibilité de copier/coller,
- de calcul de taille en pixel,
- de dynamisation facile des labels

elle propose un maximum de contraintes qui rendent le choix difficile à cerner :
- Gestion d'impression complexe,
- limitation au niveau du rendu,
- impossibilité de faire des éléments complexes ( menus déroulants etc...),
- maquète 100% statique
- etc, etc...

sans parler du fait qu'on m'imposait une taille de cellule rectangulaire (carré aurait été tellement plus simple...)

Je sais qu'on peut toujours trouver moins adapté, mais là ils ont fait fort et entre collègues prestataire ça nous fait bien rire!

Et vous,quel est votre pire souvenir d'une association tâche-techno imposée très mal adaptée?

Euh sans vouloir être désagréable, autant je suis d'accord sur la limitation niveau rendu, autant sur certains arguments j'ai plus l'impression de lire l'avis de quelqu'un qui ne maitrise pas Excel / VBA que quelque chose de vraiment objectif

Car bon, sur Excel :

- on peut faire des menus déroulants (avec ou sans VBA)
- je ne vois pas trop la complexité au niveau de l'impression, on peut tout piloter via VBA également
- niveau mise en page, tu peux très bien générer la mise en page de tes écrans dynamiquement en fonction du nombre de données (toujours via VBA)
- etc etc

Donc oui, Excel et le VBA, c'est loin d'être la panacée, mais vu le nombre de PME qui gèrent toute leur boîte avec ces outils, cela doit bien être largement suffisant pour une maquette

[AoCannaille]

Euh sans vouloir être désagréable, autant je suis d'accord sur la limitation niveau rendu, autant sur certains arguments j'ai plus l'impression de lire l'avis de quelqu'un qui ne maitrise pas Excel / VBA que quelque chose de vraiment objectif

Car bon, sur Excel :

- on peut faire des menus déroulants (avec ou sans VBA)
- je ne vois pas trop la complexité au niveau de l'impression, on peut tout piloter via VBA également
- niveau mise en page, tu peux très bien générer la mise en page de tes écrans dynamiquement en fonction du nombre de données (toujours via VBA)
- etc etc

Donc oui, Excel et le VBA, c'est loin d'être la panacée, mais vu le nombre de PME qui gèrent toute leur boîte avec ces outils, cela doit bien être largement suffisant pour une maquette

Autant poour moi, je n'ai pas précisé que je n'avais pas le droit au VBA, macro, et editeur IHM de Excel. Je n'avais le droit que de colorier des cellules, les fusionner et écrire dedans Sinon effectivement, il y a un editeur wysiwyg d'ihm inclu dans Excel, j'aurai aimé l'utiliser!

[Zirak]

Autant poour moi, je n'ai pas précisé que je n'avais pas le droit au VBA, macro, et editeur IHM de Excel. Je n'avais le droit que de colorier des cellules, les fusionner et écrire dedans Sinon effectivement, il y a un editeur wysiwyg d'ihm inclu dans Excel, j'aurai aimé l'utiliser!

Ah c'est déjà pas pareil oui

Car bon qu'un outil spécifique te soit imposé, à la limite c'est leur droit, mais si en plus tu es limité au niveau de l'utilisation du-dit outil, c'est effectivement un peu bête, surtout que ce qui les intéresse c'est le résultat final de la maquette pas comment elle a été réalisée.

Après peut-être que c'était fait exprès pour avoir une maquette vraiment basique et que tu ne perdes pas du temps pour rien, à faire un truc plus élaboré en VBA ? Ou au contraire ont-ils pesté à la fin sur le résultat ?

[AoCannaille]

Ah c'est déjà pas pareil oui

Car bon qu'un outil spécifique te soit imposé, à la limite c'est leur droit, mais si en plus tu es limité au niveau de l'utilisation du-dit outil, c'est effectivement un peu bête, surtout que ce qui les intéresse c'est le résultat final de la maquette pas comment elle a été réalisée.

Après peut-être que c'était fait exprès pour avoir une maquette vraiment basique et que tu ne perdes pas du temps pour rien, à faire un truc plus élaboré en VBA ? Ou au contraire ont-ils pesté à la fin sur le résultat ?

C'est juste qu'ils ont commencé les maquettes comme ça (~250 écrans) et que pour les 50 à ajouter ils voulaient garder une cohérence. Un choix hérité a priori de 5/6 écrans fait en réunion à l'arrache et qui ont imposé la technique sur tout le reste.

[el_slapper]

C'est juste qu'ils ont commencé les maquettes comme ça (~250 écrans) et que pour les 50 à ajouter ils voulaient garder une cohérence. Un choix hérité a priori de 5/6 écrans fait en réunion à l'arrache et qui ont imposé la technique sur tout le reste.

un grand classique.

[Glutinus]

J'ai toujours trouvé ça étrange.
Les utilisateurs veulent toujours un truc "qui ressemble à Excel", évidemment, un tableur c'est utile.
Mais je me rends compte que la plupart qui l'utilisent tous les jours le maitrisent beaucoup moins que moi, c'est à peine s'ils savent qu'on peut faire =A1+B1 dans une cellule.

[pcaboche]

Et vous,quel est votre pire souvenir d'une association tâche-techno imposée très mal adaptée?

Moi c'est un mauvais souvenir récurrent, qui revient à chaque fois que je suis confronté à un ORM, le plus souvent choisi pour de mauvaises raisons.

Généralement, la raison invoquée c'est : "on veut être indépendant de la base de donnée choisie par le client, et c'est plus facile à déployer".

Mais selon moi, dans la grand majorité des cas la véritable raison, c'est : "personne chez nous ne fait de SQL, on est plus à l'aise dans l'écriture de programmes avec plein de méthodes qui traîtent les enregistrements un par un" .

...car au final, il y a quand même des vues qui ont été créées parce qu'ils ne pouvaient pas tout faire avec l'ORM
...et les fonctionnalités phares de l'application, ce ne sont pas tant les opérations de CRUD, mais bien le fait de pouvoir sortir des rapports
...et que le problème de base s'inscrit parfaitement dans une logique relationnelle (ex. : mettre en relation des écritures comptables)
...mais on a tout conçu en Orienté-Objet et pour le stockage des données, on a fait confiance à l'ORM
...et l'ORM a foutu des données partout
...et la base de données est pas mal dénormalisée par endroits

Puis on me demande de regarder comment améliorer le programme
...pour cela, j'ai besoin de récupérer des données
...alors j'expérimente un truc en SQL, pour vérifier certaines hypothèses (tout en respectant la norme pour que ce soit un minimum portable au moins entre Oracle et SQL Server)
...c'est fastidieux, et parfois assez tordu (l'ORM en a vraiment foutu partout; les programmeurs ont collé des valeurs bizarres) mais j'arrive quand même à retrouver certaines des données qui m'intéressent
...maintenant je fais le traîtement que j'ai en tête depuis le début (car j'ai passé plus de temps à rechercher les données éparpillées un peu partout qu'à concevoir le traîtement lui-même)
...il me reste à vérifier certains trucs (ex. : que la logique métier correspond bien à ce que j'ai fait) mais d'après mes premiers tests, on passe d'un traîtement de plusieurs minutes à une opération de quelques secondes
...et malgré tout, je pense que ça peut être plus facile à maintenir qu'un énorme programme Java

Mais ce qui me fait flipper, c'est que j'ai l'impression que c'est toute l'industrie qui est comme cela. Déjà, ce n'est pas la première société que je vois dans ce cas là, et quand je regarde les petites annonces (ou que celles-ci tombent directement dans ma boite e-mail), c'est toujours le même topo :
- on fait de l'analyse financière (avec plein de données dans tous les sens)
- notre projet précédent à foiré (c'est ce que je comprends en lisant : "highly complex (...) platform (that the bank is in the midst of re-building)" )
- on recherche un développeur Java / .Net / C++...
- "general SQL knowledge" (mais pas trop, hein, juste à dose homéopathique... )

Et lors des entretiens, c'est pareil :
- des questions théoriques sur de la POO (ex. : différence entre overloading et overwriting)
- des questions plus tordues sur des problèmes qui ne devraient même pas exister
- mais quasiment rien sur le traîtement des données (genre un petit test de logique sur comment lier des données)

J'ai l'impression que devant chaque problème informatique, la solution par défaut c'est "on n'a qu'à embaucher une armée d'Indiens pour nous pisser du code Java / .Net / C++ à longueur de journée... on ne veut même pas chercher à savoir s'il existe des solutions plus efficaces".

[Glutinus]

Et vous,quel est votre pire souvenir d'une association tâche-techno imposée très mal adaptée?

Ca ne répond pas vraiment à la question, mais je pense notamment au mauvais usage d'un ETL. Les personnes qui sont dans la business intelligence et particulièrement dans les ETL seront très certainement confrontés à cette situation !

Pour résumer, un ETL permet de transformer des données et de charger dans une BDD. La source peut être tout type : CSV, txt, base de données A, base de données B, XML...
Dans les faits on charge d'abord bêtement dans un endroit temporaire (DataStore), si possible déjà sur la base SQL, puis on fait les calculs du DataStore au DataWareHouse (c'est très très résumé).

Les ETL sont souvent graphiques et utilisent des briques qui sont autant de fonctions. Elles permettent de travailler séquentiellement et de s'affranchir de l'usage d'une requête SQL pour faire les opérations que l'on veut. On ne travaille d'ailleurs plus avec le langage SQL mais des langages maisons, avec des fonctions à paramétrer qui évite d'avoir accès aux syntaxes les moins utilisées.
Au niveau temps, c'est plus déterministe et on peut identifier rapidement les ralentissements de traitement, alors qu'en SQL c'est souvent un défaut d'architecture qui demande l'expertise d'un DBA.

Donc ce qui se fait souvent : une sorte de "select * from my table" puis derrière on fait des opérations que l'on veut, des sommes, des agrégats, des filtres, des case / when, et ainsi de suite dans le langage ETL. C'est d'ailleurs souvent très lisible quand c'est bien documenté, bien nommé, etc.

Le défaut : très souvent, pour éviter d'avoir un expert dans le langage, on "override" le SQL de base pour faire passer toutes les opérations dedans - les where, les group by, les order...
Ce qui finit toujours par des requêtes souvent mal codées car à l'arrache - j'imagine que le contexte est souvent "ho putain on n'a plus que deux jours pour développer et il en faut 5 d'après le chiffrage... Allez on fait une requête SQL et on testera en prod et on fera les specs techniques le mois prochain".
Plus-value de l'ETL : 0, puisque tout passe par le SQL. Licence chère.
Temps de traitement dégradé : à cause de la lecture et de la requête de sous-requête de sous-sous-requête de 1500 lignes, sans index, sans analyse... alors que ce serait plus facile de gérer via l'ETL.
Pas de possibilité de faire des jalons entre temps car c'est une requête ensembliste.
Quand il y a des jalons, les tables ont été vidées après les traitements. Impossible de savoir à quel moment la donnée a été altérée.
Enervement des développeurs : très elevé.
Donc : turn-over, très élevé.

Lorsque je suis parti, j'ai conseillé de chercher plutôt un mec bon en SQL de manière générale que dans l'ETL.
Mais pour la n-ième fois, mes supérieurs ont préféré cherché un expert ETL, qui va certainement s'énerver et claquer la porte à son tour...

[zecreator]

J'ai toujours trouvé ça étrange.
Les utilisateurs veulent toujours un truc "qui ressemble à Excel", évidemment, un tableur c'est utile.
Mais je me rends compte que la plupart qui l'utilisent tous les jours le maitrisent beaucoup moins que moi, c'est à peine s'ils savent qu'on peut faire =A1+B1 dans une cellule.

Le client veut pouvoir utiliser les outils qu'il maîtrise (ici Excel). Je dirai que la demande est légitime. Il n'a pas envie de raquer à chaque fois qu'il voudra faire une malheureuse modif sur son appli. Bon, ensuite je ne suis pas fan de tableur, et j'ai du mal à voir comment on peut produire une appli efficace avec un simple classeur Excel.

Mais si au final le service est rendu et que le client est content, pourquoi juger ?

[el_slapper]

Le client veut pouvoir utiliser les outils qu'il maîtrise (ici Excel). Je dirai que la demande est légitime. Il n'a pas envie de raquer à chaque fois qu'il voudra faire une malheureuse modif sur son appli. Bon, ensuite je ne suis pas fan de tableur, et j'ai du mal à voir comment on peut produire une appli efficace avec un simple classeur Excel.

Mais si au final le service est rendu et que le client est content, pourquoi juger ?

EXCEL, bien programmé, peut être TRÈS performant pour un style particulier d'applications : le pour un par un. Il devient complètement dépassé dès qu'on en arrive à deux utilisateurs, mais pour un utilisateur seul, c'est très puissant. Et je suppose que tes expériences ont été de concevoir des applis multi-utilisateurs avec EXCEL. Qui n'est définitivement pas fait pour ça. Et c'est très souvent ce dont rêvent les utilisateurs. Parceque ce qui fait la force d'EXCEL en monoutilisateur(la simplicité d'accès aux données, pour faire court), et ce qui le rend infernal en mode partagé.

Un choix technologique, c'est toujours un compromis. Si on gagne en performances en utilisant certains langages, on perd généralement en maintenabilité(pas toujours, je sais, c'est juste pour illustrer). Si on gagne en simplicité, on perd en fonctionnalités(ici le multiutilisateurs heureux). Et l'utilisateur veut tout.