Mickaël’s Weblog

Le développement logiciel d’un module peux se faire de plusieurs façons différentes. On peut le coder en une fois en prenant en compte tous les cas d’utilisation (connus et potentiels). On peut également en faire une première version en prenant en compte tous les cas d’utilisation connus tout en sachant qu’il faudra la réécrire pour l’étendre. A l’extrême, on peut coder à minima, en ce disant que le design n’est pas important et au final revenir 1000 fois dessus pour coder…tout ce qui manque.

D’où la question: “Quelle est la meilleure ?”

Première remarque: il n’y a pas de méthode “meilleure”, mais elles ont toutes des avantages et inconvénients propres différents, à vous de choisir en fonction de vos objectifs et des moyens à votre disposition. Ce qui est sur: c’est qu’il n’y a pas de (recette) miracle. Au bout du compte, une fonctionnalité a un coup lié à sa complexité/difficulté, et donc requiert un investissement a peu près identique quelque soit la méthode…mais un retour sur investissement différent suivant vos objectifs.

Prenons le cas du codage en 1 fois, plus communément appelé : “usine a gaz”.  L’idée est de confier ce module a un seul développeur qui part “en sous marin” pour coder le module afin de répondre aux besoins connus…mais aussi suffisamment extensible pour intégrer des nouveaux besoins très rapidement. Pour caricaturer, c’est la tendance naturelle d’un développeur, car cela lui permet de ne se consacrer que à cette tâche, il travail seul, décide seul, doit faire appel a ses connaissances d’expert (pour l’extensibilité), et enfin démontre que le management lui fait confiance…c’est gratifiant. Quand on a un développeur capable d’anticiper les besoins futures, de coder de manière efficace et propre, c’est certainement la “méthode” qui permet d’avoir le module complet le plus rapidement…sauf que ça c’est la théorie, et que cela se passe autrement dans 95% des cas. En effet, il y a souvent un nombre important de bugs, l’extensibilité n’est souvent pas au rendez-vous et du coup le moindre besoin supplémentaire demande un “refactoring” important et pas si simple que ça. L’autre effet indésirable, est le non partage de la connaissance du code…et c’est souvent du code assez complexe (d’où le terme ”usine a gaz”). Autre inconvénient majeur: il faut attendre en général d’être aux 9/10 de l’implémentation pour voir quelque chose tourner/fonctionner.

Mon responsable R&D d’il y a 10 ans disait toujours: “de toute manière c’est toujours la 3ième implémentation la bonne…il faut donc toujours tout refaire au moins 2 fois”. On commence a sortir de l’usine a gaz, car les ambitions de la première implémentation sont plus raisonnable et se cantonne aux besoins connus (enfin 90%). De toute manière, y aura la seconde implémentation pour corriger ce qui ne va pas et intégrer les nouveau besoins! Autre avantages: un retour sur investissement plus rapide…même si l’implémentation est moins complète, moins de complexité, et donc aussi en général moins de bugs. Au bout du compte, on va avoir [sur une base de 3 implémentations] investi autant: moins de temps à définir les spécifications, plus en dev, moins en bug fix, moins en QA. Si on a un staff QA plus réduit, on y gagne. On peut mettre sur le marcher ce module plus tôt. Et si on fait faire le développement a différent développeurs, on a un meilleur partage de la connaissance (et on a perdu en efficacité car il faut former chaque développeur).

Poussons le raisonnement du nombre d’implémentations à l’extrême : 1000! On réduit a minima les spécifications, on ne se concentre que sur le plus important (1/1000ième de la fonctionnalité), et on n’anticipe aucun besoins non connu. On ne peut cependant pas se permettre de faire les 1000 itérations/implémentations les unes derrière les autres, avec phase de spécification, implémentation, test, documentation, transfert de connaissance…il faut une extrême fluidité dans la communication associé à une polyvalence de chaque développeur (et oui, il va faire le dev, la QA, la doc et le design).

Au bout du compte, quel est l’investissement total suivant chaque méthode ? Définissons d’abord ce qu’est l’investissement total. C’est l’ensemble des ressources qu’il aura fallut mettre en place pour avoir un module qui fonctionne correctement (les clients en sont satisfaits), et donc le code ne bouge quasiment plus (peu de bugs).

La première méthode apparait comme la plus rentable, mais le risque (devoir refaire une autre implémentation) est très élevé (et là cette solution devient la moins rentable), et souvent la qualité n’est pas au rendez-vous. Deplus, seul un développeur connait le code…ce qui peut poser d’énormes problème de maintenance.

1000 intérations apparait comme la méthode la moins rentable, mais la capacité d’adaptation a des nouveaux besoins est excellente et on délivre bien plus rapidement…et ça, c’est de l’argent. Cela demande cependant d’intégrer redesign et tests a chaque itération.

C’est donc à vous de choisir suivant les ressources, le contexte, le objectifs.

Il y a cependant une pratique dont j’ai pu observer qu’elle ne fonctionne pas quelque soit la méthode. Le fond du problème est la gestion de la dette technique qui mène au “refactoring”. La première méthode consiste a réduire à 0 cette dette pour éviter tout refactoring. Le problème est que le risque est très élever de ne pas y arriver, et on s’en aperçoit souvent trop tard. Augmenter le nombre d’itération consiste à admettre cette dette technique et de la compenser par des itérations/implémentations supplémentaires. Le piège est de consacrer ces itérations uniquement à la dette. Le résultat est d’avoir des itérations sans valeur ajoutée, et du coup une incompréhension du product management quand a leur utilité. La “bonne” pratique consiste a apporter de la valeur ajouter à chaque itération, tout en remboursant une partie de la dette.

Au final, ayez une stratégie de remboursement de dette qui correspond a vos objectifs et à vos resources.

Les méthodes agiles assurent-elles le succès d’un projet de développement?
La réponse est clairement non. Ayant pratiqué plusieurs méthodologies (agiles…ou pas), il m’apparait clairement que c’est avant tout l’existence d’une méthode et son adhésion qui est la condition nécessaire, mais pas suffisante. Ne pas avoir mis en place de méthode est la garantie d’un désastre, et la responsabilité en incombe au management. Il faut de plus que l’ensemble des acteurs y adhèrent: équipe et client. Ce n’est pas chose facile, mais le management n’est pas une chose facile. Il faut enfin que le déroulement du projet ce fasse en toute transparence vis-à-vis de l’équipe et du client.

Mettre en place une méthode efficacement n’est pas aisée. Dans le cadre d’une SSII par exemple, les méthodes agiles sont souvent opposées aux contrats de type forfait. Il est vrai qu’au prime abord cela peut sembler vrai, mais c’est a mon avis juste une question d’approche, et au final les SSII travaillent de plus en plus en mode Agile. Sur ce sujet, Pascal Van Cauwenberghe a écrit 2 excellents articles à ce sujet: Succeding with Agil Fixed Price projects (part 1 et part 2). Les plus gros obstacles sont souvent la méconnaissance ou les fausses évidences.

Le plus important est la mise en place d’une méthodologie, ensuite il faut considérer tous les paramètres du projet dont le contexte d’éxécution (taille d’équipe, durée du projets, objectifs, priorités..etc), et choisir la méthode la plus appropriée, la modifier suivant les besoins et l’exécuter en toute transparence
.

Agile sounds on the decline … in the practice as mass adopte it wrongly. This is what are saying James Shore in this post,Jonathan Kohls in this post. I think the Agile bubble start to explose, the question is: will it follow the hype curve that I described in that post.

I bet on this as the major infrastructure component for software within near future.

Separation of Concern (SoC) is really important to me and goes beyond simple separation of layers os a software implementation. I should add “cohesive”, but this is part of the same idea: everythings doing the right thing in the rigth area.

This principle does apply obviously to the source code as a programming practice, useing a tool as maven that introduce some structure into the code organization. But it also apply to the architecture (SCA), the deliverables (DLL…and its hell), platform (OSGi / Spring DM server), components/framework (IoC, MEF), and methodologies (Agile).

The last one could be amazing, but I think the rational is the same: change adpoption. Kevlin Henney in his post Manage component dependencies for improved system quality says:

Another consideration in managing dependencies is the question of change. The dependency structure of a system can enable or discourage change, which makes dependency management a question of architecture, not merely one of fine-grained code quality

Having a system allowing effective depedency management at compile-time will ease test infrastructure setup (abaility to test a piece of code without having the entire system setup), hence quality…humm…be sure to automate your test to really ensure quality (doing manual repetive stuff is the best way to do it in a bad way over the time).

Having a system allowing effective depedency management at run-time will ease deployement as you will be able to do hotswapping of components even when they are running as for OSGi platforms.

Having a system allowing effective depedency management at run-time with version management, will allow multi-tenant applications and smooth upgrade…and probably start to solve the DLL’s hell.

Jimmy Bogard have written a very interesting post on Flexibility and control.

He is writting: “The manager had likely fallen under the illusion of rigid control leading to more predictable success.”

His image with arrow and guided missile is terribly true and helps a lot to understand agile concept. Has I’ve already written in a post on Agile Practices With Waterfall Management, management that does not embrasse really agility (maybe due to some misunderstanding), this can produce very weird effect.

What about Program and Development Management that are using a waterfall approach with agile development team? By waterfall approach for management I’m talking about management decision not to start the development before requirements are defined, planification and release date setup. It’s not unusual to see also a stabilization phase defined as for example the last couple of iteration.

This is mainly due to:

• Product Management team is not ready at all for the first iteration,
• Infrastructure changes not identified before the first iteration,
• Product Management wants to have a full plan on the future release before starting, to prepare pre-announcement.

The final result of this approach is that the development team is not working at all…because it’s simply forbidden. The market driven approach has been well understood by Product Management and they are blocking any kind of development before they have decided what features have to be implemented.

Joaquim Rendeiro talk about co-existence of waterfall (especially for management) and agile methodology in his post on Agile or Waterfall?. Yes, they can exist but may have the consequences I’ve talked about.

IMHO, this occurs inside teams that are transitioning to agility and are not mature enough on this agile approach. As agility provide a huge responsibility and control capability to the product management, they used this extra-strength keeping in mind the waterfall approach targeting dates and content of the releases.

The development management should be the driver to accelerate the transition to a real agile approach. For example by rejecting all big kick-off meetings to start a release, and encourage a better preparation of each iteration. The development team managers should also avoid any technical discussion include an product owner and take the responsibility to make the technical choices. Often, the technical choices are delegated to product owner. Yes this is strange, but haven’t you any discussion with a product owner like: we can implement the story this way and it will cost 13 points or a different way and it will cost 21 points but this last one is less good for reasons A and B. Let guess the answer…do the shortest path. Even if this is usually the good answer from a technical perspective (I’m supporting the principle of simple design which is often shorter to implement), there is not reason to delegate this decision to product owner.

Agile approach requires a clear definition and separation of responsibility for every shareholder.

Getting agile is probably the only (or best) way for large R&D organization in a software company to setup their workforce in front of their need. They usually are working over multiple products (legacy or not), and are market driven. In small software companies, the product management marketing function is endorsed by R&D management and they work usually on a small number of projects which are at least tightly integrated, which means R&D team is focusing on only 1 common goal.

Start-up have focused/sharp vision, excellent creativity. Large company are relying on strong market analysis and capacity to move on…most of the time as soon as a startup has demonstrated new markets.  Vijay Challa talk about this in his post on Agility World 2.0.So, they have to invest (put development resources) on the products depending on the market trends, profits from each product,…etc. That’s why its important to be able to switch developers from a product to another to be reactive.

Some agile principles helps for this:

• iterations and time boxed releases to have reactivity when some resources are removed from a project,
• sharing knowledge instead of specialization to be allow reallocation,
• pair programming to reduce learning curve when new developers are working on a new project.

I tend to think that agility is maybe not always that relevant for small company, but its certainly a must have for large software company to be reactive.

Agile methodology are based on the capacity to make the code evolving. Extrem Programing have some principles around that as simple design and continuous refactoring for example. Notice, that the aim is not to anticipate future evolution.

Even out of an agile perspective, this is a good practice to keep code simple, maintainable, easy to make evolve and avoid what I call the Critical Code Mass. This post of Kevin Barnes on The Code Garden is worth to be read and is also talking about code evolution capability.

All this is about complexity of code, but this does not means thousands or millions lines of code. Of course, having a very tricky algorithm written with a too large code base will create difficulties when an update will have to be done: a new developer will need time to explore this code before doing the change (maybe even do some prototypes). Even the author himself of the code maybe request additional time to test the change before checking in.

The Critical Code Mass can also be achieved on a very small code base, for example, when the algorithm have kind of magic: few lines of code, but it is not obvious how it work and even why it is working. Implementing a change can also be a challenge.

I think it is really important to take care of this Critical Code Mass if you do not want to let your program behave like a black whole. This evolution of the code is silent and do not appear suddenly. If all the development team is not aware of this and do not pay attention to avoid it, the projects evolutions will become more and more difficult and long.

Take the time to look at this vidéo, it’s one hour long, but worth it.

Agile methodology are far less adopted than traditional waterfall methodology. Is it due to a lack of maturity? Maybe yes. I think Agile methodology will continue to evolve and this is a good thing.

I think that agile methodology are misused and people is emphasing too much the test versus design which is not to me the original sense. The ‘behaviour’ is really the unit of mesure of the business value provided by a software.

Product owner is a role within scrum methodology that represent the customer. The question is about a team that would like to apply Scrum methodology without such role.

The answer is definitely “No” obviously. How to use such methodology in an organization that do not provide such role. I think this can be hardly achieve by managers assuming this role but they have to be fair. The team will assume its responsibilities (sizing, self organization…etc) and the manager will validate the acheivement of the stories even if this has no value from a customer point of view. The manager then will do the buffer with the “real” customer, and takes his responsibilities.

The hard point is for the manager:

• have an iterativ approach at least (1 month is perfect) 
• create new user stories if the customer is not fully satisfied with the implementation and track them as new items,
• describe precisely the content of the user stories to help the team do a precise and accurate sizing,
• provide support to the team if they have questions on the impelmentation during the srpint,

The key point is not to have a manager which is only simple bridge between the customer and the dev team, but fully assume the role of Porduct Owner. Sure this is not easy, but this can be done this way.