marketing - roadmap template

¿Alguna vez te has quemado las manos con alguna tecnología nueva e inmadura? (30)

En mi opinión, sin embargo, es crucial para el éxito en la industria del software mantener el ritmo de la innovación.

Esto no responde a su pregunta específica, pero hay un libro llamado Crossing the Chasm que podría interesarle.

A menudo oigo a la gente decir que no debe apresurarse a adoptar nuevas tecnologías hasta que se hayan estabilizado, probado y probado. Incluso hay una broma sobre cómo se necesitan 3 versiones para hacerlo bien. Esta podría ser la voz de la experiencia de la vida real, pero al menos a veces esa postura es el resultado de la complacencia, la resistencia al cambio y el esfuerzo necesarios para aprender nuevas habilidades.

En mi opinión, sin embargo, es crucial para el éxito en la industria del software mantener el ritmo de la innovación. Mientras que las grandes empresas tienen departamentos enteros dedicados a la I + D, en las empresas más pequeñas son los equipos de desarrollo los que deben mantener el ritmo. Embárcate en la nueva tecnología incluso antes de que salga oficialmente: esto te dará una ventaja inicial y te ayudará a seguir el ritmo del resto.

Esta es la estrategia que trato de seguir siempre que sea posible:

Sé agresivo adoptando nuevas tecnologías
Utilice betas tempranas para experimentar y prototipos y RC para el desarrollo
Dirija cualquier cambio de última hora al producto cuando salga a la luz la versión oficial de la tecnología que adoptó con anticipación.
No confíes en algún oscuro proyecto de código abierto con 0 actividad
Asegúrese de estudiar, pero tome con una hoja de ruta oficial de productos de grano de sal.

Hasta ahora, nunca pagué el precio de ser demasiado entusiasta para saltar en un tren de nueva tecnología, aún así obtuve los beneficios. Me pregunto si esto es solo una coincidencia o quizás ser un adoptante temprano no es tan peligroso después de todo.

Más que invitar a una discusión sobre el tema adopción anticipada, ya que tal tema seguramente será polémico y subjetivo, me gustaría escuchar experiencias de la vida real donde la adopción de nuevas tecnologías demostró ser un grave error y tuvo que pagarse un precio terrible. pagado.

El marco web de TurboGears

Tenía una aplicación web para escribir y salté sobre esto (habiendo escuchado de un amigo). No estaba realmente al tanto de las alternativas, no conocía MVC correctamente y no tenía conocimiento de las alternativas a los diversos componentes ''estándar'' (por ejemplo, SQLAlchemy en lugar de SQLObject). Si bien la documentación y el estado general del proyecto es mucho mejor de lo que era cuando me ensuciaba las manos, terminé con una gran aplicación que dependía de "trucos" para eludir algunas de las características mágicas y tenía muchas características no documentadas en él. para cumplir con los plazos. Se convirtió en una pesadilla de mantenimiento y realmente me gustaría haberme tomado el tiempo de construir algo más simple con planes para una nueva redacción si los requisitos cambian.

Esta era la serie 1.x que ha quedado obsoleta ahora para la serie 2.x basada en Pylons. Como se puede imaginar, el equipo central en sí mismo decidió realizar una búsqueda, pero yo tuve que recurrir a una aplicación heredada que tuve que mantener.

Por falta de presencia en el mercado:

Go de Google
- Pobre toolchain, carece de integración con compiladores populares y C.
Python3000
- Carece de las características imprescindibles: los Iteradores, las partes internas limpias y las interfaces más ordenadas son agradables para nosotros los usuarios incondicionales, pero la mayoría quiere rendimiento, y esto no se ha entregado.
C ++ 0x
C99
- Han pasado 12 años y ningún compilador convencional implementa esto completamente. Proyectos populares y arquitecturas de nicho permanecen en C89 para estar seguros.

Por mala calidad:

Windows Vista
- ''Dijo Nuff.
Forzosamente
C ++

Para rezagarse río arriba:

PyGTK en Windows
Soporte de MSVC C

Tenga en cuenta que mi inclusión en la lista de estas tecnologías de ninguna manera sugiere que no sirvan, soy un gran admirador de todos estos (excepto los de mala calidad). Mi opinión sobre ser consumido por estas tecnologías es de primera mano (por lo general, trato de impulsarlos como sustitutos de la tecnología existente, o simplemente de encontrarme con barreras después de que ya se haya realizado una inversión importante.

AzMan (Administrador de Autorización de Microsoft)

Comenzamos a usar esto en un sitio web público / aplicación web, atraídos por los sueños de inicio de sesión único y las afirmaciones de poder "aprovechar su infraestructura existente" o lo que dice el discurso de marketing ahora. Una solución de acceso directo para ASP.NET que los administradores de sistemas podrían administrar sin tener que desarrollar ninguna herramienta o escribir ningún código. Fue ganar-ganar, ¿verdad?

Aprendimos varias cosas como resultado de nuestra decisión, ninguna de las cuales queríamos aprender:

Active Directory en sí mismo no es una opción muy buena para un mecanismo de autenticación que da servicio a un sitio web público. No es que no sea capaz, es bastante capaz, pero es como contratar un doctorado para escribir una aplicación "Hello World". Está sobrecualificado, hace mucho más de lo que podrías necesitar en ese contexto, es mucho más difícil trabajar con él que con una simple tabla SQL antigua, y requiere mucho más mantenimiento.
AzMan es lento. Muy, muy lento El proveedor del rol debe mantener un caché , lo que debería indicarle de qué tipo de rendimiento estamos hablando. Nunca entendí por qué era tan lento, pero imagino que tiene algo que ver con el nido de insectos de los protocolos COM y de red de los que depende.
Un caché (ver arriba) puede ser algo muy peligroso cuando tienes poco o ningún control sobre él. Cuando agregamos nuevos usuarios de forma manual (es decir, a través de una aplicación administrativa en oposición al sitio mismo), esos usuarios terminarían con una pantalla "no autorizada" hasta que el caché expirara y se desconectaran. Algunas veces esto incluso les pasaría a los usuarios que se auto-registraron en línea; nunca descubrimos por qué.
Las herramientas fueron horribles Eche un vistazo a la consola de AzMan si no me cree, o lea parte de la documentation si realmente quiere un dolor de cabeza. ¿Por qué debería ser algo tan complicado?
Fue escamoso. Muchas veces el proveedor simplemente dejaba de funcionar, escupía errores COM crípticos (¡uno diferente cada vez!) Y teníamos que reiniciar IIS o incluso todo el servidor web para que cooperara nuevamente. También teníamos una configuración de confianza de dominio, porque obviamente no queríamos 50,000 cuentas de usuario público en nuestro dominio corporativo interno. El único problema era que los administradores tenían que iniciar sesión en cuentas administrativas en el dominio secundario para administrar roles porque la consola no funcionaría. de formas misteriosas si intentó usarlo desde la primaria (incluso como administrador de empresa con derechos de administrador de dominio en el dominio secundario).
El soporte era prácticamente inexistente. Si utiliza el proveedor de funciones SQL Server básico (que no, pero solo como ejemplo), hay 10 millones de tutoriales y puede buscar cualquier mensaje de error o hacer preguntas en cualquier foro. Cada vez que algo salía mal con AzMan o queríamos hacer algo nuevo, era una lucha constante encontrar buena información.
La integración del código fue incómoda. Tuviste que pasar por un montón de capas COM desordenadas y la interfaz apestaba. Si no recuerdo mal, no había forma de hacer una simple verificación de autorización: tenía que descargar toda la aplicación / registro de roles. Esto fue hace mucho tiempo, por lo que mi memoria podría estar nublada en ese aspecto.

Finalmente, no pudimos soportarlo más y decidimos arrancar todo el sistema para un sistema interno basado en un par de tablas SQL Server, que es probablemente lo que deberíamos haber hecho desde el principio. La migración fue dolorosa (ver los dos puntos anteriores), pero lo logramos y nunca miramos hacia atrás.

¡Sí tengo! ¡Con JSF 1.0! Parecía que Sun no lo revisó bien antes de lanzarlo.

Hemos estado tratando de hacer que las cosas funcionen, pero en un momento acabamos de descubrir que nuestros errores fueron causados por errores JSF y tuvimos que usar soluciones temporales. No fue hasta JSF 1.1 y el uso de implementaciones myfaces-tomahawk que el proyecto comenzó a tener cierta velocidad.

¿Alguien más recuerda OpenDoc, la idea de Apple sobre cómo se escribirían todas las nuevas aplicaciones para Mac? No lo creo

¿Alguien notó la tendencia aquí? La mayoría de las tecnologías aquí fueron creadas y canceladas o modificadas por microsoft ...

También me he quemado por Microsoft con los cambios realizados en el marco de la entidad.

API de carbono de 64 bits en Mac OS X: No me quemé personalmente por esto, pero tengo un amigo que trabaja para una gran empresa de software que pasó un año convirtiendo casi todo su código para usar las API de carbono de 64 bits solo para encontrar en WWDC que esas API ya no estarían disponibles.

Actualmente estoy en proceso de quemarme con el soporte CustomXML de Microsoft Office Word 2007.

CustomXML permite que el documento tenga elementos definidos personalizados que pueden modelar datos comerciales, etc. Por ejemplo, podría definir un XSD con sus elementos personalizados, asociarlo con un archivo docx, luego generar los marcadores de posición como etiquetas CustomXML y navegar / modificar los documentos usando C # (u otros lenguajes .NET) y OpenXML SDK . El beneficio de OpenXML es que desacopla la necesidad de tener Office instalado en una máquina servidor para fines de automatización y es una alternativa a la compra de bibliotecas de terceros.

En resumen, hubo una demanda en relación con la capacidad de Word 2007 para abrir documentos con XML definido personalizado. De este artículo :

El 11 de agosto, la compañía recibió un mandato de venta de Office Word ...
"Esta medida cautelar se aplica solo a las copias de Microsoft Word 2007 y Microsoft Office 2007 vendidas en los EE. UU. A partir de la fecha de la medida cautelar del 11 de enero de 2010. Las copias de estos productos vendidas antes de esta fecha no se verán afectadas".

La respuesta de Microsoft es eliminar el soporte para CustomXML de versiones futuras de Word y está lanzando un parche que eliminaría por completo esta capacidad. Aquí está el enlace a la actualización oficial . Según este sitio de Microsoft OEM Partner Center :

El siguiente parche es obligatorio para los Estados Unidos. El parche funcionará con todos los idiomas de Office 2007.
Después de instalar este parche, Word ya no leerá los elementos XML personalizados contenidos en los archivos DOCX, DOCM o XML. Estos archivos continuarán abriéndose, pero se eliminarán todos los elementos XML personalizados. La capacidad de manejar el marcado XML personalizado generalmente se usa en asociación con el procesamiento automatizado basado en servidor de documentos de Word. Normalmente, la mayoría de los usuarios finales de Word no utilizan XML personalizado.

Me imagino que un pequeño porcentaje de usuarios finales y desarrolladores lo usan, por lo que considero que la última frase es precisa. El problema es que actualmente no hay palabras (sin juego de palabras) sobre cómo avanzar para los proyectos que sí utilizaron esta tecnología. CustomXML es la piedra angular de un gran proyecto en el que estoy trabajando actualmente. El impacto de esta decisión no es positivo e impide de manera efectiva cualquier compatibilidad con versiones posteriores, ya que no existe un enfoque alternativo equivalente que mantenga la estructura proporcionada por CustomXML.

Algunos de mis compañeros de trabajo y yo tenemos un gran conocimiento sobre el tema ... Supongo que es bueno que no hayamos escrito sobre el blog como lo habíamos planeado :) Hemos logrado algunas proezas bastante impresionantes con esto y el VSTO, pero esta noticia es decepcionante.

Si alguien está interesado en este tema, aquí hay algunos artículos para ver:

Artículos de ZDNet:

Artículos de BNet:

Artículos de Softpedia:

EDITAR: agregó un enlace a la actualización oficial.

Delphi.NET. ¡Todavía tengo un tic cuando escucho eso!

Desafortunadamente corta en ambos sentidos. Cuando comenzamos a desarrollar una gran aplicación basada en web para Windows, .NET salió en versión beta, con una versión final de .NET 1.0 no muy lejana.

Sin embargo, debido a que era nuevo, y no sabíamos lo que iba a suceder, qué tan popular sería, y si la EM lo abandonaría seis meses después. Así que nos quedamos con el probado VB6.

Todavía tenemos que mantener ese legado de VB6, y ha sido restrictivo por un tiempo. Aunque no aparece en ninguna parte, nos volvemos paranoicos de que el soporte para el tiempo de ejecución de VB vaya a ser retirado en una versión determinada de Windows.

Dicho esto, ir por la ruta .NET puede haber tenido su propio dolor: 1.0, 1.1 y 2.0 salieron bastante rápido uno después del otro, cada uno con (algunas) incompatibilidades con la versión anterior. Por lo tanto, tener que migrar la plataforma .NET hubiera conllevado un riesgo diferente. ¿Menos o mas? No puedo responder que no lo haya experimentado :-)

Al final, puedes ser condenado si lo haces y maldito si no lo haces. Si alguien puede leer las entrañas para determinar si una determinada tecnología va a tener éxito en un momento dado, entonces no debería tener un trabajo en Software, y probablemente debería recurrir a la administración de fondos de cobertura, hacer un montón de efectivo y jubilarse anticipadamente: -)

Esto aborda su discusión más que su pregunta. Creo que está asumiendo que el costo beneficio de adoptar nuevas tecnologías es un hecho. Para una corporación muy grande, las tecnologías cambiantes pueden costar cientos de millones de dólares. Si el costo beneficio no está allí, entonces se pueden guardar los cientos de millones. La mayoría de las empresas usan la tecnología para hacer algo diferente y no pueden darse el lujo de consumir nueva tecnología simplemente porque existe. Cuando el beneficio de costo está allí, entonces tiene sentido hacerlo.

Estoy increíblemente cerca de la llama todos los días al ser uno de los primeros adoptadores de MonoTouch. Nunca sé qué va a pasar después con este marco. Pero para su crédito, el equipo de Novell está a la espera con extintores casi las 24 horas, los 7 días de la semana :)

Hace varios años, hicimos un uso intensivo de la nueva característica de SQL Server 2005 llamada Notification Services. Para nuestra sorpresa, eso se ha suspendido en SQL Server 2008. Este fue un problema grave, hizo que el arquitecto del software cuestionara todas las nuevas tecnologías de Microsoft.

Aquí hay algunos detail y algunos more y algunos more

También ha habido problemas con Entity Framework de Microsoft.

Lo peor es cuando obtienes un 80% a través de un proyecto usando un nuevo producto y aciertas con un error espectacular.

A mediados de los 80, mi jefe me sugirió que probara una nueva alternativa de dBase llamada KnowledgeMan. Estaba lejos cuando me di cuenta de que algunos errores cruciales que creía que eran míos eran realmente suyos. Todo el asunto tuvo que ser rehecho desde cero; me costó mi trabajo.

Mirlo.

Un maravilloso entorno de desarrollo para crear contenido interactivo para MSN.

Mozilla XULRunner.

Era Adobe AIR, antes de que hubiera AIR. Escribimos nuestro sistema de Gestión de Recursos Humanos usándolo. En ese momento, XULrunner estaba a punto de lanzarse como el motor subyacente para Firefox, por lo que esperábamos que todo lo que tendríamos que hacer es asegurarnos de que nuestros usuarios tenían instalado Firefox.

A los 2 años de iniciado el proyecto, y justo antes del despliegue, apareció un nuevo XULrunner que rompió por completo todo nuestro código y no se pudo ver el despliegue de Firefox. Terminamos implementando en nuestra versión anterior con un instalador de escritorio dedicado y lo hemos estado utilizando desde entonces, sin el beneficio de las actualizaciones de seguridad o rendimiento porque tendríamos que volver a escribir demasiado código para ser compatible. A pesar de eso, ha sido un proyecto muy exitoso con nuestros clientes.

Ahora estamos volviendo a escribir la aplicación para ejecutar en Ext, que es lo más nuevo para nosotros, pero parece tener más apoyo de la comunidad, y ofrece soporte comercial si realmente nos quedamos atrapados en algo.

No programando, pero sigue siendo un error tecnológico más reciente: casi pierdo un pezón en mi primer mini-ATX, la moraleja de esa historia es nunca inclinarme sobre un caso mientras trato de cerrarlo con fuerza cuando se atasca ...

Oh sí

Actualmente estoy sintiendo el dolor de ser uno de los primeros en adoptar Fortran 2003 :-)

marca

Para mí, IntraWeb de Delphi era eso.

Podría contar muchos de ellos. El que todavía me duele cuando lo pienso es WLPI (un antiguo producto de flujo de trabajo de BEA). Nunca funcionó y el vendedor lo abandonó. Suspiro ...

De todos modos, diría que estar al día con lo último (saber lo que hay allí, considerándolo) es muy valioso, pero solo vivir a la vanguardia si:

Estás preparado para recibir cortes y pérdidas (dinero / tiempo / recursos)
Proporciona una importante ventaja / competitividad estratégica.

Un buen ejemplo para esto es AJAX. Ahora es lo suficientemente maduro como para que cada nuevo sitio web lo haga a menos que tenga una razón convincente para no hacerlo, pero cuando se hizo posible, un sitio web creado con él habría sido muy costoso en comparación con la alternativa tradicional.

Algunos sitios web necesitan la última apariencia para seguir siendo competitivos, incluso hasta el punto en que las características del sitio en sí mismas son secundarias y deben ser los primeros adaptadores de AJAX. Otros no lo hacen. Sepa quién es usted y actúe en consecuencia.

Puedo escribir un buen Applet de Java. Todas las tecnologías se quedarán en el camino eventualmente, pero esta tuvo un fuerte aumento y caída.

QBASIC nunca despegó realmente. Pasé años aprendiéndolo también.

De acuerdo, para ser justos, era mi primer idioma y una buena forma de aprender. Y luego fue reemplazado por Visual Basic, luego VB.NET. Entonces no fue una pérdida total de mi tiempo. ;)

La mayoría de las veces, incluso si un idioma no "despega" exactamente, sigue siendo una buena experiencia de aprendizaje que se puede aplicar a otra cosa.

Sí. Soy un programador Lisp: todo se ve nuevo e inmaduro para mí. :-)

Scala.

Se ve muy bien en papel, así que escribí un proyecto con él mientras me aseguro de mantener mi versión de Scala actualizada. El número de versión (2.7.x) y sus años de desarrollo me hicieron sentir relativamente seguro al hacer eso.

Bueno, cometí un error. ¿El problema? Grave falta de documentación y ejemplos de código, así como una biblioteca de clases en constante cambio (dos veces durante mi trabajo, el código que antes funcionaba comenzó a recibir advertencias "obsoletas" ... y estoy hablando en el lapso de algunos meses y una versión similar) números).

No puedo decir que perdí mucho (este era un proyecto privado) pero no tocaré a Scala en el futuro cercano. Aún así creo que es un lenguaje muy agradable y prometedor.

True Basic

A mediados de los años ochenta, estábamos buscando una plataforma de desarrollo que funcionara en las diversas implementaciones de DOS y no fuera tan "chiflado" como C.

Encontramos True Basic, anunciado como creado por los creadores originales de BASIC en 1964. Aquí había un lenguaje que ''compilaba'' hasta p-code. No solo funcionaría en máquinas con DOS, se ejecutó en cajas GEM (Atari-ST) y Amiga.

Tenía complementos muy similares a los que estábamos acostumbrados a tener con entornos de desarrollo en las máquinas VAX / VMS que usamos. Cosas como paquetes de formularios, un complemento "ISAM" (antes de los días de bases de datos invocables en PC), etc.

Desafortunadamente, las habilidades multiplataformas nunca vendieron el idioma lo suficiente. Diablos, según Wikipedia, hay una versión de Mac OS (aunque no es OS X o Snow Leopard). Incluso encontré la página TrueBasic ''actual'' mientras escribía esta nota.

Eventualmente apareció Visual Basic 1.0 y todo el programador de BASIC, como yo, lo revisó ya que tenía el nombre de Microsoft en él. Ahora, por supuesto, 10 versiones más tarde, hemos sido dirigidos a la plataforma .Net, mientras que TrueBasic se encuentra en V5.5.

Una vez me vi obligado a usar witango , pero lo estoy superando.

VBA : pasamos mucho tiempo integrándolo en nuestro producto. Todavía pasamos mucho tiempo en cada nuevo lanzamiento para asegurarnos de no romper nada. VB6 y VBA también están basados en COM y eso es un problema si desea ejecutar como un usuario estándar y no tener acceso de escritura al registro.

Java

Estaba ansioso por comenzar a trabajar en él en 1996 y lo usé para varios proyectos. Pero para el desarrollo web siempre preferí Perl y en estos días PHP. Desarrollo de GUI terminé usando principalmente .NET. Para los pocos programas de línea de comandos que no pueden manejarse con scripts, prefiero usar Perl, Python o incluso para ese PHP.

Pocos de los programas de Java que escribí se utilizaron durante largos períodos de tiempo, mientras que algunas de mis aplicaciones pre-java todavía están en uso.

Creo que la razón principal de esto es que siempre tomó más tiempo desarrollar algo en Java que usar otro lenguaje de programación: las aplicaciones resultantes contenían menos características y eran más fáciles de reemplazar.

Como la velocidad de desarrollo suele ser un problema para mis clientes, Java tiende a convertirse en la segunda opción.

Cuando tenía 10 , mi padre intentó tocar una canción de Año Nuevo para mí en una nueva Elektronika BK-0010-01 .

Huelga decir que el sintetizador no se pudo cargar de la cinta y no hubo ninguna canción hasta que el vecino llegó con una guitarra.