Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

27/02/2009

Shanghai – San Francisco

Alors, c’est un peu long à tout expliquer, mais à priori, je pars deux semaines en Chine à Shanghai en milieu de semaine prochaine, puis j’enquille une semaine aux US pour la GDC. En passant à Paris entre, évidemment.

 

Humm, trois continents en trois semaines… O_o

 

J’espère avoir le temps de blogger un peu, même si je doute de pouvoir traiter les sujets à fond. Je mettrai des photos ;-)

 

En tout cas, si vous êtes à Shanghai ou à San Francisco des ces eaux là, c’est l’occasion ou jamais de ma payer un verre. ^_^

17:19 Publié dans Nexus | Lien permanent | Commentaires (10)

24/02/2009

Les 10 commandements de Capcom ?

Evidemment, une semaine après que j’ai exprimé ma défiance vis-à-vis des listes et autres recettes, Capcom sort sa liste des 10 commandements qui gouvernent sa stratégie.  Bah, au moins maintenant je sais que les dirigeants de Capcom ne lisent pas ce blog ^_^

 

 

 

Blague à part, voyons voir ce que ces 10 principes peuvent nous apprendre concrètement sur ce qu’est Capcom aujourd’hui, si tant est que Capcom s’en tire en effet pas si mal que ça ces derniers temps.

 

 

 

1. Keep staff turnover below 10 percent per annum.

 

 

 

Le premier point porte donc sur la notion de ressource humaine. Je pense l’avoir déjà dit, mais un jeu, c’est d’abord et avant tout une aventure humaine. C’est la première ressource, la plus importante, loin devant les impératifs techniques ou organisationnels.

 

 

 

Dans ce cadre, le cout caché du turnover est donc immense, et fréquemment sous évalué. La volonté de limiter ce cout, même s’il n’est que vœux pieux, est donc une simple stratégie de bon sens.

 

 

 

Une chose me semble a peu prêt sure : peu de gros studios / éditeurs dans notre industrie peuvent se targuer d’un chiffre aussi bas.

 

 

 

2. Maintain the ability (and cash reserves) to increase personnel by 10 percent each year.

 

 

 

Ca déjà, c’est plus discutable. S’il semble sensé de tout faire pour conserver un maximum de flexibilité en termes de ressources humaines et financières, je ne vois pas forcément l’expansion du personnel comme étant un but en soi.

 

 

 

Non, ce que je comprends, c’est plutôt que l’entreprise doit pouvoir grossir de 10% si besoin est. Pouvoir financer un overhead de 10% pour atteindre les objectifs, ca me semble déjà plus logique.

 

 

 

3. Keeping the firs two points in mind, keep development cost fluctuation within 10%.

 

 

 

Encore du bon sens, mais là, on est dans le domaine de la gestion pure et dure. Ce qui serait vraiment intéressant de savoir, c’est comment Capcom fait pour maintenir cette limite.

 

 

 

4. Investment in new IP needs ot be kept within 20% of total development budget. (Takeuchi feels this is unique to Capcom, which has tried hard with “Dead Rising,” “Lost Planet,” and “Zack and Wiki.”)

 

 


20% de nouvelles IPs, ça peut sembler peu, mais en fait c’est déjà un chiffre énorme. Et il suffit  de repenser aux difficultés auxquelles de nombreux éditeurs doivent faire face pour les commercialiser pour comprendre pourquoi c’est un sujet aussi sensible.

 

 

 

Je reviendrai sur ce sujet bientôt…

 

 

 

5. The structure and organization of the company needs the flexibility to change in response to growth, goals and objectives must constantly be reviewed.

 

 

 

Management 101. Bon, je me moque bien sur, car le besoin de revu continuelle des objectifs et des résultats est bien sur évident. En ce moment, j’ai l’intuition que le secteur est un énorme terrain de sables mouvants. Avoir un minimum de vigilance, c’est le minimum requis pour ne pas se réveiller avec du sable jusqu'à la taille.

 

 

 

6. Goals and objectives must be adaptable to external forces. (Takeuchi cited as a positive example, Square-Enix moving the “Dragon Quest” series to the Nintendo DS.)

 

 

 

C’est une illustration bien sur du point précédent, et un point fort chez Square. Square sait que son cœur de métier, c’est le jeu. Ils vont donc là où le public se trouve, en l’occurrence sur la DS.

 

 

 

7. Objectives and aims must always be set from the top down. (Takeuchi: “When a problem occurs in a development company it almost always comes from the developers… having the developers work from the bottom up to reform how they do things things, management must also maintain flexibility.”)

 

 

 

C’est un peu trop générique pour en tirer grand chose. Il semble évident que dans toutes entreprises, si la direction ne sait pas ce qu’elle veut ou dans quelle direction aller, il y a peu d’espoir d’arriver à quoi que ce soit.

 

 

 

Mais ça mérite d’être approfondi dans un prochain post.

 

 

 

8. Reform must always be undertaken from the bottom up.

 

 

 

Parler de réformes, c’est déjà admettre qu’on a besoin de se reformer. Ce n’est pas tout le monde qui est prêt à le faire ^_^

 

 

 

Ceci dit, il me semble vrai que tout effort « transformatif » fonctionne mieux de bas en haut que l’inverse. Nous sommes tous relativement conservateur, plus que l’on aimerait l’admettre. Arriver alors à obtenir l’adhésion de son équipe à un nouveau projet, à de nouveaux processus, à une nouvelle façon de faire, c’est difficile et potentiellement risqué.

 

 

 

Difficile mais nécessaire.

 

 

 

9. There should be no taboo areas when it comes to reform. Reform must be undertaken at all costs. (Takeuchi said this was learned from Toyota. Problems within the developers and development team would be most costly, so management and workers need to learn to work and change together.)

 

 

 

La notion de tabou aussi est réelle dans toute structure. Il y a pleins de cadavres dans les placards des cultures d’entreprises, mais aussi des lubies, des blocages, des peurs exprimées ou pas, des dénis de réalité. Ca peut sembler négatif quand on les liste comme ça, mais c’est aussi une force, la part irrationnel dans une équipe.

 

 

 

Est-ce que les tabous sont à la source des problèmes de transformations ? Ca, je ne sais pas…

 

 

 

10. Don’t set unachievable targets

 

 

 

Encore du bon sens, mais mon petit doigt me dit que les structures et les projets pharaoniques ont eues leurs heures de gloires de toute façon. Plus que jamais, small is beautifull and smart is better than strong.

 

 

 

Mais bon, pour conclure, j’insiste: rien ne peut préparer à gérer une équipe dans la production d’un bien immatériel. Il n’y a pas de formules, juste des gens qui fonctionnent ensembles… ou pas.

 

 

 

Je pense qu’avant même d’avoir une stratégie qui fonctionne, ce qui fait le succès de Capcom, c’est d’avoir su mettre les bonnes personnes aux bons endroits, et d’avoir su capitaliser sur leurs énergies, leurs cultures et leurs savoirs-faires….

13:27 Publié dans Business | Lien permanent | Commentaires (12)

19/02/2009

Most Played: Flower

Wooh, je l'ai déjà fini 3 fois, alors si vous avez une PS3, ne laissez pas passer ce jeu !!!

 

 

site_flower-ss-13.jpg
flower-20070920032058314_640w.jpg



13:00 Publié dans Jeux | Lien permanent | Commentaires (5)

18/02/2009

Sales is vanity, profit is sanity

Slate reviens sur ce que l'on sait tous plus ou moins depuis déjà longtemps: à l'heure actuelle, les jeux AAA coutent trop chers à produire. Morceaux choisis:

 

...


So how can publishers lose money amid such incredible sales and record growth? The answer is simple: They're spending more than they're bringing in. Game development budgets have ballooned, and publishers are reeling because they can't keep the costs under control.


...


While industry leaders anticipated that budgets would creep higher, the shift to high-definition gaming with Microsoft's Xbox 360 and Sony's PlayStation 3 has proved to be more expensive than estimated. At a conference in the spring of 2006, then-Midway developer Cyrus Lum sounded the warning, telling his audience that game development budgets could rise as high as $15 million to $25 million for a single title—previously unheard-of averages. "We need to rethink how we're financing games," Lum concluded.


When a newspaper quoted this frightening view, Lum found himself in hot water with his employer for making such sensationalist comments. It turned out that Lum's prediction was too low: Midway would go on to spend between $40 million and $50 million developing This Is Vegas, an action title set for release in late 2009.


...


The industry has long discussed going with this "Hollywood model," in which a few games/movies turn a profit, those hits more than covering the other losses. The analogy between the Hollywood blockbuster model and the games business falls apart, however, because of the huge difference in overhead costs.

 

Electronic Arts steadily employs 7,400 developers. The industry standard is a $10,000 man-month, meaning the company burns through more than $74 million for development each month.

 

The big Hollywood studios, by contrast, make movies by giving money to temporary production companies, which then hire temporary crews with one-project contracts. The temporary entity will make the film from start to finish. And once production is complete, the studio receives a finished product that it can distribute to theaters—without the continued overhead expenses that game publishers often face.


...


It's unrealistic for a company that employs many thousands of developers to abandon internal production immediately. In the short term, Electronic Arts should consider copying the old Hollywood "studio system."

 

During the Great Depression, a movie could be made in two weeks—and people would go to see a new movie each week. EA could make games that cost less. How? Change the scale and scope of the world. Make the story shorter. Use lower-quality graphics. Recycle proven tools and technology.


[ Slate ]

13:10 Publié dans Business | Lien permanent | Commentaires (2)

17/02/2009

La création dans l’industrie du jeu vidéo

Hé, suite à un tips de Pedro, je suis tombé sur cette étude du Département des études de la prospective et des statistiques (DEPS - Ca s'invente pas!).

 

En générale, j'ai plutôt tendance à me méfier de ce genre de documents, mais une fois n'est pas coutume, celui ci est plutôt bien foutu. Bon, Il y a plein de points d'accroches de ci de là, il est bien trop verbeux, mais on peut s'en servir de point de départ pour argumenter certains problèmes auxquels nous faisont face...

 

La filière du jeu vidéo a atteint une maturité dont témoignent une troisième génération de créateurs et l’apparition de nombreux studios de développement. La création joue un rôle essentiel dans cette filière pour permettre un renouvellement de la production de jeux qui tire parti de potentialités techniques en constant développement et de formes renouvelées de jouabilité.

 

Or la création, par ses formes collectives d’organisation au sein des studios et du fait de ses coûts et de ses risques, peine à être reconnue au sein d’une industrie mondialisée où le poids des consoliers et des éditeurs est particulièrement important.

 

Ce sont donc les formes de reconnaissance de cette création (statut, rémunération, organisation sociale, etc.) qui sont explorées dans la perspective de rendre pérenne sa vitalité et, partant, celle du secteur vidéo-ludique en France.

 

[ DEPS ]

14:02 Publié dans Business | Lien permanent | Commentaires (1)

Technical Debt

La notion de dette technique n'est pas nouvelle : à chaque fois que l'entreprise prend une décision de design ou d'implémentation technique sous le coup de facteur externe (temps, coût) au lieu de facteurs internes (qualité, maintenance), l'entreprise contracte en pratique une dette technique.

 

Dans le contexte de la production d'un jeu vidéo, la dette technique recouvre donc tous les détails d'implémentation qui n'ont pas été correctement exécuté. Les hacks, les hiérarchies de classes vite faites, les structures de données mal pensé, les opportunités d'optimisation ratées, mais aussi les lourdeurs dans le pipeline de production, le pis aller dans le choix des outils de productions (CVS au lieu de Perforce par exemple), etc etc….

 

C'est un sujet sensible pour beaucoup de programmeurs, si tant est que nous sommes quotidiennement poussés à aller à l'opposé de notre intuition pour satisfaire les impératifs stratégiques de l'entreprise.

 

Pour autant, il n'y a rien de mal à cumuler la dette technique, du moment qu'elle est proprement géré. Comme toutes dettes, si on ne garde pas l'œil dessus, elle fini par affaiblir le studio en le rendant de moins en moins compétitifs.

 

Il est donc vital de connaître l'ampleur de la dette, afin de ne pas se retrouver dans des situations délicates. Comme toute dette, la dette technique à un cout et des intérêts conséquents.

 

Plus votre base de code est endetté, moins il est facile de la maintenir, et par conséquent il est de plus en plus difficile de démarrer de nouveaux projets. De même, votre process de production est de plus en plus lent, nuisant par conséquence à la productivité de l'équipe et donc à la compétitivité du studio.

 

Pour finir, la dette rend la société fragile à la notion d'information technique informelle. La dette nécessite un effort continu de documentation, qui n'est souvent pas faite correctement. Au fur et à mesure que les techniciens et programmeurs quittent l'entreprises pour de plus verts pâturages (meilleurs payes, moins de nuits blanches pour gérer les problèmes liés à la dette), les éléments mal conçus deviennent de plus en plus obscurs, absconds, et difficile à résoudre.

 

La dette s'élève mécaniquement, relevant de la même logique que le crédit revolving.

 

Il existe des outils pour gérer la dette. L'effort de réécriture (refactoring) est un investissement permettant de réduire la dette. De même, prendre le temps d'évaluer les outils de productions (de perforce au compilateur en passant par les outils de communication interne) permet aussi de réduire la dette.

 

En tant que technicien, Il nous appartient de savoir comment évaluer la dette construite dans une base de code. La dette, c'est du risque, et on nous paye aussi pour réduire les risques.

 

Mais il faut reconnaître aussi que la dette est un outil. Il faut savoir quand et dans quels conditions il est parfaitement légitime de cumuler de la dette. L'impératif premier de toute entreprise, c'est la survie. Et la survie, c'est d'abord faire des ventes.

 

Le seul souci est donc de s'assurer que le coût pernicieux de la dette technique de revienne pas manger vos profits quelques années après avoir commencé…

13:00 Publié dans Business | Lien permanent | Commentaires (0)

15/02/2009

There is no silver bullet...

Malgré ce que l'on veut bien essayer de nous faire croire, il n'y a au fond pas de solutions magiques, de méthodologies ultimes, de croyances 'vrai', de façon de faire, de techniques infaillibles, de recettes inratables, etc etc

 

Juste un rappel ^_^

14:21 Publié dans Idées | Lien permanent | Commentaires (5)

13/02/2009

Project Portfolio

Beaucoup de studios sont mono projets, et en fait, peu de studios peuvent mener de front plusieurs projets. D’ailleurs, ça n’est pas forcément désirable.



En premier lieu, en dessous d’un certain nombre de projets, il est très difficile de faire de réelles économies d’échelles sur la production (et non, 2 productions en parallèle, je ne crois pas que ça soit suffisant pour faire des économies d’échelles substantielles).



De plus, de façon assez légitime, un éditeur souhaite avoir le meilleur de vos capacités de productions sur son titre. Il est donc très rare de pouvoir détacher des ressources d’un projet à un autre sans faire tiquer votre producteur externe.



Du coup, la norme, c’est plutôt de voir les studios commencer à investir dans l’avenir de façon plus ou moins tardive. L’assèchement du flot de revenue entre projets transforme souvent ces moments en véritable traversée du désert.



Economiquement parlant, l’entreprise se retrouve prise entre l’étau des négociations avec les éditeurs qui sont en général plutôt longues, et la masse des charges sociales qui ne souffrent que très peu de flexibilités.



Comment éviter ses situations délicates ? En règle générale, ayant souvent peu de traction sur les éditeurs, c’est la masse salariale qui paye le prix.



Et de facto, beaucoup d’entreprises choisissent de réduire leur voilure, d’où le recours parfois disproportionné aux intermittents, CDD, stagiaire, etc etc, pour combler les besoins de la production sans impacter durablement les charges sociales.



Jusqu'à présent, ça marchais plutôt pas trop mal. Il était en effet rare d’avoir besoin de toute une équipe pour designer, prototyper et pitcher de nouveaux projets.



Mais cette logique a un coup d’opportunité assez conséquent. A chaque itération du cycle de production, les meilleurs éléments finissent forcément par être capter par la concurrence (en France, CDI vs CDD, le choix est en principe vite fait). L’absence de stabilité du personnel nuit également à l’établissement et a la maintenance des processus de production. De même, l’expérience acquise aux cours de la production est en général perdue.



De plus, pitcher un projet requiert en fait de plus en plus de ressource. Il y a 10 ou 15 ans, il n’était pas rare de signer un prototype juste à l’aide d’un document et des membres de l’équipe principale. De nos jours, ça marche peut être encore pour des titres de moindres envergures, mais pour les jeux consoles, la démo jouable semble être inévitable, cette démo pouvant même aller jusqu'au vertical slice complet.



Bref, les dividendes de cette stratégie sociale sont de plus en plus dilués.



L’autre façon de réduire ces temps de vaches maigres, c’est donc de réduire la durée des négociations. A priori, il y a deux mots clefs pour réussir ce processus : anticipation –commencer de plus en plus tôt à préparer les projets et à entamer les négociations - et qualité – s’assurer d’avoir les meilleurs projets possibles.



La notion de portfolio de projets permet d’adresser ces deux priorités. Il s’agit d’établir et de valider le plus tôt possible un certain nombre de projets de jeu avec le moins de ressource possible. Un projet, ce n’est pas qu’un design, un concept, des démos. C’est aussi une étude des éditeurs potentiellement intéressé, la recherche des conditions de marchés, l’information stratégique sur le processus décisionnel des éditeurs, les techniques de productions nécessaires d’acquérir ou de développer, etc etc.



En utilisant une approche de type « kill gate », vous pouvez faire grossir votre portfolio en l’étoffant où en raffinant progressivement chaque itération. Qualitativement parlant, le portfolio permet aussi de prendre le temps nécessaire pour élaborer le meilleur produit possible.



Le portfolio permet aussi d’aller chercher des opportunités qui ne sont pas forcément dans votre cœur de métier. Epic, ID ou Valve vendent le moteur qui sert pour leur jeu par exemple. Valve va plus loin, puisqu’avec Steam ils ont établies leur propre canal de distribution. D’autres studios vont chercher des projets chez des institutionnels (l’exemple de Blitz me vient à l’esprit). D’autres encore en profitent pour se mouiller les pieds sur le Xbox live ou le Psn. Les opportunités sont multiples.



Et en termes de ressource, stretcher la construction du portfolio le long de la production du projet courant permet de profiter des divers effets d’aubaine attaché à cette même production.



Une production, c’est un processus qui respire, avec des besoins en ressource humaine qui changent tout du long. Du coup, il est souvent possible de faire travailler certains membres de l’équipe sur les projets du portfolio, les corps de métiers disponibles variant selon la phase de la production.



Ca devient aussi un moyen de mobiliser l’énergie des troupes, en leur offrant parfois une bulle d’air après une milestone difficile. C’est peut être aussi l’opportunité de faire grandir en expérience votre équipe, en leur permettant de contribuer de façon créative au portfolio



Après tout, une fois lancée dans la production d’un jeu avec un planning de paiement par milestone, le projet - en tant qu’effort de prospection - deviens de facto la passé pour le studio. Non pas que la production n’est pas importante – au contraire même – mais le risque économique de ne pas pouvoir subvenir aux charges deviens moindre, car subordonné à la capacité de votre studio à réussir vos milestones.



Bien sur, votre éditeur peut changer d’avis à tout moment, mais ça ne rend que d’autant plus importante la gestion du portfolio de projets.



Pour conclure, c’est une approche que je vois mise en place de plus en plus souvent, et qui semble avoir aidé pas mal de studios à devenir plus résiliente aux aléas de l’économie. Et vous, quels est votre expérience avec ce type de stratégie ?

13:00 Publié dans Business | Lien permanent | Commentaires (14)

09/02/2009

Script visu-hell

Il y a bientôt presque 10 ans, j’étais en stage à Annecy sur un jeu révolutionnaire pour l’époque : il était scripté à l’aide d’un langage de script partiellement visuel qui s’appelait Piccolo.

 

De nos jours, cette notion de script visuel se retrouve dans pleins de moteurs, Kismet d’UE3 étant l’exemple le plus populaire.

 

 

kismet_2.jpg

 

La dernière fois que j’ai abordé le sujet des éditeurs visuels, c’était pour parler de shaders. Pour être précis, c’était pour se poser la question du bien fondé des éditeurs de shaders visuels.

 

Mais l’idée de scripter visuellement un comportement va bien plus loin que la simple notion de shader. On trouve désormais ces éditeurs aussi bien pour scripter des cinématiques, que des événements dans le jeu, ou pour scripter des IA.

 

D’où viens cette évolution ?

 

Le succès de la notion de langage informatique repose sur les milliers d’années d’évolution du langage humain. En simplifiant à l’extrême, le langage est et reste la technologie la plus avancé pour encoder et transmettre de l’information.

 

Nous utilisons donc des langages de programmation non pas parce que nos machines s’y prêtent particulièrement, mais plutôt parce que nous humains somment des machines incroyablement performantes pour manipuler le langage.

 

Alors, si le langage est la technologie la plus poussé pour manipuler et définir des scripts, d’où viens le besoin de définir des outils graphiques pour faire le même travail ?

 

Le principal problème avec les langages est que le sens de ce qui est exprimé est hautement dépendant du contexte. En d’autre terme, le sens perçus dépend non seulement de la personne qui écrit (l’auteur) et de la personne qui écoute (le lecteur), mais aussi de ce qui a été écris auparavant.

 

En ce qui concerne les langages informatiques, le sens est en règle générale univoque : la machine exécute le code qui a été compilé à partir des textes sources, point barre. Là où le bat blesse, c’est que ce qui a été compilé ne correspond pas forcément à ce que le programmeur pense.

 

Les langages de programmations sont complexes parce que l’ordre d’exécution des instructions n’est pas trivial. Quand on écrit un programme, il ne s’agit pas d’écrire un roman dans lequel chaque chapitre va se suivre les uns après les autres.

 

De plus, la capacité à lire ou à écrire du code source dépend de la capacité de l’opérateur à intégrer non seulement les idiomes du langage, mais aussi le contexte du code en question (ce qui a été exécuté avant, ce qui va être exécuté après, ce qui est attendu en entré et ce qui doit être produit). Le programmeur pour ce faire doit construire un modèle mental du fonctionnement du programme à l’aide du code exprimé dans le langage de programmation.

 

Et ça, c’est dur. Mais alors, vraiment vraiment dur. Et c’est ici qu’entre en jeu la notion de langage visuel.

 

La grande majorité de ces langages visuels reposent sur la même anatomie : Un script visuel est constitué d’une collection de boites - correspondant à diverses actions/états, qui ont diverses entrées/sorties, et des paramètres internes – que l’on a connecté les unes aux autres. Ces boites peuvent parfois s’imbriquer dans des boites conteneurs façon poupées russes.

 

Les scripts ainsi conçus définissent tantôt des machines à états, tantôt des worlkflows, tantôt des graphes.

 

L’attrait principal de ces langages repose sur un principe simple : un dessin vaut mieux qu’un long discours. Et de fait, l’information sur un schéma est incroyablement plus accessible : d’un simple coup d’œil, on a accès à une masse d’informations qui nécessiterait un travail autrement plus ardu si on devait le déduire d’un texte.

 

De plus, il est beaucoup plus facile d’apprendre à lié des boites entre elles que d’apprendre à travailler avec un langage de programmation, n’est ce pas.

 

N’est ce pas ?

 

Tout cela est vrai, tant que les schémas produits sont bons. En fait, en pratique, voilà ce qui se passe.

 

La bonne idée atterrie dans les mains de quelqu’un qui n’est pas programmeur, en général quelqu’un avec un penchant un peu plus artistique, pour qui l’aspect visuel parle naturellement.

 

Cette personne développe des scripts bon an mal an pour définir le contenu du jeu.

 

Quelques mois plus tard, on vous appelle parce que ça « bug », et qu’il faut corriger les problèmes. Quand vous ouvrez le script dans l’éditeur visuel, vous vous retrouver devant un gloubigoulba indigeste de schèma façon spaghetti, avec des dépendances dans tout les sens et au bas mot 3 niveaux d’imbrications.

 

Bref, bienvenu(e) en enfer.

 

Alors, comment une aussi bonne idée peut elle s’avérer aussi dommageable ?

 

Le gain de productivité acquis par l’usage de ces langages visuels est réel. On va plus vite pour assembler visuellement des briques que quand on écrit. Mais la productivité n’est pas forcément positive – en d’autres termes vous pouvez parfaitement plomber un développement si vous ne faite pas attention.

 

Et c’est là le drame. Les langages de programmations sont équipés de toute une batterie d’outils pratiques ou conceptuels pour aider à assurer une productivité aussi positive que possible. Ces outils vont des débuggeurs à l’auto complétion en passant par l’analyse statique du code, les profilers, le développement orienté objet, les design patterns, les différents langages appropriés pour différentes taches, et j’en oublie une pelleté d’autre…

 

Des dizaines d’années de recherches et de développements ont été investis pour permettre au développeur d’aller dans la bonne direction autant que faire ce peux. A minima, ces outils permettent au langage en soi de ne pas devenir par essence un problème.

 

Les abstractions visuelles, elles, n’ont pas eu ce luxe. En somme, en abaissant la barrière de productivité, elles permettent surtout de produire plus facilement du code erroné.

 

Et ce problème n’est pas inhérent aux outils modernes d’un moteur de jeu vidéo. Les langages visuels se retrouvent dans tous les secteurs IT, avec les mêmes symptômes:

 


And in particular, the favorite demo-ware application is their BPEL (Business Process Execution Language) designer. This designer allows you to wire together services by drawing lines between boxes. The lines can include transformations and other sexiness. And it demos great. "Look, just draw a couple of lines here and here, click on the Run button and voila! Instant SOA".


Then, the manager brings it back home and notifies the developers that this is the new tool of choice. When developers start using it, they realize the awful truth: they've been sold a hairball generator. Tools like this work great on really small scales, when it's easy to see all the connections between things. But, as things get complicated, they start suffering from the hairball effect: all the lines start running together, and you can't create a diagram that makes sense to anyone anymore. Perhaps maybe you can fight through this, by creating workflows in chunks, and zooming in and out.


Then reality arrives. Because you create workflows using these tools, you are coding, in the worst possible language (a graphical representation). Thus, you are defining behavior, just like you do when you write source code. But the behavior you define lacks all the benefits you get from writing it in code.


· reuse: you can't really reuse portions of your workflow because their is no method or subroutine functionality (you might get lucky with a sub-workflow). Mostly, people achieve "reuse" by copy and pasting, which you never do in code.


· refactoring: no refactoring, making it harder to identify common workflow chunks for reuse. When you don't have refactoring, you don't watch for opportunities for refactoring as much.


· limited programmability: you don't get if statements and for loops, you get whatever this particular BPEL designer supports. You get flow-chartly looking stand-ins for real decision statements, but they are much more brittle than the facilities offered in modern languages.


· testing: you can't write unit, functional, or integration tests for these workflows. The only real testing option is user acceptance, meaning that the entire universe must be up and running. If you have no unit testing, you also don't have mock objects or other testing techniques common in code.


· hard to diff: lets say you fought the beast and get a non-trivial workflow up and running, and everything is great. In six months, you change it in non-trivial ways, and all is good. Then it comes time to see what's different. BPEL tools don't have diff facilities, so you can either visually diff the diagrams (yuck) or diff 2 10,000 line XML documents (double yuck). BPEL relies on either heavy-weight diagramming tools or raw XML, and nothing in between.


Tools like this fall into the category one of my colleagues identified as doodleware tools. They let you create pretty pictures but collapse under scale.


[ Meme Agora ]

 

Pour conclure, que doit on faire ? Les abstractions visuelles ont une utilité pratique, en particulier là où l’expressivité est un facteur important de la productivité. Difficile de s’en passer.

 

Quelques conseils :

 

- Limitez le scope de ces langages : Si on traite ces langages comme étant des DSL, il est parfaitement imaginable d’en limiter le domaine i.e. scripter un shader ou une machine a état oui, scripter toutes une cinématique, non. Pour les cinématiques, il y a de meilleurs outils (un séquenceur par exemple)

 

- Limitez l’expressivité du langage : Par exemple, vous pouvez parfaitement décider que toute entrée soit liée à une et une seule sortie. Créez des boites spécifiques pour créer des bifurcations par copie si c’est vraiment nécessaire, mais limiter ainsi le nombre de liens qui partent d’un seul point.

 

- Dotez vous d’outils permettant de debugger visuellement le flow : Attention, ce n’est pas une tache aisé. Dans un workflow traditionnel basé sur la notion d’événement, vous pouvez parfaitement passer dans plusieurs boites simultanément.

 

- Agissez en amont : Le comportement est plus facile à exprimer en langage parce que le langage est l’outil le plus puissant qu’il existe pour définir un comportement. Quiconque définit un comportement devient par essence un programmeur, avec tout ce que ça implique.

 

- Exploitez le gain de productivité: En cas de gros pépin, vous pouvez retourner l’avantage des langages visuels à votre profit très simplement. Faites recommencer à zéro le script en question, mais en étant ce coup ci en support de la personne qui l’a écrite à l’origine. Vous irez parfois plus vite à réécrire un script bugée à deux qu’a debugger un plat de spaghetti. Bonus : vous aurez peut être même une chance de faire mieux, plus simple, et plus esthétique.

 

Dans tout les cas, méfiez vous des outils magiques qui permettent de tout faire en connectant 3 boites : ces outils sont toujours merveilleux, géniaux, supers, etc etc… tant que les scripts ainsi écrits fonctionnent…

 

Sinon, ces fameux gains de productivités acquis pendant la production risquent bien de s’envoler en fumée quand le temps du debug viendra.

20:06 Publié dans Code | Lien permanent | Commentaires (2)

06/02/2009

Debug: Deja Insight

Ce n'est pas un secret que la condition d'une production réussi dépend majoritairement de la qualité du pipeline et des outils associées. Et de fait, beaucoup d'efforts sont consacrés aux exporteurs, éditeurs et autres outils de distribution des calculs.

 

Par contre, il y a un autre aspect qui est remarquablement peu souligné, c'est le debuggage. S'il est vrai que la plupart des constructeurs fournissent des outils pour debugger, profiler et tuner votre application, il n'en reste pas moins que ces outils interviennent souvent au plus bas niveau.

 

Nul autre mieux que vous sais ce que votre moteur est sensé faire, quels abstractions sont utilisés, comment votre VM fonctionne avec son language de script, comment est agencé votre mémoire etc etc.

 

Il y a une opportunité massive pour créer des outils qui font plus loin grace à la connaissance interne de votre architecture logique. Et c'est cette opportunité qui semble passé à la trappe un peu partout.

 

Comment d'outils de debug des allocations mémoires ont été écrites à l'arrache pour chasser un leak particulièrement vicieux ? Combien de façon de loguer des messages utiliser vous ? Humm ?

 

C'est dans ce point aveugle que s'engouffre Deja Insight:

 

What is Deja Insight? At its core, Insight is a logging system. But, Insight takes the ideas behind "logging" and pushes them to new and previously unexplored extremes. In addition to being an excellent logger, Insight includes functionality normally associated with debuggers, profilers, and various other development tools. All state information is tracked over the entire application execution history, thus allowing Insight to display the state of the heap or any instrumented object instance for any point in time. Furthermore, all data is cross referenced so Insight can, for example, display all log entries generated by a specific object instance.

 

[ Deja Tools ]

 

 

Heap_small.jpg

 

Alors, rendez vous service, et jetez un oeil à ces outils, ne serait ce que pour réver.

 

Et si vous n'êtes pas codeur, filer le lien à votre codeur préféré - si si, vous voyez très bien de qui je parle, celui que vous allez toujours voir quand vous avez un problème parce que même si c'est en dehors de son champ de compétence il trouvera une réponse pertinente. Toutes les boites en ont un (ou alors elles vont pas tarder d'avoir de gros problèmes).

04/02/2009

I Get You Fail ^_^

On a tous des merveilles qui dorment dans de vieux dossiers. Ca n'était qu'une question de temps avant que cela ne resurgissent sur le réseau ^_^

 

 

rainbow.jpg
CubemapDebugging.png
ErrorPartyShader.gif

[ I Get Your Fail ]

03/02/2009

Perma-crunch...

Le terme perma-crunch s'applique au mode de fonctionnement avec heures sup continues dans certaines structures ou sociétés.  Quand on est en perma-crunch, ce qui est l'exception devient la norme, et tout le monde bosse 12h par jour, 6 jours sur 7 (ou pire).

 

Dans certaines boites, ou pour certains individus, c'est même devenu une sorte de gloire, un badge d'acceptation, ou un mode de vie.

 

A priori, on y est tous plus ou moins exposé, et ce dans de multiples industries.

 

Dans de multiples industries ? Il faudra m'expliquer pourquoi une simple recherche google sur ce terme ne conduit que sur des pages lié à l'industrie du jeu... Sommes nous plus bavard que les autres ?

 

Quoi qu'il en soit, à l'heure tardive ou j'écris ce post, et surtout vu de l'endroit où je l'écris (eh oh, ça va, je compile!), je ne suis pas en position de dire quoi que ce soit ^_^

 

Si ce n'est qu'il me semble objectivement y avoir certaines taches qui sont délicates à diviser en blocs de 8H. Moi le premier, je reconnait la satisfaction d'avoir chasser un bug même après une longue session, et je connait la morsure du bug que l'on a pas pu résoudre dans une journée normale.

 

Assurèment, il y a un juste millieu à trouver. Si le perma-crunch est une imposture, la journée de 8H ne l'est elle pas aussi ?