La enseñanza que sacó Dubray de su experiencia tiene dos aspectos: uno, respecto a la evolución de la industria del software, que no necesariamente coincide con los intereses del usuario de la tecnología:
I discovered NeXT and NeXTStep in 1990 at Penn State and it was love at first sight. I was inspired, from the very first second after years of programming in Turbo Pascal. It is hard to believe for most people that something like Xcode was available as early as 1989. I had built two solutions with NeXTStep: a Laboratory Information Management System (LIMS) and an Industrial Process Control System. It was not easy but the results were incredible.
NeXTStep was so productive that a very small team of 2 or 3 people could write software that was vastly superior to the one written by much larger teams (10-50). I still remember a professor from Stanford visiting us at Hughes Research Lab and looking at these two products (at the time I had also added a Natural Language Interface to the Process Control Software to log process data in the LIMS and define control rules), his jaw dropped on the floor.
Yet, around 1994, NeXT started to fail. You had already moved to create OpenStep (a port of their APIs to Sun -yet incompatible with NeXTStep) and all together in 1997, NeXTStep was packed in boxes and moved to Apple. It resurfaced nearly a decade later. You can easily imagine how these two "strategic" moves impacted my business and my customers. Yes, devastating doesn't really qualifies.
Software vendors are always looking for new customers, they compete against each other and ultimately they have no commitment to their past customers. I actually don't know a single Platform Software Vendor which understands and focuses on helping their existing customers migrate to new versions of their platform. They simply don't care, older customers are just collateral damage.Su segunda conclusión es que ya nunca encarará la construcción de software comprometido técnicamente con un proveedor, sino que se apoyará en el desarrollo basado en modelos:
I have learned my lesson, never, ever will I write code directly tied to a set of APIs.Jean-Jacques expresa un punto de vista importante en el estado actual del mercado del software: en un universo de negocios cambiantes, donde la tecnología es infinitamente variada, y donde es difícil contruír soluciones estables porque el ciclo de vida de las aplicaciones es crecientemente corto, comprometerse con una solución basada en una tecnología es peligroso. Y orientarse hacia el desarrollo basado en modelos es preventivo: difícilmente un cambio de tecnología afectará la especificación del software. Existen distintas variantes de desarrollo basado en modelos; cualquiera de ellas ofrecerá mejores perspectivas que un diseño apegado a un lenguaje, o infraestructura, o plataforma específica. En el estado actual de la industria, cada variante de lenguaje o plataforma se acerca a ser un commodity, y es el desarrollo basado en modelos el que permite manipular esta diversidad.
(...) NeXT shaped my mind to build model-driven software. Somehow, I could never go back to just writing imperative code ever again. Around 2005, my understanding of MDE became a lot more formal with the emergence of DSL Tools and Eclipse Modeling Framework and later XText and Oslo.
Ever since I understood how deadly, and frankly stupid it was to tie your solutions to vendor APIs, I spent lots of time developing strategies to become technology and architecture independent.