La différence entre un bon et un mauvais programmeur...
105 réponses
korchkidu
Le mauvais programmeur, il code, il compile, il exécute et ca plante.
Le bon programmeur, il code, il compile, il exécute, ca plante mais
c'est un bon programmeur...;)
Plus serieusement, je vois souvent "bons programmeurs" ou "mauvais
programmeurs". Comme je sais qu'il y a surement parmi vous des gens qui
doivent decider si quelqu'un est un bon ou un mauvais programmeur, je
serais curieux de connaitre les criteres sur lesquels vous vous bases
pour decider de ca dans le cas du C++. Par exemple, lors d'un entretien,
qu'est ce qui peut faire gagner des points et qu'est ce qui peut en
faire perdre...
Je precise que je n'ai aucunement l'intention (enfin j'espere, on ne
sait jamais ce qu peut nous arriver....) de passer ce genre d'entretien
dans un avenir proche, c'est juste une question de curiosite.
Merci pour vos commentaires,
K.
PS: merci de rester assez "haut-niveau" pour eviter que la discussion ne
degenere...;)
j'ai vu plusieurs fois des équipes passer du temps a peaufiner une conception avec une phase de conception dédiée et, a chaque fois, l'équipe a trop tardé a écrire du code.
Est-ce qu'on peut trop tardé à écrire du code ? En général, plus on rétard à écrire du code, plus le projet est fini vite.
Parce qu'il est annule pour manque de résultat tangible ?
Pas du tout.
En gros, dans mes propres développements, je compte à peu près 60% du temps à la conception, 30% au codage (ce qui comprend le codage des tests), et 10% sur la mise au point et la correction des erreurs. D'après mon expérience, réduire la conception en dessous des 60% amène à une augmentation du temps total de développement.
Donc, sur un petit projet de trois moins, on compte environ 8 semaines avant de commencer le codage. Si on commence au bout de 4 semaines, le même projet risque de durer quatre ou cinq mois, avec une mise au point importante (deux ou trois mois, plutôt qu'une semaine).
Pour reprendre une analogie connue, si le cout d'un crash test automobile était tres faible et sa mise en oeuvre tres rapide, les constructeurs automobiles ne passeraient pas des mois a concevoir un véhicule sur papier et a faire des simulations numériques : tous les jours, ils construiraient un prototype grandeur nature en 5 minutes et l'enverraient contre le mur pour voir s'il tient le coup.
Et ça leur avancerait à quoi ? À savoir ce qu'ils ont fait n'était pas juste ?
C'est un bon début, non ?
C'est toujours ça de gagné, en effet.
Parfois (souvent même, dans certains domaines), on est obligé à passer par des prototypes ; ou bien, le client ne sait pas exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou bien, le domaine est assez expérimental, et on ne sait pas ce qu'il faut nous même. Mais même ces prototypes ont une phase de conception.
Ça ressemble un peu l'histoire des millions de singes qui tappent au hazard au clavier, pour écrire Shakespeare.
Personne n'a parlé de coder au hasard (c'est a dire sans savoir ce que l'on veut coder). Il est juste question de vérifier le plus tot possible que ce que l'on a imaginé fonctionne réellement.
Je sais, et je caractèrisais. Mais l'idée y est, en quelque sort. On écrit pour voir si le code va marcher, puis on essaie au coup de déboggueur, jusqu'à ce qu'on ne voit plus d'erreurs. Il vaut mieux reflechir sur ce qu'on écrit, et écrit du code qui marche le premier coup. La perfection n'est pas de ce monde, mais dans les boîtes où j'ai travaillé, on arrivait bien à un taux d'erreurs inférieur à une erreur pour cent mille lignes de code. C'est comme ça d'ailleurs qu'on arrive à dépenser moins de 10% du temps dans la mise au point.
-- 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
Olivier Azeau wrote:
kanze@gabi-soft.fr wrote:
Olivier Azeau wrote:
j'ai vu plusieurs fois des équipes passer du temps a
peaufiner une conception avec une phase de conception
dédiée et, a chaque fois, l'équipe a trop tardé a écrire
du code.
Est-ce qu'on peut trop tardé à écrire du code ? En général,
plus on rétard à écrire du code, plus le projet est fini
vite.
Parce qu'il est annule pour manque de résultat tangible ?
Pas du tout.
En gros, dans mes propres développements, je compte à peu près
60% du temps à la conception, 30% au codage (ce qui comprend le
codage des tests), et 10% sur la mise au point et la correction
des erreurs. D'après mon expérience, réduire la conception en
dessous des 60% amène à une augmentation du temps total de
développement.
Donc, sur un petit projet de trois moins, on compte environ 8
semaines avant de commencer le codage. Si on commence au bout de
4 semaines, le même projet risque de durer quatre ou cinq mois,
avec une mise au point importante (deux ou trois mois, plutôt
qu'une semaine).
Pour reprendre une analogie connue, si le cout d'un crash
test automobile était tres faible et sa mise en oeuvre
tres rapide, les constructeurs automobiles ne passeraient
pas des mois a concevoir un véhicule sur papier et a faire
des simulations numériques : tous les jours, ils
construiraient un prototype grandeur nature en 5 minutes
et l'enverraient contre le mur pour voir s'il tient le
coup.
Et ça leur avancerait à quoi ? À savoir ce qu'ils ont fait
n'était pas juste ?
C'est un bon début, non ?
C'est toujours ça de gagné, en effet.
Parfois (souvent même, dans certains domaines), on est obligé à
passer par des prototypes ; ou bien, le client ne sait pas
exactement ce qu'il veut, et il faut lui montrer les
alternatifs, ou bien, le domaine est assez expérimental, et on
ne sait pas ce qu'il faut nous même. Mais même ces prototypes
ont une phase de conception.
Ça ressemble un peu l'histoire des millions de singes qui
tappent au hazard au clavier, pour écrire Shakespeare.
Personne n'a parlé de coder au hasard (c'est a dire sans
savoir ce que l'on veut coder). Il est juste question de
vérifier le plus tot possible que ce que l'on a imaginé
fonctionne réellement.
Je sais, et je caractèrisais. Mais l'idée y est, en quelque
sort. On écrit pour voir si le code va marcher, puis on essaie
au coup de déboggueur, jusqu'à ce qu'on ne voit plus d'erreurs.
Il vaut mieux reflechir sur ce qu'on écrit, et écrit du code qui
marche le premier coup. La perfection n'est pas de ce monde,
mais dans les boîtes où j'ai travaillé, on arrivait bien à un
taux d'erreurs inférieur à une erreur pour cent mille lignes de
code. C'est comme ça d'ailleurs qu'on arrive à dépenser moins de
10% du temps dans la mise au point.
--
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
j'ai vu plusieurs fois des équipes passer du temps a peaufiner une conception avec une phase de conception dédiée et, a chaque fois, l'équipe a trop tardé a écrire du code.
Est-ce qu'on peut trop tardé à écrire du code ? En général, plus on rétard à écrire du code, plus le projet est fini vite.
Parce qu'il est annule pour manque de résultat tangible ?
Pas du tout.
En gros, dans mes propres développements, je compte à peu près 60% du temps à la conception, 30% au codage (ce qui comprend le codage des tests), et 10% sur la mise au point et la correction des erreurs. D'après mon expérience, réduire la conception en dessous des 60% amène à une augmentation du temps total de développement.
Donc, sur un petit projet de trois moins, on compte environ 8 semaines avant de commencer le codage. Si on commence au bout de 4 semaines, le même projet risque de durer quatre ou cinq mois, avec une mise au point importante (deux ou trois mois, plutôt qu'une semaine).
Pour reprendre une analogie connue, si le cout d'un crash test automobile était tres faible et sa mise en oeuvre tres rapide, les constructeurs automobiles ne passeraient pas des mois a concevoir un véhicule sur papier et a faire des simulations numériques : tous les jours, ils construiraient un prototype grandeur nature en 5 minutes et l'enverraient contre le mur pour voir s'il tient le coup.
Et ça leur avancerait à quoi ? À savoir ce qu'ils ont fait n'était pas juste ?
C'est un bon début, non ?
C'est toujours ça de gagné, en effet.
Parfois (souvent même, dans certains domaines), on est obligé à passer par des prototypes ; ou bien, le client ne sait pas exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou bien, le domaine est assez expérimental, et on ne sait pas ce qu'il faut nous même. Mais même ces prototypes ont une phase de conception.
Ça ressemble un peu l'histoire des millions de singes qui tappent au hazard au clavier, pour écrire Shakespeare.
Personne n'a parlé de coder au hasard (c'est a dire sans savoir ce que l'on veut coder). Il est juste question de vérifier le plus tot possible que ce que l'on a imaginé fonctionne réellement.
Je sais, et je caractèrisais. Mais l'idée y est, en quelque sort. On écrit pour voir si le code va marcher, puis on essaie au coup de déboggueur, jusqu'à ce qu'on ne voit plus d'erreurs. Il vaut mieux reflechir sur ce qu'on écrit, et écrit du code qui marche le premier coup. La perfection n'est pas de ce monde, mais dans les boîtes où j'ai travaillé, on arrivait bien à un taux d'erreurs inférieur à une erreur pour cent mille lignes de code. C'est comme ça d'ailleurs qu'on arrive à dépenser moins de 10% du temps dans la mise au point.
-- 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
Jean-Marc Bourguet
writes:
Parfois (souvent même, dans certains domaines), on est obligé à passer par des prototypes ; ou bien, le client ne sait pas exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou bien, le domaine est assez expérimental, et on ne sait pas ce qu'il faut nous même. Mais même ces prototypes ont une phase de conception.
Le probleme chez nous, c'est que le client meme s'il ne sait pas ce qu'il veut le veut pour hier... et accepte plus ou moins bien de se servir du prototype -- c'est la seule solution pour resoudre son probleme d'aujourd'hui. On le lui vends donc parce que sinon c'est le concurrent qui le fera. Dans ce domaine, les start-up, c'est un moyen de faire developper les prototypes en paralleles. Au final, generalement celles qui ont choisit la bonne approche se font racheter, rarement une emerge et grossit assez. Faire la version finale est inutile: les problemes auront changes... donc on solidifie comme on peut, on agrege differentes solutions et on sait que dans deux ans on rachetera quelque chose.
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
kanze@gabi-soft.fr writes:
Parfois (souvent même, dans certains domaines), on est obligé à
passer par des prototypes ; ou bien, le client ne sait pas
exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou
bien, le domaine est assez expérimental, et on ne sait pas ce qu'il
faut nous même. Mais même ces prototypes ont une phase de
conception.
Le probleme chez nous, c'est que le client meme s'il ne sait pas ce
qu'il veut le veut pour hier... et accepte plus ou moins bien de se
servir du prototype -- c'est la seule solution pour resoudre son
probleme d'aujourd'hui. On le lui vends donc parce que sinon c'est le
concurrent qui le fera. Dans ce domaine, les start-up, c'est un moyen
de faire developper les prototypes en paralleles. Au final,
generalement celles qui ont choisit la bonne approche se font
racheter, rarement une emerge et grossit assez. Faire la version
finale est inutile: les problemes auront changes... donc on solidifie
comme on peut, on agrege differentes solutions et on sait que dans
deux ans on rachetera quelque chose.
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
Parfois (souvent même, dans certains domaines), on est obligé à passer par des prototypes ; ou bien, le client ne sait pas exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou bien, le domaine est assez expérimental, et on ne sait pas ce qu'il faut nous même. Mais même ces prototypes ont une phase de conception.
Le probleme chez nous, c'est que le client meme s'il ne sait pas ce qu'il veut le veut pour hier... et accepte plus ou moins bien de se servir du prototype -- c'est la seule solution pour resoudre son probleme d'aujourd'hui. On le lui vends donc parce que sinon c'est le concurrent qui le fera. Dans ce domaine, les start-up, c'est un moyen de faire developper les prototypes en paralleles. Au final, generalement celles qui ont choisit la bonne approche se font racheter, rarement une emerge et grossit assez. Faire la version finale est inutile: les problemes auront changes... donc on solidifie comme on peut, on agrege differentes solutions et on sait que dans deux ans on rachetera quelque chose.
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
Jean-Marc Bourguet
writes:
Je dirais que si tu penses qu'on a le droit d'affecter this, je me pose des questions sur ta maîtrise des bases:-).
Moi je me dirais que tes connaissances commencent a dater tres serieusement... :-)
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
kanze@gabi-soft.fr writes:
Je dirais que si tu penses qu'on a le droit d'affecter this, je
me pose des questions sur ta maîtrise des bases:-).
Moi je me dirais que tes connaissances commencent a dater tres
serieusement... :-)
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
Je dirais que si tu penses qu'on a le droit d'affecter this, je me pose des questions sur ta maîtrise des bases:-).
Moi je me dirais que tes connaissances commencent a dater tres serieusement... :-)
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
Gabriel Dos Reis
writes:
[...]
| > > Ça ressemble un peu l'histoire des millions de singes qui | > > tappent au hazard au clavier, pour écrire Shakespeare. | | > Personne n'a parlé de coder au hasard (c'est a dire sans | > savoir ce que l'on veut coder). Il est juste question de | > vérifier le plus tot possible que ce que l'on a imaginé | > fonctionne réellement. | | Je sais, et je caractèrisais. Mais l'idée y est, en quelque | sort.
Hmm, tu caractérisais ou tu caricaturais ?
-- Gaby
kanze@gabi-soft.fr writes:
[...]
| > > Ça ressemble un peu l'histoire des millions de singes qui
| > > tappent au hazard au clavier, pour écrire Shakespeare.
|
| > Personne n'a parlé de coder au hasard (c'est a dire sans
| > savoir ce que l'on veut coder). Il est juste question de
| > vérifier le plus tot possible que ce que l'on a imaginé
| > fonctionne réellement.
|
| Je sais, et je caractèrisais. Mais l'idée y est, en quelque
| sort.
| > > Ça ressemble un peu l'histoire des millions de singes qui | > > tappent au hazard au clavier, pour écrire Shakespeare. | | > Personne n'a parlé de coder au hasard (c'est a dire sans | > savoir ce que l'on veut coder). Il est juste question de | > vérifier le plus tot possible que ce que l'on a imaginé | > fonctionne réellement. | | Je sais, et je caractèrisais. Mais l'idée y est, en quelque | sort.
Hmm, tu caractérisais ou tu caricaturais ?
-- Gaby
Gabriel Dos Reis
Fabien LE LEZ writes:
| Bon, il est vraiment temps que j'arrête de dire des conneries sur | Usenet et que j'aille au lit :-
Bonne nuit.
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| Bon, il est vraiment temps que j'arrête de dire des conneries sur
| Usenet et que j'aille au lit :-
| Bon, il est vraiment temps que j'arrête de dire des conneries sur | Usenet et que j'aille au lit :-
Bonne nuit.
-- Gaby
Olivier Azeau
wrote:
En gros, dans mes propres développements, je compte à peu près 60% du temps à la conception, 30% au codage (ce qui comprend le codage des tests), et 10% sur la mise au point et la correction des erreurs. D'après mon expérience, réduire la conception en dessous des 60% amène à une augmentation du temps total de développement.
Donc, sur un petit projet de trois moins, on compte environ 8 semaines avant de commencer le codage. Si on commence au bout de 4 semaines, le même projet risque de durer quatre ou cinq mois, avec une mise au point importante (deux ou trois mois, plutôt qu'une semaine).
Oui, mais tout ça ne peut éventuellement fonctionner que si les besoins sont entièrement exprimés dès le départ et qu'ils ne bougent pas.
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...
kanze@gabi-soft.fr wrote:
En gros, dans mes propres développements, je compte à peu près
60% du temps à la conception, 30% au codage (ce qui comprend le
codage des tests), et 10% sur la mise au point et la correction
des erreurs. D'après mon expérience, réduire la conception en
dessous des 60% amène à une augmentation du temps total de
développement.
Donc, sur un petit projet de trois moins, on compte environ 8
semaines avant de commencer le codage. Si on commence au bout de
4 semaines, le même projet risque de durer quatre ou cinq mois,
avec une mise au point importante (deux ou trois mois, plutôt
qu'une semaine).
Oui, mais tout ça ne peut éventuellement fonctionner que si les besoins
sont entièrement exprimés dès le départ et qu'ils ne bougent pas.
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...
En gros, dans mes propres développements, je compte à peu près 60% du temps à la conception, 30% au codage (ce qui comprend le codage des tests), et 10% sur la mise au point et la correction des erreurs. D'après mon expérience, réduire la conception en dessous des 60% amène à une augmentation du temps total de développement.
Donc, sur un petit projet de trois moins, on compte environ 8 semaines avant de commencer le codage. Si on commence au bout de 4 semaines, le même projet risque de durer quatre ou cinq mois, avec une mise au point importante (deux ou trois mois, plutôt qu'une semaine).
Oui, mais tout ça ne peut éventuellement fonctionner que si les besoins sont entièrement exprimés dès le départ et qu'ils ne bougent pas.
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...
Olivier Azeau
Jean-Marc Bourguet wrote:
writes:
Parfois (souvent même, dans certains domaines), on est obligé à passer par des prototypes ; ou bien, le client ne sait pas exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou bien, le domaine est assez expérimental, et on ne sait pas ce qu'il faut nous même. Mais même ces prototypes ont une phase de conception.
Le probleme chez nous, c'est que le client meme s'il ne sait pas ce qu'il veut le veut pour hier... et accepte plus ou moins bien de se servir du prototype -- c'est la seule solution pour resoudre son probleme d'aujourd'hui. On le lui vends donc parce que sinon c'est le concurrent qui le fera. Dans ce domaine, les start-up, c'est un moyen de faire developper les prototypes en paralleles. Au final, generalement celles qui ont choisit la bonne approche se font racheter, rarement une emerge et grossit assez. Faire la version finale est inutile: les problemes auront changes... donc on solidifie comme on peut, on agrege differentes solutions et on sait que dans deux ans on rachetera quelque chose.
prototype : du grec protos "premier" et typos "empreinte, marque"
Comment définissez-vous donc "prototype" dans un tel contexte de développement logiciel ? 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.
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.
Jean-Marc Bourguet wrote:
kanze@gabi-soft.fr writes:
Parfois (souvent même, dans certains domaines), on est obligé à
passer par des prototypes ; ou bien, le client ne sait pas
exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou
bien, le domaine est assez expérimental, et on ne sait pas ce qu'il
faut nous même. Mais même ces prototypes ont une phase de
conception.
Le probleme chez nous, c'est que le client meme s'il ne sait pas ce
qu'il veut le veut pour hier... et accepte plus ou moins bien de se
servir du prototype -- c'est la seule solution pour resoudre son
probleme d'aujourd'hui. On le lui vends donc parce que sinon c'est le
concurrent qui le fera. Dans ce domaine, les start-up, c'est un moyen
de faire developper les prototypes en paralleles. Au final,
generalement celles qui ont choisit la bonne approche se font
racheter, rarement une emerge et grossit assez. Faire la version
finale est inutile: les problemes auront changes... donc on solidifie
comme on peut, on agrege differentes solutions et on sait que dans
deux ans on rachetera quelque chose.
prototype : du grec protos "premier" et typos "empreinte, marque"
Comment définissez-vous donc "prototype" dans un tel contexte de
développement logiciel ?
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.
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.
Parfois (souvent même, dans certains domaines), on est obligé à passer par des prototypes ; ou bien, le client ne sait pas exactement ce qu'il veut, et il faut lui montrer les alternatifs, ou bien, le domaine est assez expérimental, et on ne sait pas ce qu'il faut nous même. Mais même ces prototypes ont une phase de conception.
Le probleme chez nous, c'est que le client meme s'il ne sait pas ce qu'il veut le veut pour hier... et accepte plus ou moins bien de se servir du prototype -- c'est la seule solution pour resoudre son probleme d'aujourd'hui. On le lui vends donc parce que sinon c'est le concurrent qui le fera. Dans ce domaine, les start-up, c'est un moyen de faire developper les prototypes en paralleles. Au final, generalement celles qui ont choisit la bonne approche se font racheter, rarement une emerge et grossit assez. Faire la version finale est inutile: les problemes auront changes... donc on solidifie comme on peut, on agrege differentes solutions et on sait que dans deux ans on rachetera quelque chose.
prototype : du grec protos "premier" et typos "empreinte, marque"
Comment définissez-vous donc "prototype" dans un tel contexte de développement logiciel ? 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.
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.
Fabien LE LEZ
On 02 Feb 2005 17:53:44 +0100, Gabriel Dos Reis :
Bonne nuit.
Merci.
-- ;-)
On 02 Feb 2005 17:53:44 +0100, Gabriel Dos Reis
<gdr@integrable-solutions.net>:
En gros, dans mes propres développements, je compte à peu près 60% du temps à la conception, 30% au codage (ce qui comprend le codage des tests), et 10% sur la mise au point et la correction des erreurs. D'après mon expérience, réduire la conception en dessous des 60% amène à une augmentation du temps total de développement.
Donc, sur un petit projet de trois moins, on compte environ 8 semaines avant de commencer le codage. Si on commence au bout de 4 semaines, le même projet risque de durer quatre ou cinq mois, avec une mise au point importante (deux ou trois mois, plutôt qu'une semaine).
Oui, mais tout ça ne peut éventuellement fonctionner que si les besoins sont entièrement exprimés dès le départ et qu'ils ne bougent pas.
Il n'exclut pas une certaine souplesse.
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...
Ça dépend des modifications qu'il démande, et la souplesse dans la conception initiale. Certes, on ne peut pas tout prévoir, et il arrivera bien des démandes de modifications qu'on ne peut prendre en compte qu'à prix de récommencer la conception. Mais avec un peu de prévoyance, on arrivera à prendre en compte la majorité des modifications sans trop de problème.
(Ceci suppose, évidemment, qu'on connaît le domaine de l'application, et qu'on sait donc prévoyer les types de modifications probables.)
-- 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
Olivier Azeau wrote:
kanze@gabi-soft.fr wrote:
En gros, dans mes propres développements, je compte à peu
près 60% du temps à la conception, 30% au codage (ce qui
comprend le codage des tests), et 10% sur la mise au point
et la correction des erreurs. D'après mon expérience,
réduire la conception en dessous des 60% amène à une
augmentation du temps total de développement.
Donc, sur un petit projet de trois moins, on compte environ
8 semaines avant de commencer le codage. Si on commence au
bout de 4 semaines, le même projet risque de durer quatre ou
cinq mois, avec une mise au point importante (deux ou trois
mois, plutôt qu'une semaine).
Oui, mais tout ça ne peut éventuellement fonctionner que si
les besoins sont entièrement exprimés dès le départ et qu'ils
ne bougent pas.
Il n'exclut pas une certaine souplesse.
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...
Ça dépend des modifications qu'il démande, et la souplesse dans
la conception initiale. Certes, on ne peut pas tout prévoir, et
il arrivera bien des démandes de modifications qu'on ne peut
prendre en compte qu'à prix de récommencer la conception. Mais
avec un peu de prévoyance, on arrivera à prendre en compte la
majorité des modifications sans trop de problème.
(Ceci suppose, évidemment, qu'on connaît le domaine de
l'application, et qu'on sait donc prévoyer les types de
modifications probables.)
--
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
En gros, dans mes propres développements, je compte à peu près 60% du temps à la conception, 30% au codage (ce qui comprend le codage des tests), et 10% sur la mise au point et la correction des erreurs. D'après mon expérience, réduire la conception en dessous des 60% amène à une augmentation du temps total de développement.
Donc, sur un petit projet de trois moins, on compte environ 8 semaines avant de commencer le codage. Si on commence au bout de 4 semaines, le même projet risque de durer quatre ou cinq mois, avec une mise au point importante (deux ou trois mois, plutôt qu'une semaine).
Oui, mais tout ça ne peut éventuellement fonctionner que si les besoins sont entièrement exprimés dès le départ et qu'ils ne bougent pas.
Il n'exclut pas une certaine souplesse.
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...
Ça dépend des modifications qu'il démande, et la souplesse dans la conception initiale. Certes, on ne peut pas tout prévoir, et il arrivera bien des démandes de modifications qu'on ne peut prendre en compte qu'à prix de récommencer la conception. Mais avec un peu de prévoyance, on arrivera à prendre en compte la majorité des modifications sans trop de problème.
(Ceci suppose, évidemment, qu'on connaît le domaine de l'application, et qu'on sait donc prévoyer les types de modifications probables.)
-- 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
