Articles pour le thème développement logiciel
Quelques remarques sur le mouvement agile et le "software craftsmanship", suite à mon commentaire sur le blog de Christian Fauré.
Avant hier, j'ai assisté à un exposé sur la propriété intellectuelle dans le développement logiciel: historique du droit d'auteur, rattachement des logiciels au droit d'auteur, licences, etc.
On entend souvent poser la question "Pourquoi y a-t-il si peu de femmes en développement logiciel ?" ou d'autres variantes consistant à se demander "Qu'est-ce qui dans le développement logiciel fait qu'il y a si peu de femmes ?", poussant à chercher les spécificités du développement logiciel qui expliqueraient la faible présence des femmes.
J'ai du mal à savoir où la technique devient technologie en développement logiciel. Le mot technologie est utilisé à toutes les sauces, des "nouvelles technologies" (qui ne sont plus si nouvelles) aux pseudo-technologies dont l'acronyme cache le vide. De plus, la définition de technologie comme un mélange technique+science+industrie-secouez-bien ne me paraît pas pertinent dans ce contexte.
J'ai récemment développé un logiciel pour une équipe de recherche. Ce développement a fait l'objet d'une affectation temporaire sur un projet. La question de la motivation se pose.
Proposition pour la création d'une académie du développement logiciel dans un institut de recherche en informatique. Je décris les besoins de l'institut en terme de savoir-faire en développement logiciel d'une part et en quoi consiste la formation pour les développeurs de logiciel d'autre part. Partant de là, je présente ce que devrait être une académie du développement à l'institut.
Premier billet d'une série au fil de ma lecture de .
Quel rapport entre les sophistes chez les Grecs et les développeurs utilisant le TDD ? Remarque: Ce billet est volontairement provoquant.
Dans La mètis du développeur, j'évoquais le kairós, c'est-à-dire le bon moment, l'occasion d'agir.
Quelques idées après la lecture de
Ce mois-ci j'ai eu le plaisir de récolter des haricots verts. A cette occasion, je me suis rendu compte que ma méthode de récolte se rapproche de ma façon de développer un logiciel.
Dans un précédent billet, j'évoquais le développement logiciel en terme de poursuite d'une idéalité. J'ajoute quelques réflexions supplémentaires concernant la confiance dans le développement logiciel.
Ce document se veut être une contribution à une réflexion sur le métier d'"ingénieur" de développement logiciel dans le milieu de la recherche, plus précisément ici un institut public de recherche en informatique.
Il s'agit d'un point de vue personnel sur mon métier.
Ce document ne couvre pas toutes mes activités mais détaille pour l'instant la seule partie "développement de logiciel", la plus importante en terme de temps passé.
Réaction au commentaire sur ma réaction au billet d'Uncle Bob sur la difficulté d'estimation.
Récemment, lors d'une session randori d'un coding dojo, le sujet était la lecture d'un texte pour construire un noyau de transition markovien afin de générer un autre texte qui ait l'air relativement correct, en tout cas au niveau des mots mis côte à côte. La question a été soulevée de savoir comment tester le générateur développé.
Quel est le but de la veille technologique dans le domaine du développement logiciel ?
Dans Le programme est un logiciel punk, je différenciais un logiciel d'un programme par le fait qu'un logiciel est muni d'un potentiel d'évolution, d'un avenir. Ce potentiel est orienté selon une ou plusieurs directions. Un logiciel est donc logiciel selon certaines directions d'évolution, et est par ailleurs programme, c'est-à-dire avec un faible potentiel d'évolution, selon d'autres directions.
Voyons ce qui donne ce potentiel d'évolution.
Dans Ce que sait la main de Richard Sennett, l'auteur rappelle que l'apprentissage passe par la répétition des gestes.
J'ai découvert en Novembre dernier seulement le Manifesto for software craftsmanship qui revendique l'aspect artisanal de l'activité de développement logiciel.
J'ai toujours dans l'idée de développer des ateliers personnalisés et distribués pour le développement logiciel, ce qui nécessite la manipulation de données à la façon du web sémantique. Comme il n'est pas question pour moi de troquer OCaml contre un autre langage pour lequel des bibliothèques de manipulation de RDF existent déjà, j'ai décidé de développer OCaml-rdf, une interface OCaml pour la bibliothèque Redland librdf. Le projet est ici.
Pour faire suite à Une forge, des forges... ou autre chose ?, prenons l'image de l'artisan menuisier et son atelier.
Dans Une forge, des forges... ou autre chose ? et Slow dev ?, j'évoquais respectivement le phénomène de prolétarisation du développeur par des outils imposés et la prescription de rythme par les principes de base des méthodes agiles.
J'ai appris il y a quelques temps que l'origine du mot "délit".
Fin septembre, un exposé sur les méthodes agiles aux JDev 2011 m'a interpelé.
La question des forges de développement logiciel agite pas mal les différents établissement de l'enseignement supérieur et de la recherche (ESR). Certains voudraient une forge pour leur établissement, d'autres plutôt une forge nationale, ...
Pourtant, il me semble qu'une forge unique, qu'elle soit nationale ou par établissement, est une mauvaise réponse aux besoins divers de la communauté des développeurs.
Comme tout développeur de logiciels, il m'est arrivé, en relisant le code d'un autre ou même mon propre code, de me demander ce que l'auteur a voulu faire, quelle était son intention, ce que fait ce code ou plus précisément ce qu'il est supposé faire.
Il y a bien sûr les commentaires, censés aider à la compréhension, mais ils peuvent manquer, ou bien être présents et ne pas être à jour, sans bien sûr aucune indication sur ce décalage potentiel.
Idéalement, j'aimerais donc assister à la création du code et aux pensées qui ont présidé à son écriture. Le sens de lecture (par la machine) d'un code est relativement linéaire, alors que son écriture (par l'humain) est faite d'allers et retours incessants pour ajouter ici une variable, ici découper une fonction, ...
Dans le cadre d'une réflexion sur le métier d'ingénieur de développement logiciel dans le milieu de la recherche, il est utile de préciser ce que l'on entend par programme et par logiciel, les deux termes n'étant pas, pour moi, synonymes, et la distinction entre les deux devrait permettre de comprendre l'activité de développement.