Post intéressant de Tom Preston-Werner à propos des débuts de GitHub :

When I’m old and dying, I plan to look back on my life and say “wow, that was an adventure,” not “wow, I sure felt safe.”

http://tom.preston-werner.com/2008/10/18/how-i-turned-down-300k.html

Au fil du temps tout ces morceaux de code qui populent votre application et que plus personne n’utilise finissent par vous ralentir de façon dramatique et vous causent souvent les pires mots de tête. C’est pourquoi il est essentiel, avant de développer de nouvelles fonctionnalités, de vous assurer que celles-ci sont réellement nécessaires et seront utilisées.

Oubliez la “sauce” et les besoins incertains, et mettez votre énergie sur ce qui compte vraiment! C’est une remise en question qui sera bénéfique aux développeurs autant qu’au clients dans le moyen terme.

Just as Taiichi Ohno called overproduction the worst waste in manufacturing, unused features are the worst kind of waste in software development. Every bit of code that is there and not needed creates complexity that will plague the code base for the rest of its life. Unused code still requires unnecessary testing, documentation, and support. It will do its share of making the code base brittle and difficult to understand and change as time goes on. The cost of complexity in code dominates all other costs and extra features that turn out to be unnecessary are one of the biggest killers of software productivity.

Humans suffer from a bright’n’shiny complex, where we’re titillated by the new. Think of it like this: have you actually done anything with that last domain you bought? No. You had the idea for it on Tuesday morning and you got all fred up, so you bought the domain the moment you got in to work. At lunch you furiously doodled your design in your notebook, fully intending to get home and get started on the HTML/CSS, and then you got home…and watched Lost.

Take the bright’n’shiny complex and apply it to your entire group, where everyone is prioritizing their day by their particular inspiration, and it’s shocking that we collectively get anything done.

Management is the art of choosing what not to do

What I’m telling you is that management is the art of choosing what not to do, which means you need to be ready and willing to look at the task at the end of a day and ask, “OK, I made this urgent this morning. A day has passed and I had time, but never got to it. Does it matter?”

Priority is relative. What felt so important last Wednesday loses importance five days later when the larger context of your week, your month, and your career shows up. You need to develop a practice of strategic information shedding where you are constantly and intelligently jettisoning ideas and work.

Bilan :

Arrêtez de vouloir tous trier, tout prioriser, tout associer à des dates de livraisons. La vérité c’est que tout va changer et que ce qui est votre priorité aujourd’hui ne le sera fort probablement pas demain.

Surtout, acceptez qu’il est correct de “détruire” une todo. Il est inutile de conserver 6 ans de tâches prévues d’avance dans un monde où il rentre toujours plus d’ouvrage que nous sommes capable d’en sortir. Rendez-vous service et faites le ménage de vos liste. Si ces tâches sont vraiment importantes, elles vont revenir d’elles-mêmes

Predictable outcomes are one of the key expectations that the marketplace imposes on companies and their senior management, and these expectations eventually flow down to software development. Unfortunately, software development has a notorious reputation for being unpredictable, so there is a great deal of pressure to make it more predictable. [...]

Because we assume that our predictions are facts, we tend to make early decisions that lock us into a course of actions that is difficult to change. Thus, we lose our capability to respond to change when our predictions turn out to be inaccurate. [...]

We forget that the predictions of the future are always going to be inaccurate if they are 1) complex, 2) detailed, 3) about the distant future, or 4) about an uncertain environment. [...]

There are, however, well-proven ways to create reliable outcomes even if we canot start with accurate predictions. [...] Fundamentally, an organization that has a well-developed ability to wait for events to occur and then respond quickly and correctly will deliver far more predictable outcomes than an organization that attempts to predict the future.