La différence entre un script et une plateforme
Un script peut automatiser une tâche. Transformer cette automatisation en produit fiable demande de résoudre un ensemble de problèmes beaucoup plus large.
Oblivion a commencé beaucoup plus près d'un script que d'une plateforme.
Les scripts sont incroyablement utiles parce qu'ils permettent de faire passer une idée de la théorie à la réalité rapidement. Ils aident à tester un concept, à retirer du travail répétitif et à prouver que l'automatisation peut créer de la valeur.
Mais il existe un moment où ajouter plus de code à un script ne résout plus le vrai problème.
À partir du moment où d'autres personnes doivent dépendre du système, les exigences changent.
Un script résout ton problème
Quand on construit un logiciel pour soi-même, on le comprend déjà.
On sait quels paramètres sont dangereux, ce qu'une erreur veut probablement dire et quand redémarrer quelque chose est sans risque. Un script personnel peut s'appuyer sur cette connaissance parce que l'utilisateur et le constructeur sont la même personne.
Un produit ne peut pas faire cette hypothèse.
Le logiciel doit communiquer son propre état, valider ses entrées et se comporter de manière prévisible sans exiger que la personne qui l'a écrit reste à côté.
Les utilisateurs changent la définition de terminé
À mesure qu'Oblivion grandissait, des responsabilités qui vivaient auparavant ensemble ont eu besoin de frontières plus claires.
L'exécution, le monitoring, la configuration, l'état runtime et le comportement visible par l'utilisateur sont devenus des sujets différents. Dès que d'autres personnes interagissent avec un système, l'onboarding, les permissions et le comportement prévisible deviennent eux aussi une partie du problème d'ingénierie.
Cela a changé ma manière de juger le progrès.
La question n'était plus seulement de savoir si l'automatisation fonctionnait pour moi. Elle était de savoir si la plateforme pouvait s'expliquer, protéger les utilisateurs contre les erreurs évidentes et continuer à se comporter de manière cohérente quand l'environnement changeait.
Les plateformes demandent une discipline opérationnelle
Un script peut échouer bruyamment et attendre que son créateur enquête.
Une plateforme a besoin d'un modèle opérationnel plus solide. Elle a besoin de logs qui restent compréhensibles plus tard, d'alertes qui pointent vers de vrais problèmes, de chemins de récupération qui ne dépendent pas de la mémoire et d'interfaces qui réduisent l'ambiguïté.
Rien de tout cela ne semble très excitant comparé à la logique de stratégie.
Mais sans cela, l'automatisation reste fragile. La partie utile existe, mais elle est entourée d'hypothèses que seul le constructeur original comprend.
La confiance devient une partie de l'architecture
Une plateforme ne se définit pas seulement par le nombre de fonctionnalités qu'elle possède.
Elle se définit par la capacité des gens à lui faire suffisamment confiance pour s'appuyer dessus. Dans un logiciel de trading, cette confiance doit être gagnée par la clarté, les limites, la récupération et la cohérence.
C'est ce qui a poussé Oblivion à sortir de la logique d'un outil pour aller vers celle d'un système.
Le code compte toujours, mais les garanties autour comptent tout autant.
Avec le recul
Un script prouve que quelque chose peut fonctionner.
Une plateforme doit prouver qu'elle peut continuer à fonctionner, évoluer et être utilisée par des personnes autres que son créateur.
Cette différence est devenue l'un des défis d'ingénierie les plus importants d'Oblivion.