La propriété est généralement abordée comme un montage financier. Qui détient le capital, qui profite de la plus-value, qui décide d’une sortie. Ces questions comptent, mais ce n’est pas d’elles qu’il s’agit ici.
Nous construisons et exploitons notre propre technologie parce que la propriété détermine l’horloge. Et l’horloge détermine l’ingénierie.
Chaque système suit l’horloge de quelqu’un
Un logiciel est toujours construit en fonction d’une attente quant au moment où quelque chose doit être vrai, et cette attente se propage jusque dans les décisions techniques.
Un système construit dans le cadre d’un contrat suit l’horloge du contrat. Le travail est cadré sur ce qui peut être livré avant son terme, ce qui est raisonnable pour les deux parties et structurellement hostile au type d’infrastructure qui ne porte ses fruits qu’après plusieurs années. Personne ne prévoit de ligne budgétaire pour le modèle de données qui rendra la quatrième année bon marché.
Un système construit pour être vendu suit l’horloge de l’acheteur. Il est façonné par ce qui peut être montré au moment de la vente, ce qui entraîne une forte préférence pour ce qui est démontrable maintenant plutôt que pour ce qui est durable plus tard. Les deux sont légitimes ; ils ne sont pas identiques.
Un système bâti sur des fondations louées suit l’horloge de son bailleur. Lorsque la plateforme sur laquelle il repose change ses prix, ses interfaces ou son orientation, la feuille de route change avec elle, que le produit en ait eu besoin ou non.
Un système que l’on construit, que l’on exploite et que l’on entend conserver ne suit qu’une horloge : celle du problème. C’est plus lent, et c’est le seul cas où la réponse à la question « quand cela doit-il fonctionner » est dictée par le problème plutôt que par un calendrier extérieur.
Ce qui change en pratique
La conséquence n’est pas que nous travaillons sans pression. C’est que la pression est technique plutôt que temporelle.
Cela change ce que nous pouvons nous permettre de refuser. Une fonctionnalité qui rendrait une démonstration plus impressionnante et le système plus difficile à comprendre peut tout simplement être écartée, parce que personne à l’extérieur de l’entreprise n’a besoin d’être convaincu ce mois-ci.
Cela change la manière dont nous ordonnons le travail. Notre ordre déclaré est la profondeur avant l’étendue : amener les systèmes actuels à maturité avant d’ouvrir un nouveau front. Cet ordre n’est accessible qu’à un propriétaire. Une équipe qui travaille selon le calendrier de quelqu’un d’autre subit une pression continue pour annoncer la nouveauté suivante, parce que c’est à ses annonces que l’on y mesure le progrès.
Cela change ce que signifie un retard. Lorsqu’un problème s’avère plus difficile que prévu, les options sont de le résoudre correctement, de le résoudre partiellement ou de modifier ce qui avait été promis. Avec une échéance externe, la première option est souvent exclue. Sans échéance, c’est généralement la bonne.
Cela change ce que nous louons. Les services courants sont loués sans hésitation, parce qu’on peut les remplacer sans toucher au produit. Ce qui définit un produit ne l’est pas : ses données, sa logique centrale et la possibilité de le déplacer ailleurs restent entre nos mains.
L’indépendance coûte de la vitesse. Ce qu’elle achète, c’est le droit d’être patient, et la patience est le seul moyen de construire quelque chose qui continue de s’améliorer après une décennie.
Le coût, en toute honnêteté
Il serait malhonnête de présenter ce modèle comme strictement meilleur. C’est un arbitrage, et le prix est réel.
Construire et exploiter ses propres systèmes est plus lent qu’assembler des systèmes loués. Nous abordons de nouveaux domaines plus lentement, parce que chacun doit arriver à maturité avant que le suivant commence. Certaines occasions passeront parce qu’elles demandaient une réponse avant que nous soyons prêts à en donner une bonne, et certaines d’entre elles auront été de véritables pertes plutôt que des refus disciplinés. Quiconque prétend que son approche n’a aucun inconvénient décrit un argumentaire commercial plutôt qu’une entreprise.
Ce que nous obtenons en échange, c’est que l’exigence d’ingénierie n’est pas négociable. Dans la plupart des entreprises, la qualité est la variable qui absorbe la pression du calendrier, non par décision, mais parce que c’est la seule variable qui conserve encore une marge. Supprimer le calendrier externe supprime ce mécanisme. Lorsque quelque chose n’est pas assez bon ici, la réponse est de continuer à y travailler, parce qu’il n’existe aucune échéance à laquelle le sacrifier.
Conserver, pas revendre
Chaque système que nous construisons est conçu pour être conservé. Cette seule décision explique la plupart des autres.
Si vous avez l’intention de vendre un produit dans trois ans, la stratégie rationnelle consiste à optimiser ce qu’un acheteur pourra voir dans trois ans. Si vous avez l’intention de le conserver indéfiniment, la stratégie rationnelle consiste à optimiser son coût d’exploitation la dixième année. Cela signifie de la documentation, des frontières, des tests et une architecture choisie pour des personnes qui n’ont pas encore été recrutées.
Ces deux stratégies produisent des bases de code différentes dès la première semaine. Nous avons choisi la seconde, et c’est la propriété qui permet de continuer à la choisir lorsque le travail avance lentement.