fplanque: Techno

This thread in Ask Joel is the most interesting discussion I've ever read abut offshoring/outsourcing software development!

It's getting incredibly long though, so it's really hard to read through. But the first 25 comments are definitely worth reading.

My personal take on the subject is roughly this: I believe software is art more than science. I think the best approach to make it look like engineering is something along the Unified Process - that's what the IT world has learned the hard way for the last 30 years! One golden rule of UP is to have the users and the coders communicating, to have them understand each other's constraints...

This doesn't mean I think nothing can be outsourced, but you certainly cannot carelessly offshore a whole IT department to a place with a radically different culture and expect that communicating with specs will "just work"! :|

If offshoring software development is ever going to succeed we'll need a whole new set of skills and tools (internet being one of them) to master it, and we're not even close! However, I think the experience of open source software projects developped by an international community are an interesting experience to this.

I would probably elaborate on this if I wasn't this busy reading the thread at Joel's right now! :>>

Cela fait probablement une bonne décennie que les entreprises ne jurent plus que par la rentabilité maximale du mètre carré, créant ainsi des opens spaces à tout va.

Toutefois, c'est avec un certain bonheur que j'entends aujourd'hui quelques manifestations de retour à la raison: celle de la rentabilité maximale du salarié (:!:) lorsqu'on lui offre un environnement de travail plus confortable, ou du moins plus propice à la concentration ou à l'efficacité.

Voir par exemple le dossier de JDNet, ou au moins les principes de base.

Malheureusement, les initiatives de la conception de bureaux poussées à l'extrême telles que celle de Joel Spolsky risquent des rester des exceptions...

Ceci dit, une des principales motivations de la démarche de Joel est de se créer un avantage concurrentiel tangible afin de lui permettre de recruter la crême des développeurs. Je me demande qui osera transposer cette démarche à du personnel moins qualifié... :?:

Ce week-end, j'ai fini la lecture du livre de Lou Gerstner: "J'ai fait danser un éléphant".

C'est l'histoire d'un très gros constructeur de très gros ordinateurs sur le déclin, pire: déjà enterré par les médias lorsque Gerstner en prends la présidence, en 1993. C'est l'histoire d'une entreprise de services de premier plan, prospère et respectée de tous en 2002.

Les histoires de redressement d'entreprises ne sont souvent pas très passionnantes, voire plutôt déprimantes sur le plan social. Mais celle-ci, je vous la recommande! Surtout si vous avez vous même vécu cette décennie de transformations profondes dans le secteur de l'informatique.

Personnellement, ce que j'ai trouvé le plus croustillant, c'est la manière de Gerstner d'aborder la net-économie. Il faut se rappeller que c'est IBM qui a inventé le terme de e-business! Mais ce n'est pas pour autant que l'entreprise s'est laissée emporter par toutes les modes et les excès de la net économie... Non, Gerstner, c'est plutôt le triomphe du pragmatisme, autant sur l'immobilisme que sur la course en avant effrénée et irréfléchie...

Grosse leçon de sagesse managériale! :b

"Lorsqu'un dirigeant qui a bonne réputation rencontre une société qui a mauvaise réputation, c'est la réputation de la société qui reste intacte."

-Warren Buffet

Traditionnellement, on se disait que pour développer plus vite, il fallait soit faire travailler plus de développeurs, soit les faire travailler plus longtemps chaque jour.

Le problème avec plus longtemps chaque jour, c'est qu'il ne tiennent pas longtemps! :roll:

Le problème avec plus de développeurs, c'est que la collaboration devient de plus en plus complexe et la gestion de plus en plus importante. Il faut une répartition des tâches minutieuse, une modularité exemplaire et un système de gestion de code source à la hauteur.

Tout ça coute cher... très cher... souvent trop cher et il reste plus rentable, dans de nombreux cas, développer moins vite, avec moins de développeurs! :|

Une autre alternative consiste à décharger le développeur des tâches ingrates de manière à ce qu'il puisse se concentrer sur l'essentiel. Le développeur appréciera souvent de se faire livrer à déjeuner... et parfois même à diner (ne pas abuser du régime pizza, ça lasse et la lassitude nuit à la créativité)... Mais plus sérieusement, il appréciera que quelqu'un d'autre s'occupe de la documentation... et par dessus tout: ce dont le développeur moyen à horreur: c'est le testing! Il repoussera toujours les tests à plus tard alors qu'il serait en fait plus judicieux de tester tout au fur et à mesure des modifications, avant qu'on ait oublié ce qu'on a bien pu modifier exactement et qui puisse provoquer tel ou tel bug... (Je ne m'étends pas sur la nécessité de tester le plus rapidement possible, c'est une vérité communément avérée! :|)

Lire la suite »