Tous bureaucrates: Ainsi – et c’est la caractéristique principale d’une bureaucratie – la défense des territoires y devient un objectif plus important que l’intérêt général de l’entreprise, sa survie. Car ce rapport de force moyenâgeux entre services se superpose à la traditionnelle séparation entre penseurs et faiseurs, autre caractéristique des bureaucraties
Les métiers de l’informatique: En France, 77% des jeunes diplômés en informatique débuteraient ainsi leur entrée dans la vie professionnelle à partir d’une SSII, alors que seul 1 % de l’effectif des SSII quitterait l’entreprise pour cause de départ à la retraite (contre 10,4 % en moyenne)
LA PÉNURIE DE DÉVELOPPEURS: Altaïde rencontre aussi depuis deux ans les pires difficultés à trouver des développeurs sur les technos du web et mobile. Trouver des développeurs PHP, Java, .Net, IOS, Androïd ou RoR, pour ne citer que ces technos les plus demandées, c’est une débauche de moyens et d’énergies énorme.
The Rise of Developeronomics: We are only just beginning to understand how software is now the core function of every company, no matter what it makes or what service it actually provides.
4 Types of programmer: action heroes are mostly extreme agile developers, technical gurus, and junior developers.
Testing Will Challenge Your Conventions: “Clever” is dead. Clever is hard to refactor. Clever is hard to isolate, hard to internalize, hard to phrase in tests. One point of “obvious” is worth two hundred points of “clever”.
La tête dans les nuages Les mains dans le cambouis Les pieds sur la prod
La tête dans les nuages
Pas parce qu’il s’intéresse au cloud, mais parce qu’il doit prendre de la hauteur et du recul pour analyser, synthétiser et savoir restituer des vues adaptés à chacun des acteurs d’un projet. Il est le garant d’une vision partagée et cohérente des objectifs métiers stratégiques jusqu’aux déploiement des composants logiques sur des serveurs physiques ou virtuels.
Les mains dans le cambouis
L’architecte qui ne code plus (pire n’a jamais codé) a vite fait de s’envoler dans les nuages et de perdre le contact avec la réalité. De la vue aérienne d’un projet il doit pouvoir zoomer sur un composant logique, sa conception et la ligne de code. Seul un astro-architecte qui ne quitte jamais les stratosphères de sa cellule architecture et méthode peut retenir des technologies comme EJB1/2 ou JSF, qui en pratique sont inutilisables. Une technologie ou une architecture peut avoir toutes les qualités que l’on voudra, si elle n’est pas comprise et adopté par les développeurs ça n’ira pas loin.
Les pieds sur la prod
Tan qu’il n’est pas entre les mains des utilisateurs un projet informatique ne produit aucune valeur. Et le passage obligé pour atteindre les utilisateurs c’est la prod. Vous suivez à la lettre les recommandations du site 12factors ? Super votre application est prête à être déployé dans le cloud. Dommage, ce qu’attend votre prod c’est un ear pour déployer sur webFear ! Pour que le succès d’une application soit complet travailler en étroite collaboration avec les gens de la prod (Devops) et aussi important que de leur faire avec le métier (les méthodes agiles)
Et chez vous il fait quoi l’architecte (logiciel bien sûr) ?
Lors du code retreat de ce week-end la 3eme itération avec piwai m’a permis de trouver une illustration simple et concrète de ce précepte. (PRO tip: le pair programming est un moyen pour fabriquer des développeurs 10 fois plus productif à partir de deux développeurs normaux)
Le kata classique d’une code retreat est le game of life, la spec tien en 4 règles:
Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Chaque itération dure 45min, en pratique il est difficile de finir dans ce temps, ce qui tombe bien car le but d’un kata n’est pas de finir mais d’expérimenter librement. Dans une approche TDD naïve on va commencer par implémenter un test permettant de valider la première règle, puis implémenter le code permettant qui permet de faire passer le test.
Mais TDD ne veut pas pire pas de conception, bien au contraire, la première question à se poser est qu’est qu’on doit tester?
Dans le cas du game of life on réalise très vite qu’on à besoin de stocker l’état des cellules dans 2 structures, une pour la génération actuelle, une autre pour la suivante. Si l’on démarre toujours la génération suivante par une structure vide que l’on va remplir en parcourant la structure actuelle il n’est pas nécessaire d’identifier les cellules à tuer: elles sont déjà toutes mortes dans la prochaine génération. Ce qui permet de ne pas se soucier de 2 règles sur 4.
Ainsi
Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Devient
All cell are dead in the next generation
Any live cell with two or three live neighbours lives on to the next generation.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
La complexité du problème a été divisée par deux…
En partant sur ces bases on a pu finir de manière relativement élégante en 30 min.
Politics-Oriented Software Development: The code itself is the only document which may be relied upon in any way in order to find out how the software might actually behave under this or that set of circumstances. However, anyone actually saying so only reveals themselves as a troublemaker.
Entreprise 2.0: Within the companies, workers have little incentive to
share, as it is additional work with no clear benefits. Therefore, only the
minority of do-gooders, open source advocates who have an ideological bias
towards sharing knowledge, uses it
The death of Flash : Apple decided not to adopt the Flash Platform because Flash would limit its ability to differentiate its devices
Yoda Conditions : Un véritable guide des bonnes pratiques du code legacy. A lire absolument!