L’autre jour, je suis tombé sur le ticket d’un programmeur qui montrait un bout de son code, le voici :

bool SIM_FoodMemory::IsBoringChoice(std::string foodname)
{
	//return true if we ate the same food more than once in the last 14 days
	int recentmatches = 0;
	iter it;
	for(it = Items.begin(); it != Items.end(); ++it)
	{
		SIM_FoodMemoryItem* pitem = *it;
		if(pitem->FoodName == foodname)
		{
			int diff = SIM_GetSim()->GetTurnCount() - pitem->TurnConsumed;
			if(diff < 14)
			{
				recentmatches++;
			}
		}
	}

	if(recentmatches > 1)
	{
		return true;
	}
	else
	{
		return false;
	}
}

Autant vous le dire tout de suite, ce bout de code ne me plait pas du tout. Si l’on fait une remarque sur ce genre de code, beaucoup de coders sortent leur carte anti-troll ; « les goûts et les couleurs, ça ne se discute pas » ainsi que l’autre carte souvent utilisée ; « pas grave, ce n’est pas ‘time critic’ ».

Mais est-ce que ces 2 cartes devraient tout autoriser ? Alors sous ces 2 prétextes, on peut faire tout et n’importe quoi ? Je suis désolé, mais je ne suis pas d’accord.

Prenons le cas de la classe string qui est passé en paramètre, on est loin du débat « est-ce que ++i est mieux que i++ » ! Même si la fonction n’est pas ‘time critic’, passer une classe string comme cela entraine non seulement un overhead de code mais surtout, des allocations/désallocations mémoire! Il faut allouer la classe sur la pile, appeler le ctor, allouer la mémoire pour la chaine de caractère, la copier, et, à la fin, la désalouer. En plus de prendre du temps CPU, ça fragmente la mémoire, ce qui peut avoir des effets réellement génants.

Maintenant le fait de ne pas utiliser de const ? Mettre un header SIM_ au lieu d’utiliser un namespace ? Ce code montre très clairement que c’est un ancien programmeur C et qu’il ne maitrise pas des concepts basiques du C++ et continue à utiliser ses anciennes habitudes du C.

Tout le monde fait des erreurs, tout le monde a tendance à faire comme il a toujours fait, c’est humain. Ce qui me dérange plus, c’est la réaction, plutôt que d’accepter qu’il y ait un problème et le corriger, le programmeur se réfugie derrière le “c’est pas grave, les gouts et les couleurs… c’est pas time critic…”. Comment évoluer, s’améliorer dans ces conditions ?

Pour finir, voilà comment, moi, j’aurais surement écrit ce bout de code (ce n’est pas du tout pour montrer la solution parfaite, mais juste pour jouer le jeu) :

using namespace std;
namespace SIM {
bool FoodMemory::isBoringChoice(const string &foodname) const
{
	int recentmatches = 0;
	for(iter it = Items.begin(); it != Items.end(); it++)
	{
		FoodMemoryItem *item = *it;
		if(item->FoodName == foodname)
		{
			int diff = sim()->turnCount() - item->TurnConsumed;
			if(diff < 14) recentmatches++;
		}
	}

	return (recentmatches > 1);
}

J’ai clairement un style plus compact, j’ai fait exprès de ne pas changer l’algo sinon j’aurais fait directement un return dans le if pour casser la boucle ‘for’ le plus tôt possible.

Et comme je suis curieux, vous l’auriez écrit comment vous ?

Cela fait plus de 10 ans que je développe sous GNU/Linux en C++. Je faisais souvent des applications pour les serveurs qui étaient gérés par moi ou mon équipe. Faire des programmes portables Windows-GNU/Linux est donc quelque chose que je maitrise bien.

Par contre avec la sortie de Mtp Target sous GNU/Linux, je me suis lancé dans quelque chose de nouveau ; la distribution d’un logiciel sous GNU/Linux.

Sous Windows, j’ai l’habitude, un coup de NSIS pour faire l’installer et le tour est joué. Bon, ce n’est pas aussi simple, il faut gérer les problèmes sous VISTA, les problèmes de directX et beaucoup d’autres petits soucis, mais je gère.

La question était donc : comment faire pour que Mtp Target soit jouable par tous les Linuxiens.

La première piste était de faire comme sous Windows ; un installer. Il en existe un certain nombre qui marche plutôt pas mal. Le plus simple est makeself, c’est celui qui est utilisé par Id Software et nVidia. C’est en ligne de commande, on exécute, ça déarchive et exécute un script si nécessaire.

Sauf que voilà, le gros problème est que lorsque l’on télécharge un programme sous GNU/Linux, les droits d’origine ne sont pas gardés, donc on se retrouve avec un programme sans le bit d’exécution et quand on double clique dessus, ça l’ouvre dans un éditeur de texte ! Il faut que l’utilisateur s’y connaisse pour ajouter le bit d’exécution et ensuite l’exécuter. La raison invoquée est que c’est une question de sécurité. Un utilisateur pourrait télécharger un programme sans le faire exprès et l’exécuter.

La solution choisie par Mozilla est de créer une archive “.tar.bz2″. L’avantage est qu’il suffit de double cliquer sur l’archive pour que ça l’ouvre grâce au logiciel associé. Ensuite, l’utilisateur drag&drop le répertorie contenu dans l’archive où il le souhaite et il peut exécuter ce qui va bien. Je ne trouve pas que ça soit l’extase, mais au moins ça marche sans bidouiller, car les droits sont gardés dans l’archive.

Autre problème, impossible d’associer une icône à l’exécutable. Encore une fois, la raison invoquée est la sécurité (oui, sinon on pourrait mettre une icône d’un autre logiciel pour se faire passer pour celui çi). Mais bonne nouvelle, il est possible de créer une sorte de raccourci à la Windows, c’est un fichier texte qui contient le path vers l’exe, une icône, etc. Super ! Sauf qu’en fait non, c’est naze, on ne peut pas mettre de chemin relatif vers l’exe!!! Ca serait trop simple, on peut pas faire : path=bin/myexe, il faut un chemin absolu, sauf que bien sûr, comme l’utilisateur peut extraire le jeu n’importe où, il est impossible de créer ce fichier, donc retour à la case départ, pas d’icône.

Problème suivant ; mon jeu utilise une lib dynamique, FMod. Sous Windows, c’est simple, l’exe va automatiquement chercher les lib dynamiques dans un ordre précis, d’abord dans le répertoire courant, puis dans des répertoires spécifiques. Sous GNU/Linux? Il cherche dans les chemins définis dans la variable d’environnement LD_LIBRARY_PATH. Il est donc impossible de lancer le jeu directement, car il ne trouve pas la lib dynamique. Il faut donc écrire un script Shell qui va ajouter le chemin courant dans LD_LIBRARY_PATH puis exécuter le jeu. Sauf que c’est un script, et donc quand on double clique dessus, ça pop une message box demandant à l’utilisateur s’il veut l’exécuter, l’éditer, etc. Malgré le bit d’exécution !

Dernier souci ; la portabilité. Si je veux que le jeu marche sur un maximum de distribution GNU/Linux, il faut que je limite les dépendances avec les librairies externes. Chaque dépendance risque de poser un problème, car chaque distribution a sa propre version de chaque librairie. Il faut donc *tout* compiler en librairies statiques.

Dans les versions récentes de gcc, le compilateur ajoute un système de stack check pour limiter les bugs, sauf que, pas de bol, il faut la GLIBC 2.4 pour que cela fonctionne, sauf que ce n’est pas très répandu encore. Donc tous les utilisateurs qui tournent sur des distribs avec la GLIBC inférieure à 2.4 ne pourront lancer le jeu. Après une grosse prise de tête, j’ai enfin trouvé le moyen de retirer ce système et donc retirer les symboles dépendants de la GLIBC 2.4. Ouf…

Après tous ces problèmes, j’ai finalement réussi à faire un package unique qui fonctionne sur quasiment toutes les distribs GNU/Linux!

J’ai toujours le problème du script qui ne veut pas se lancer automatiquement quand on double clique dessus. Toujours pas d’icône associée au script. Pas de version 64bits (mais ça marche bien avec l’émulation automatique). Pas d’ajout du jeu dans le menu… La solution ultime serait peut-être un tar.bz2 qui contient un installer mais ça ne règlera pas tous les problèmes.

Quand je discute avec des fans de GNU/Linux, leur réponse est toujours la même, c’est naze ce que tu fais, la bonne façon de faire est de créer un package. Sauf que le système de package est différent sur chaque distrib! Ça veut dire que si je veux que mon jeu soit disponible partout, je dois créer une bonne 10ène de version du jeu ! C’est vrai que c’est mieux intégré, mais ça demande un boulot monstre. Prenons par exemple le simple cas de la distrib Debian, si je veux que tous les utilisateurs Debian puissent jouer à Mtp Target, il faudrait que je fasse un package debian, sauf qu’il y a plusieurs versions de Debian, etch, lenny, sarge, woody… Donc, il faudrait en théorie faire autant de package que de version de Debian, donc au moins 3 pour Debian. Je vous laisse imaginer le boulot (nombre de distrib * nombre de versions par distrib)!

Peut-être qu’un jour il y aura assez de monde dans la communauté de Mtp Target pour faire ce boulot, mais ce n’est pas quelque chose que je peux faire tout seul. Mon système n’est pas parfait, mais il permet au moins à tout le monde sous GNU/Linux de jouer à Mtp Target sans dépendre d’une distrib ou d’une version de distrib. Je n’ai à ce jour aucun linuxien qui est venu me voir en disant que ça ne marche pas chez lui.

Demain je vais à Linux Expo, ça fait des années que j’y vais car c’est toujours l’occasion de revoir des gens que je vois rarement.

Je profite de cette occasion pour faire un ticket sur les jeux vidéo libres. Voici les différentes catégories :

Les jeux développés sur le temps libre

Ça représente surement 95% des jeux libres. Ils sont très souvent développés par des étudiants qui ont beaucoup de temps libres (forcement, ce sont des geeks) et qui veulent faire un jeu parce que c’est fun (oui, ce sont des geeks, ils n’ont pas la même notion du fun que les gens normaux).

Ça part toujours d’une très bonne intention, les développeurs se démènent pour faire un programme clean, se focalise sur le dernier design pattern, le dernier moteur 3D libre et rédigent des game designs. Ils sont super contents, motivés, en une semaine ils arrivent à ouvrir une fenêtre 3D et à afficher un triangle rouge au milieu.

Au bout d’un an, à force de boulot acharné, ils n’ont rien à montrer si ce n’est une fenêtre 3D qui s’ouvrent avec un triangle au milieu (mais qui tourne !) et un doc de 500 pages décrivant un jeu tellement complexe que même la NASA ne comprendrait pas les spécifications. Quelques fois, ils arrivent à amener quelques potes de classe sur le projet et arrivent à faire quelque chose de jouable. Mais ces projets tombent très souvent à l’eau, non pas qu’ils soient mauvais mais par manque de temps. L’étudiant découvre les boites de nuits et les filles (non, c’est pour rire, c’est un geek !). Je veux dire l’étudiant trouve un travail et n’a plus le courage le soir et le weekend de passer encore du temps sur ce satané bug introuvable (et oui, le dernier design pattern n’a finalement pas suffit à éviter les bugs).

Les jeux tellement vieux qu’il faut ressortir l’Atari pour les compiler

Bon ok, j’exagère, mais c’est un peu ça quand même. Les seuls jeux produits par l’industrie du jeu vidéo et qui sont libres aujourd’hui sont ceux qui sont tellement vieux que de toute façon ils ne peuvent plus espérer les vendre (même pas dans les boites de Frosties). C’est le cas par exemple de Quake. 5 ou 6 ans après la sortie, quand la technologie est complètement dépassée et que le code source n’a plus aucun intérêt compétitif, le studio le passe en licence libre pour se faire un coup de pub. C’est clairement mieux que rien. L’avantage est que ce sont des jeux beaucoup plus connus et donc qui attirent beaucoup de geeks qui veulent voir comment ça a été codé (QUOI ? ça a été codé sans design pattern? Comment ont-ils pu en vendre des millions ?). C’est très instructif et toute une ribambelle de geek bidouillent le code pour le fun en faisant une version pour iPhone, une pour le C64 et une autre avec des design patterns parce que c’est quand même mieux comme ça.

3ème catégorie de jeux libre… Euh… bah en fait, il n’y en a pas.

Dans de très rares cas, les jeux développés sur le temps libre attirent d’autres geeks et deviennent connus (TuxRacer par exemple). Dans d’autres rares cas, un groupe de geeks se réunit autour d’un ancien jeu close source et fait un super mod (Warsow par exemple) mais dans la grande majorité des cas, ce n’est pas fameux et on se retrouve avec 90% des jeux complètement injouables, pas fun et sans intérêt… tant d’énergie perdue…

On peut s’étonner de voir de superbes applications libres comme GNU/Linux, Open Office, Firefox et si peu de bons jeux (et encore moins de jeux originaux). C’est d’autant plus étrange que faire un jeu est souvent un rêve de geek.

Je pense qu’une des raisons à cela est que les geeks ont tous une idée différente de jeu révolutionnaire et donc que chacun veut développer son jeu dans son coin et n’arrive à rien car il est tout seul. Une autre raison est que les geeks misent beaucoup trop de temps sur la technologie et les docs. Combien de fois j’ai discuté avec des geeks qui veulent faire “un MMORPG où on sera libre de faire toute ce qu’on veut dans un monde 3D avec de la physique qui tue tellement c’est réaliste, qu’à coté, Second Life c’est du pipi de chat.” (c) Je n’ai rencontré que si peu de geeks pragmatiques. Je pense que ceux qui arrivent à faire de bons jeux libres aujourd’hui sont justement ceux là, les pragmatiques. Des personnes qui savent à quel point c’est complexe de réaliser un jeu et donc qui se donnent un objectif simpliste, sur un gameplay extrêmement simple et efficace. Et une fois cette version lancée, fonctionnelle et amusante alors d’autres geeks tomberont peut être dessus, trouveront l’idée sympa et rejoindront le projet pour l’améliorer. Alors une version améliorée sortira et ainsi de suite jusqu’à arriver à un jeu vraiment bien.

Je trouve dommage qu’il y ait si peu de bons jeux dans le logiciel libre alors que tous les ingrédients sont présents. Je trouve encore plus dommage qu’aucun studio ne s’intéresse au logiciel libre alors que tout le monde sait qu’un bon jeu est avant tout un game play original et fun et non un moteur 3D nouvelle génération. Ce n’est pas le code source du jeu qui fait vendre, c’est le fun du jeu. Si l’industrie du jeux vidéo partageait son code, elle pourrait baisser ses coûts de développement et surtout aurait plus de temps pour se concentrer sur le fun et l’originalité de leur jeu ce qui serait positif pour tout le monde et surtout, les joueurs.

Ce dont je suis convaincu, c’est qu’il est aujourd’hui possible de développer des jeux vidéo libres (et même gratuits) et d’en vivre et je suis là pour tenter de vous le prouver à tous avec Mtp Target

Un jour en lisant mes blogs favoris, je tombe sur cet article que je vous invite à lire. Il parle de l’importance de la discipline lorsque l’on programme. Sans cela, tout part vite n’importe comment jusqu’au jour où ça devient ingérable et où les gens commencent à passer plus de temps à chercher et comprendre qu’à développer.

Il prend l’exemple des outils de source control et je ne peux qu’être d’accord avec lui… J’ai eu l’occasion de voir un bon nombre de projets utilisant des sources control et à chaque fois c’était un désastre ! Aucune discipline n’est apportée sur l’arborescence des répertoires alors que c’est la base du projet, ses fondations. Le problème principal est que personne ne s’intéresse à ce sujet, chacun met ses fichiers où il veut et s’il ne sait pas où, il va surement créer un répertoire quelque part portant son nom. Il y a ceux qui vont créer un répertoire par classe, d’autres qui vont tout mettre en vrac dans un même répertoire, après tout, on s’en fiche du moment que ça compile et que ça se lance !

Quelque chose qui m’horripile encore plus, c’est la nomenclature des noms de fichiers. Vous êtes vous déjà posé la question sur comment vous nommez vos fichiers ? En français ? En anglais ? En minuscule ? En majuscule ? Peu importe ? Pas tant que ça…

Par exemple, accepter les espaces dans les noms de fichiers peut devenir une réelle galère pour les programmeurs et peut entrainer un bon nombre de bugs.

Accepter les majuscules ne pose pas de problèmes sous Windows, car il ne fait pas la différence, mais si pour une raison quelconque vous devez faire fonctionner un outil sous Linux, alors vous allez le regretter. J’ai pu voir des projets où les règles de nommage des fichiers étaient différentes en fonction du programmeur. Il y avait des MyClass.h yourClass.h voir même des his_Class.h. Mais lors de l’inclusion dans le code avec la directive #include, les majuscules ne correspondaient pas. Ça marche très bien sous Windows mais aucune chance que ça passe sous Linux et vous êtes alors bon pour repasser sur tous les #include du code source. L’autre gros problème est pour les nouveaux programmeurs : comment peut-il s’y retrouver ? Un coup il y a un _, un autre coup non, en gros il faut apprendre par cœur le nom de chaque fichier !

Vous pouvez dire que c’est ce qui arrive fatalement quand on a une grosse équipe ou alors quand on engage des gens incompétents mais en fait non. Regardons ce projet développé par 2 programmeurs talentueux et expérimentés qui viennent de créer un studio ensemble dans le but de réaliser le projet de leurs rêves. Le projet a commencé il y a moins d’un an, et ils ne sont que 2. Ils s’amusent à afficher leurs commits alors profitons-en pour essayer de trouver les règles de nommage des fichiers et répertoires qu’ils ont mis en place :

• Règle 1: Nommage des répertoires et des code sources : une majuscule pour la première lettre de chaque mot et le reste en minuscule.
• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _.
• Règle 3: Nommage des répertoires des assets graphiques: c’est la que ça se complique… Il semblerait que ça soit la règle 1 pour les 2 premiers répertoires, puis la règle 2 pour les répertoires suivants.

Regardons maintenant un autre commit qu’ils ont fait sur le même projet quelques mois auparavant :

AIE. Il semblerait que ma règle 2 ne soit pas correcte, en fait il faut la modifier comme ça :

• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _ ou des - en fonction du sens du vent (où tout autre paramètre aléatoire).

Imaginez, ils ne sont que 2 ! des ingénieurs avec l’esprit cartésien ! et au bout de quelques mois on ne peut déjà plus décrire le nommage des fichiers/répertoires avec des règles simples. Qu’est ce que ça va devenir dans 1 an, ou quand il y aura des nouveaux dans l’équipe ?

Pourtant, il existe une règle simple qu’en général les programmeurs aiment bien : KISS (Keep It Simple, Stupid). Mais pour je ne sais quelle raison, ils ne l’appliquent que pour la programmation.

À mes débuts à Nevrax, pour le développement d’un MMORPG Windows/Linux, j’avais proposé une règle très simple suivant justement le principe KISS en partant du principe que plus les règles seront simples, plus il y a de chance que les gens la connaitront et la suivront.

• Règle 1: Nommage de tous les fichiers et tous les répertoires : uniquement des caractères alphanumériques en minuscule, les mots étant séparés par des _. Pour les geeks, on peut résumer ça en [a-z0-9_]+
• Règle 2: pas de règle 2…

On peut difficilement faire plus simple, ça évitait tous les problèmes des espaces, des majuscules et des caractères bizarres. Bien que cette règle soit simple et rabâchée depuis le début du projet, un certain nombre de programmeurs n’arrivaient pas (ou ne voulaient pas) la suivre et mettaient des noms de fichiers qui ne suivaient pas cette règle. Mais le pire a été avec les graphistes, designers, sound designers… Ils ne voulaient pas se plier à cette règle et voulaient continuer à faire comme ils faisaient avant (c’est à dire sans règles, au gré des humeurs). Pour éviter des conflits trop violents, il a été décidé de n’appliquer la règle que pour le code source et ce fut une belle erreur. Pendant des années on a du ajouter des bouts de code (rustines) dans les tools, sous Linux uniquement pour gérer des cas particuliers dans les noms fichiers et répertoires parcequ’ils ne voulaient pas se plier à cette règle simple. Il est même arrivé de devoir mettre des rustines dans des outils qui fonctionnaient parfaitement bien depuis 4 ans parce qu’une personne avait trouvé un nouveau moyen fun de nommer les répertoires qui cassait le peu de logique qui restait dans l’arborescence des datas.

Autant je comprends que les gens soient réticents à suivre des règles complexes ou qui n’ont pas de sens. Mais je ne comprends toujours pas pourquoi autant de personnes ont protesté si fortement contre une règle simple qui aurait mis de la discipline dans le source control et aurait rendu la vie tellement plus simple à tous.

Honnêtement, je ne pense pas que plus de 5 % des entreprises savent recruter des programmeurs. Depuis que je suis dans la vie active (une demi-douzaine d’années), je n’ai dû en croiser qu’une qui savait vraiment bien le faire, qu’une ou deux où il y avait de l’idée et tout le reste, c’était du grand n’importe quoi.

Tout d’abord, il faut définir ce qu’est un “bon programmeur”. Selon moi, avoir un diplôme reconnu n’est pas un critère, connaître par coeur les puissances de 2 jusqu’à 2 puissance 32 non plus. Je définirais un bon programmeur comme quelqu’un d’extrêmement curieux, qui maîtrise ce qu’il fait, qui a une très bonne capacité d’écoute et de résolution de problèmes techniques. Il doit aussi être capable de se remettre en question, aimer travailler en équipe et être capable de finir ce qu’il commence.

Dans les 95 % des entreprises, on est confronté à l’un de ces scénarios :

- Si l’entreprise a de la chance, quelques bons ingénieurs vont être recrutés par erreur et se retrouveront au milieu d’une grande majorité d’ingénieurs qu’ils trouveront incompétents. Ces bons ingénieurs ont toutes les chances de vite quitter la société, car un bon ingénieur a besoin de trouver dans son environnement de travail des gens au moins aussi bons que lui. La société ne se retrouvera donc rapidement plus qu’avec des ingénieurs de niveau moyen ou mauvais et cela reviendra au cas suivant.

- Si l’entreprise n’a pas de chance, elle ne recrutera que des ingénieurs moyens ou incompétents. Pour que cela fonctionne quand même un minimum, la solution choisie est souvent de les encadrer de très près par des managers. Le problème est que ces managers n’ont aucune raison d’être mieux recrutés que les ingénieurs et donc sont du même niveau de compétence. Il faut alors mettre en place une énorme hiérarchie où tout le monde surveille tout le monde et où personne n’ose plus rien faire de peur de se faire taper sur les doigts par son chef… Dans ces entreprises, les managers mettent alors en place des méthodologies très lourdes et complexes avec beaucoup de paperasse, de planning, etc., pour essayer de se protéger en cas de problème et pouvoir rejeter la faute sur quelqu’un d’autre. On pourrait croire que ce genre de scénario n’arrive que dans les grosses sociétés, mais j’ai pu rencontrer des PME avec ce schéma (par exemple 6 ingénieurs pour 4 managers). Autant dire tout de suite, dans ces entreprises, les ingénieurs n’ont aucune reconnaissance. Ils sont vus comme le bas de l’échelle, les ouvriers, les moins bien payés, ceux qui sont à l’origine de tous les problèmes (retards, bugs, mauvaise qualité, …). Ils sont souvent considérés comme des gens qu’on peut remplacer comme on remplacerait une roue sur une voiture. Bref, il est évident que l’effet le plus indésirable de cette organisation est que l’ingénieur se trouve à détester sa position et va tout faire pour, soit partir, soit monter dans la hiérarchie pour gagner plus d’argent et arrêter de se sentir un moins que rien. Évidemment, on va vite se retrouver avec une énorme compétition entre ingénieurs, car le nombre de place de chef est inférieur au nombre de place d’ingénieur (enfin normalement). Ca crée alors des conflits d’intérêts, des histoires politiques entre équipes et les ingénieurs passent plus de temps à essayer de bien se faire voir par leurs chefs plutôt qu’à faire du bon code. Autre problème, c’est l’organisation idéale pour rencontrer le principe de Peter.

Dans ce genre d’entreprises, passer aux méthodes agiles où n’importe quelle autre méthode ne servira à rien, car c’est un problème de fond, un problème culturel où seule une prise de conscience de la part du boss peut prétendre à une amélioration. Mais même dans ce cas, il serait très long et très compliqué de faire des changements de fond, car cela nécessiterait forcément des licenciements, de remettre des managers en programmeurs et souvent les esprits sont trop habitués à la culture de leur entreprise et considèreraient ça comme un affront. Bref, je ne pense pas que ça soit réellement possible de changer une culture d’entreprise, car les personnes sont recrutées en général parce qu’ils partagent justement cette culture.

Maintenant, prenons le cas des 5 % restants (et encore, je crois que je suis gentil, je dirais plutôt 1 %), ce sont des sociétés où le recrutement est une partie primordiale et ils feront tout ce qui est nécessaire (ne pas céder à la pression, mettre les budgets et le temps nécessaire) pour ne pas laisser entrer dans leur société des individus qui ne correspondent pas. L’idée de base est la suivante : “On ne recrute que des gens vraiment intelligents, ou on ne recrute pas.” Dans ce genre de société, le recrutement est permanent et maximal. Permanent, car ces ingénieurs vraiment intelligents sont difficiles à trouver et souvent déjà en poste, si on ne recrute que 2 mois dans l’année, la probabilité de tomber dessus est très faible. Maximal, car pour être vu par les meilleurs, il faut se faire voir. C’est exactement la même chose que pour vendre un produit à un client sauf que dans ce cas, le produit c’est la société et le client est l’ingénieur talentueux. Et comme ils savent qu’ils sont bons, ils sont difficiles et veulent aller dans des sociétés où ils se sentiront vraiment bien. Comment réussir toucher ce genre de personnes mériterait un sujet à part entière (JoelOnSoftware en à déjà parlé). Cela n’est pas gratuit, ça coûte même cher à une entreprise aussi bien en temps (car il faut des gens pour faire passer les entretiens) qu’en argent. Mais c’est un investissement qui sera extrêmement rentable sur le long terme.

Une fois que vous avez réussi à attirer les meilleurs, il faut savoir faire le tri et c’est là qu’intervient l’entretien. Comment faire passer un bon entretien ? Encore une fois, ça mériterait un article complet (vous pouvez lire ça).

Supposons que la structure est en place pour ne recruter que des bons ingénieurs, qu’est ce que ça change ? Tout d’abord, vous pouvez avoir une confiance beaucoup plus importante dans ces personnes. Vous n’avez pas à fliquer leurs horaires de travail (ils en feront même surement beaucoup plus que la normale sans même le demander), à vérifier s’ils bossent vraiment ou s’ils se tournent les pouces, etc. Bref, vous pouvez alléger au maximum la hiérarchie. Du côté des ingénieurs, ils sont beaucoup plus contents, car ils sentent qu’on leur fait confiance, ils sont beaucoup plus libres et le résultat est qu’ils bosseront beaucoup mieux et qu’ils ne voudront pas aller voir ailleurs. En plus, ces ingénieurs se retrouvent avec d’autres bons ingénieurs, ils se comprennent, s’entraident, se respectent plus facilement. Ils ne vont pas se prendre la tête pour savoir s’il faut mettre des espaces ou des tabulations, s’il faut faire des tests unitaires ou pas, car ils sont assez intelligents et ont assez d’expérience pour savoir ce qu’il en retourne et où se situent les vrais problèmes.

Donc dans ces sociétés, la hiérarchie est réduite à son minimum, il y a des ingénieurs qui programment, des lead ingénieurs qui sont aussi très techniques, mais qui peuvent facilement gérer 10 à 20 personnes, car les méthodes de travail peuvent elles aussi être très simplifiées. Pour que cela fonctionne, il faut évidement savoir mettre l’argent où il faut, par exemple ne pas lésiner sur les locaux, les ordinateurs, les tables, chaises, etc. Plus l’environnement sera agréable, plus il y a de chances que l’ambiance y soit bonne et donc que les gens y travaillent bien.

Ça peut paraître simple de mettre en place ce genre d’équipes, mais ce n’est clairement pas le cas. Tout d’abord, les lois de la concurrence, la pression des investisseurs, le manque d’ingénieurs sur le marché du travail font que les boss ont souvent tendance à vouloir recruter au plus vite, quitte à ne pas suivre la règle de base en pensant qu’après tout, ce n’est pas si grave que ça, on verra plus tard. Au début, ça marche bien, car la boite est petite, mais au fur et à mesure que des personnes peu compétentes arrivent, les problèmes arrivent par la même occasion et l’entreprise tombe dans les 95 %. L’autre problème est que les fondateurs/boss ont beaucoup de mal à mettre de l’argent sur quelque chose qui n’est pas rentable à très court terme (le problème du bûcheron). Ils prendront les chaises premier prix qui font mal au dos sans penser que derrière cela augmentera le turn-over (qui veut passer 8 heures ou plus sur une chaise inconfortable?) qui au final coûtera beaucoup plus cher que d’avoir mis des fauteuils corrects dès le début (l’exemple de la chaise vous parait peut-être exagéré pourtant c’est du vécu et des histoires comme celle-là, j’en ai vu tellement d’autres…).

Le meilleur exemple d’entreprise qui utilise la 2ème méthode est Google. Bizarrement, ils sont devenus la boite la plus recherchée par les ingénieurs et c’est aussi une société qui fait beaucoup d’argent. Je suis convaincu que leur réussite tient d’abord à leurs méthodes de recrutement et leur culture d’entreprise. Je suis aussi convaincu que même s’ils n’avaient pas eu l’idée de faire un moteur de recherche ou un business sur Internet, ils auraient obtenu un résultat similaire dans une autre industrie.

Vous allez me dire que c’est facile pour eux, ils ont énormément argent, mais ils ont commencé à moins de 10 personnes et ont tout bâti eux même. C’est avant tout leur façon de construire la société (et donc l’équipe) qui leur a permis d’arriver là où ils sont aujourd’hui.

Un autre exemple d’une entreprise qui suit ces principes est FogCreek. C’est une petite société qui ne fait que grossir, doucement, mais sûrement. Ils ont un peu la même philosophie que Google, mais avec seulement une 20aine de personnes. Cette boite a toujours été rentable. Ils suivent la règle d’or qui dit que si on recrute les bonnes personnes, quel que soit le projet qui sera choisi, il sera rentable. Et ils le prouve par exemple avec leur bugtracker. Il existe des 10aines de bugtracker différents, dont beaucoup de gratuits, mais bien que le leur soit payant il se vend bien et suffit pour faire vivre la société.

Tout ça pour dire que le processus de recrutement commence dès les premiers jours de la vie d’une entreprise et que de mauvaises méthodes de recrutement risquent d’entrainer par la suite de gros problèmes qui ne pourront pas être rattrapés. Malheureusement, c’est aussi la période où il y a tellement de choses à faire que le recrutement des programmeurs peut être mis au second plan où alors les conséquences du choix de mauvais programmeurs sont clairement sous-estimées.

Je rêve un jour de pouvoir rencontrer des créateurs d’entreprises français assez ouverts pour pouvoir comprendre l’intérêt et le potentiel énorme de ces nouvelles façons de construire et gérer une société informatique. Si vous pensez en être un, n’hésitez pas à me contacter, je serais ravi d’en discuter plus longuement !