Cet exposé technique porte sur le développement technologique en général, mais peut-être plus particulièrement sur le développement technologique progressif. Il est évidemment influencé par ma propre expérience dans l'industrie de l'optique, où le module optique n'est qu'un composant d'un système plus vaste combinant diverses disciplines d'ingénierie allant de la mécanique à l'optique, en passant par les mathématiques et les logiciels.

Expectations – make sure to manage them

Toutes les choses simples ne le sont pas. Si l'on rend suffisamment de choses simples dépendantes les unes des autres, le résultat n'est souvent plus simple. C'est souvent le cas des intégrateurs de systèmes qui peuvent externaliser ou acquérir des composants haut de gamme, ajouter leur propre technologie de niche et leur connaissance du marché pour assembler des produits complexes.

Eventually, the question becomes, do we meet the expectations? What expectations? In a mature market, expectations are fairly well known. Sometimes, expectations are set by the fundamental physical limits. Many mature products operate at some small factor above limits set by fundamental physics. Your phone is one such example. Already 25 years ago, phone receivers operated not that many dB above the noise limit set by temperature and Boltzmann’s constant.

Cependant, certains produits sont encore en train d'atteindre ces limites. Au nom de la diligence raisonnable, chaque propriétaire de produit ne devrait-il pas savoir où se situe son produit par rapport aux limites fondamentales ? Au fur et à mesure que les produits (dans les segments haut de gamme) mûrissent, ils tendent à atteindre ces limites.

Le brouillard de var

No, I didn’t spell that wrong. You read that correctly. So what do I mean by that? This tech talk is about system integrators and in this context, that would mean, someone who assembles a product with many moving parts which the final result depends on. As engineers, we know about calibration. This allows us to compensate for some fairly complex phenomena as long as they are repetitive, be it in time or space. For this reason, the quality of many products is measured in how far, or rather, how close, we follow the nominal target on average. The measure for this is usually the variance, but since we like to talk about primary variables instead of squared ones, we prefer to take the square root, and instead we talk about standard deviations. Nevertheless, the underlying measure of quality emerges from a sum of squares of (often) independent phenomena.

Le dilemme de l'incrémenteur

This is not a dig at Clayton Christensen, but it is about the pros and cons of incremental engineering, especially in the context of system integrators. When we are measured by a quality number based on a variance, the knowledge of what ails our product can be dramatically blurred because of the nature of a large sum of squared errors, eventually represented as a standard deviation. Say we jump into a project and completely squash one of those errors, and in the end, all that effort was rewarded by a 3% improvement in the standard deviation by which we benchmark our product. That is not a fun meeting with the management. We spent 3 or 6 months of profit on a marginal performance improvement. Won’t happen again.

Et maintenant ? Cessons-nous de nous améliorer ? Avons-nous atteint les limites physiques ? C'est ici que nous devons savoir exactement comment et pourquoi les produits que nous construisons fonctionnent. Des erreurs assez importantes peuvent être cachées dans une variance et, si nous ne nous penchons pas sur les détails, nous ne saurons pas laquelle cibler en premier tant que nous n'aurons pas réussi à écraser une multitude de contributions mineures qui la dissimulaient. Et il y a un risque que nous n'ayons jamais l'occasion d'y arriver.

Une anecdote

J'ai ici une anecdote de mon propre passé, l'étalonnage d'un modulateur spatial de lumière à miroir basculant (SLM). Cette question, qui peut sembler simple aujourd'hui, était considérée comme difficile à l'époque. Pour la résoudre, j'ai construit un modèle contenant ce que je pensais être les variables pertinentes. J'ai testé plusieurs idées et l'une d'entre elles a fini par s'imposer.

However, my approach was met with scepticism. The machine did not perform to expectations, and I received a fair amount of blowback. However, since I did pay attention to detail, I knew all intermediate results during the calibration process were perfectly aligned with model expectations. And here lies the first lesson, to keep track of our expectations. Therefore, I didn’t need to keep my head down too much, the problems were not in the algorithm. It took almost three years for the SLM charging and mechanical drift problems to be solved, and lo and behold, the algorithm started to deliver the results anticipated in the model.

Le fait de disposer d'un modèle suffisamment détaillé s'est avéré crucial au cours de ce développement. Il m'a fallu moins de deux semaines pour l'écrire, et c'était déjà ma première tentative. Chaque seconde en valait la peine. Je suis certain que sans cela, j'aurais plié sous la pression en essayant de résoudre des problèmes qui n'étaient pas les miens.

A retenir

So, what is the takeaway from all this? From my early days 25 years ago, all the way until as late as last week, I am reminded of the value of knowing what the result should be. How the product should perform. Whatever I have developed, it has been my goal to know how the product performs before it is built. Not always possible, but the ambition produces invaluable insights. Sometimes there are no shoulders of a giant to stand on. When short on giants, build models- models detailed enough to capture the complexities of your product, so you know what to expect when you turn on the light.