La différence entre un bon et un mauvais programmeur...

Olivier Azeau <read.my.name.and.email.to.firstname@lastname.com> writes:

prototype : du grec protos "premier" et typos "empreinte, marque"

Comment définissez-vous donc "prototype" dans un tel contexte de
développement logiciel ?

"Plan to throw one away, you'll anyway." On fournit la premiere
version. On ne dit pas que c'est un prototype, mais j'ai pas d'autres
mots pour designer ce que c'est. C'est la premiere chose qui
fonctionne assez pour etre utilisee par celui qui l'a ecrit ou
d'autres personnes courageuses.

Quand on ne sait pas exactement ce qu'il faut réaliser, chez nous on fait
des maquettes.
Cela peut prendre la forme d'animations flash ou de code rapidement écrit
(mais jamais en C++) pour démontrer un aspect visuel. Cela peut prendre
d'un morceau de protocole rapidement implémenté pour juger l'intérêt de tel
ou tel serveur. etc.
Dans tous les cas, ce n'est jamais quelque chose d'utilisable soit parce
que c'est n'est que du "dessin", soit parce que la plupart des
fonctionnalités indispensables ne sont tout simplement pas présentes.

Montrer une animation, c'est facile. Nos problemes, c'est de
l'algorithmique. Resoudre des problemes connus pour etre NP-Complet
ou pire sur des donnees monstrueuses. Allez le dernier sur lequel
j'ai travaille: trouver dans un graphe (relativement petit, de l'ordre
de la centaine de noeuds -- on en a souvent avec des millions) les
sous-graphes "semblables" a un autre graphe donne. Pour une
definition de semblable mal definie qui ressemble a "faites moi ce que
je veux, c'est evident que dans ce cas-ci la solution est celle-ci et
que ca c'est vraiment pas une bonne solution". Mais ca c'est l'aspect
interessant. Le frustrant c'est quand on a quelque chose qui marche
relativement bien de ne pas pouvoir le retravailler pour en faire
quelque chose de robuste. C'est presque mieux d'avoir quelque chose
qui ne marche mal mais de savoir pourquoi: alors on peut mieux
defendre le fait de tout refaire sur la bonne voie. Naturellement ca
coute plus cher au total et le client est frustre et le developpeur
est frustre mais ne pas delivrer tout de suite est parait-il
impossible.

Je me demande donc ce que sont tous ces prototypes. Même si on sait
que la version 1 d'un logiciel ne pourra durer qu'un temps limité
(parce que l'on n'a pas pu y mettre tout ce que l'on y voudrait ou
que l'on n'a pas pu la construire comme on l'aurait souhaité), je ne
vois pas pourquoi elle devrait avoir un statut différent de celui
des versions suivantes, qui, en toute logique, ne peuvent être que
"plus" réfléchies.

La premiere version on ne sait pas ce que l'on fait. C'est le
probleme.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Si dans ton projet de 3 mois, le client débarque au bout de 8
semaines pour te dire que en fait il voudrait modifier
quelques trucs, tu ne seras pas en mesure de commencer le
codage car ta conception risque fort d'être sérieusement
remise en cause...

[..]

(Ceci suppose, évidemment, qu'on connaît le domaine de
l'application, et qu'on sait donc prévoyer les types de
modifications probables.)

Houlala ! C'est du balèze !

Le codage post conception assisté par boule de cristal.
Des projets probalistiques préconçus !

Vertigineux !


PS :
Mais, si tu sais prévoir les modifications que te demanderas ton client
dans le futur, alors à chaque réunion avec ce client, lorsqu'il fait mine de
prendre la parole tu l'interromps avec :
- HA ! mais c'est DEJA fait !

Et le client sans dire un seul mot part content.

Jean-Marc Bourguet wrote:

Olivier Azeau <read.my.name.and.email.to.firstname@lastname.com>
writes:

prototype : du grec protos "premier" et typos "empreinte, marque"

Comment définissez-vous donc "prototype" dans un tel contexte de
développement logiciel ?

"Plan to throw one away, you'll anyway." On fournit la premiere
version. On ne dit pas que c'est un prototype, mais j'ai pas
d'autres

mots pour designer ce que c'est.

"V1.0" ca ne convient pas ?

Quand on ne sait pas exactement ce qu'il faut réaliser, chez nous
on fait

des maquettes.
Cela peut prendre la forme d'animations flash ou de code rapidement
écrit

(mais jamais en C++) pour démontrer un aspect visuel. Cela peut
prendre

d'un morceau de protocole rapidement implémenté pour juger
l'intérêt de tel

ou tel serveur. etc.
Dans tous les cas, ce n'est jamais quelque chose d'utilisable soit
parce

que c'est n'est que du "dessin", soit parce que la plupart des
fonctionnalités indispensables ne sont tout simplement pas
présentes.

Montrer une animation, c'est facile. Nos problemes, c'est de
l'algorithmique. Resoudre des problemes connus pour etre NP-Complet
ou pire sur des donnees monstrueuses. Allez le dernier sur lequel
j'ai travaille: trouver dans un graphe (relativement petit, de
l'ordre

de la centaine de noeuds -- on en a souvent avec des millions) les
sous-graphes "semblables" a un autre graphe donne. Pour une
definition de semblable mal definie qui ressemble a "faites moi ce
que

je veux, c'est evident que dans ce cas-ci la solution est celle-ci et
que ca c'est vraiment pas une bonne solution".

Mais si qqun peut donner une telle information dans un cas, il doit
pouvoir la donner dans n cas, non ?
Bien souvent, on passe d'une expression de besoin mal définie a une
bien définie en multipliant les cas d'utilisations.

Mais ca c'est l'aspect
interessant. Le frustrant c'est quand on a quelque chose qui marche
relativement bien de ne pas pouvoir le retravailler pour en faire
quelque chose de robuste. C'est presque mieux d'avoir quelque chose
qui ne marche mal mais de savoir pourquoi: alors on peut mieux
defendre le fait de tout refaire sur la bonne voie. Naturellement ca
coute plus cher au total et le client est frustre et le developpeur
est frustre mais ne pas delivrer tout de suite est parait-il
impossible.

Il n'y a probablement pas de recette miracle a ce genre de probleme
mais dans mon cas il est résolu par des itérations relativement
courtes qui adressent certains points précis tout en conservant en
permanence un code robuste (au sens ou on se permet du refactoring a
tout instant)

"Olivier Azeau" <ransom@xasamail.com> writes:

Jean-Marc Bourguet wrote:

Olivier Azeau <read.my.name.and.email.to.firstname@lastname.com>
writes:

prototype : du grec protos "premier" et typos "empreinte, marque"

Comment définissez-vous donc "prototype" dans un tel contexte de
développement logiciel ?

"Plan to throw one away, you'll anyway." On fournit la premiere
version. On ne dit pas que c'est un prototype, mais j'ai pas
d'autres

mots pour designer ce que c'est.

"V1.0" ca ne convient pas ?

V1.0 de quoi? Nous vendons un environnement et naturellement un
developpement donne c'est une "feature", pas quelque chose de bien
separe auquel on pourrait essayer de donner un numero de version ayant
un sens s'il n'etait pas bien connu que le choix de ce numero est fait
par le marketing...

[...]

Montrer une animation, c'est facile. Nos problemes, c'est de
l'algorithmique. Resoudre des problemes connus pour etre
NP-Complet ou pire sur des donnees monstrueuses. Allez le dernier
sur lequel j'ai travaille: trouver dans un graphe (relativement
petit, de l'ordre de la centaine de noeuds -- on en a souvent avec
des millions) les sous-graphes "semblables" a un autre graphe
donne. Pour une definition de semblable mal definie qui ressemble
a "faites moi ce que je veux, c'est evident que dans ce cas-ci la
solution est celle-ci et que ca c'est vraiment pas une bonne
solution".

Mais si qqun peut donner une telle information dans un cas, il doit
pouvoir la donner dans n cas, non ?
Bien souvent, on passe d'une expression de besoin mal définie a une
bien définie en multipliant les cas d'utilisations.

A part naturellement que nous ne faisons pas du developpement
personnalise (bien que parfois...) mais vendons a peut pres la meme
chose a tout nos clients (avec un controle sur les licenses pour
activer ou non suivant ce qui est paye). Et que si tu demandes a un
autre -- ou a un autre employe chez le meme client --, il est tout
aussi evident pour lui qu'autre chose est la bonne solution. Pour le
meme exemple. Mais globablement c'est bien ca qu'on fait: on
rassemble les donnees et on essaye d'en faire qqch de coherent.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

K. Ahausse wrote:

Si dans ton projet de 3 mois, le client débarque au bout de
8 semaines pour te dire que en fait il voudrait modifier
quelques trucs, tu ne seras pas en mesure de commencer le
codage car ta conception risque fort d'être sérieusement
remise en cause...

[..]

(Ceci suppose, évidemment, qu'on connaît le domaine de
l'application, et qu'on sait donc prévoyer les types de
modifications probables.)

Houlala ! C'est du balèze !

Le codage post conception assisté par boule de cristal. Des
projets probalistiques préconçus !

Vertigineux !

Plutôt normal, je dirais, si tu as des experts métiers. Tu sais
ce que fait le client ; souvent, tu sais plus que lui ce dont il
a besoin. Tu peux donc anticiper plusieurs dégrées de liberté
dans la conception, quand ça ne coûte pas trop cher.

À la fin, il faut savoir ce qu'on fait. Si je fais un projet
dans un domaine que je ne connais pas, je cherche des experts
métiers pour collaborer avec moi. Justement pour qu'il y a
quelqu'un dans l'équipe qui sait un peu les directions que ça
risque de prendre.

Et évidemment, il existe des projets réelement expérimentaux, où
on fait ce que personne n'a fait avant, et où donc c'est
impossible à prévoir quoique ce soit. Mais ces projets-là ne se
font pas à prix fixe ; le client y est à nos côtes, et il paie à
l'heure. Dans ces cas-là, en général, on essaie de faire un
prototype, pour expérimenter ; aussi, on utilise souvent la
généricité à outre-mésure, au cas où.

Mais au moins dans les banques, dans la téléphonie, et dans les
applications contrôle de processus en temps-réels, c'est assez
rare. En fait, je crois qu'en général, dans l'industrie, c'est
assez exceptionnel.

PS :
Mais, si tu sais prévoir les modifications que te
demanderas ton client dans le futur, alors à chaque réunion
avec ce client, lorsqu'il fait mine de prendre la parole tu
l'interromps avec :

- HA ! mais c'est DEJA fait !

Et le client sans dire un seul mot part content.

Ça m'est déjà arrivé.

(En fait, c'était un cas particulier. Au départ, le client nous
trouver trop cher. On lui a dit que c'était parce qu'on lui
réservait telle et telle liberté d'évoluation, parce qu'on
savait qu'il en aura besoin, même si l'appel aux offres n'en
parlait pas. Lui, il insistait que non, et qu'il fallait baisser
le prix. On a finit par accepter, en lui avertissant que les
changements dont on parlait lui coûtera cher. On les a fait
quand même, en livrant la première version à perte. Puis, quand
les démandes de modification arrivaient, comme prévue, on
changeait un #define, récompilait, et facturait deux
hommes-mois. Si le client insiste à être stupide...)

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34