Justificación para aprender / implementar nuevas tecnologías de Microsoft [cerrado]

Trabajo en una gran organización de atención médica como desarrollador de software de nivel medio. Tengo más de 10 años de experiencia en la industria de TI utilizando tecnologías de Microsoft (ASP.NET y SQL Server).

Cuando voy a conferencias, campamentos de códigos, reuniones de grupos de usuarios de .net, escucho todo tipo de nuevas herramientas y tecnologías: MVC, LINQ, Entity Framework, WCF Web Services, etc. Supongo que se podría decir que me siento cómodo. zona usando las mismas cosas viejas de asp.net 2.0. Utilizo conjuntos de datos escritos para mi capa de acceso a datos. Utilizo formularios web y control de servidor rico en características con páginas maestras. Sé cómo usar SQL antiguo simple y crear consultas en mis conjuntos de datos escritos para obtener los datos que necesitan mis aplicaciones.

A lo largo de mi carrera, siempre soy sensible a no quedar obsoleto con mi conjunto de habilidades. Lo que uso actualmente funciona bien y mi tiempo de desarrollo es rápido. Pero me preocupa que si me despidieran, me preguntarían en entrevistas cuántas aplicaciones MVC he escrito. O cómo estoy con los servicios web LINQ o WCF.

Sé que no importa cuántas conferencias, libros o videos vea en alguna tecnología nueva ... Tengo que implementarla / usarla o simplemente no se asimilará. Además, a los gerentes que entrevistan no les importa cuánto alguien lee sobre algo, solo el uso real y la experiencia con una tecnología.

Tengo un nuevo proyecto para escribir. Fui a mi gerente y solicité tiempo adicional para el proyecto de aprendizaje / implementación de tecnología con la que quizás no esté familiarizado. Nuestra organización alienta a sus empleados a "aprender y crecer" y continuar con su educación. Pero siempre obtengo resistencia cuando pido más tiempo para aumentar algo nuevo para implementar. Mi gerente pregunta por razones comerciales concretas para implementar estas nuevas tecnologías. No tengo razones comerciales. Mis razones son porque no quiero quedar obsoleto. Podría decir que haría que el proyecto sea más sostenible en el futuro por otros desarrolladores, ya que en algún momento la gente podría dejar de usar estas tecnologías más antiguas, pero eso es todo lo que se me ocurre. ¿Las aplicaciones de Linq / Entity Framework / MCV funcionan mejor? ¿Tanto que los clientes (usuarios en los departamentos para los que estoy creando esta aplicación) necesitan? Lo dudo.

Estoy interesado en los pensamientos de ustedes sobre esto. ¿Muchos de ustedes tienen dificultades similares al tratar de usar las nuevas tecnologías futuras? Dudo que esté a la vanguardia de la tecnología, tampoco. ¿Hay "razones comerciales" que sacaría a la luz por usar estas tecnologías?

¡Gracias por adelantado! Perdón por el largo muro de texto.

No volverse obsoleto parece una buena razón comercial para usar nueva tecnología. Fluye en ambos sentidos. No desea que su conjunto de habilidades quede desactualizado, pero a su jefe también le debe preocupar que no pueda encontrar empleados dispuestos o capaces de trabajar en tecnología obsoleta. Si la mayoría de los desarrolladores y empleadores dejan una tecnología antigua por una nueva, eso podría ser motivo suficiente para que su empresa también lo haga.

Para responder específicamente a su pregunta, debe evaluar cada una de esas tecnologías individualmente para ver si satisfacen sus necesidades. Le daré mi opinión, pero realmente necesita pasar al menos medio día para investigar y evaluar cada uno de ellos según se apliquen a sus necesidades comerciales específicas.

LINQ: Esto es algo que puede usar, incluso sin el marco de la entidad. LINQ es una tecnología utilizada para trabajar con colecciones de datos, y puede usarla en sus aplicaciones incluso si no la usa para cargar esos datos desde la base de datos. Hazte un favor y aprende a usar expresiones lambda y métodos de extensión LINQ. Le ahorrará tiempo, facilitará su vida como desarrollador y reducirá la cantidad de código que necesita escribir.

Entity Framework: este parece ser el futuro para el acceso a datos en el mundo de Microsoft. La mayoría de los nuevos marcos, tecnologías y herramientas de Microsoft están diseñados para funcionar con el marco de la entidad. No es perfecto, pero es mucho mejor que usar conjuntos de datos, especialmente si usas LINQ para entidades. Una razón comercial importante para usar el framework de entidades es que reduce la cantidad de código SQL que necesita escribir, ya que el framework lo generará por usted. En mi experiencia, la mayoría de los desarrolladores no son muy buenos para escribir SQL de todos modos (y la mayoría de las empresas no tienen un DBA dedicado), por lo que para la mayoría de las aplicaciones, el marco de la entidad debería hacer las cosas más rápidas y más eficientes. El marco de entidades también le permitirá trabajar con POCO que tienen menos gastos generales y son más fáciles de trabajar que los conjuntos de datos.

MVC: esta puede ser difícil de justificar, ya que la mayoría de las aplicaciones podrían no beneficiarse mucho de ella. Según los últimos anuncios de trabajo que he visto, MVC sigue siendo minoritario (aunque está ganando terreno rápidamente). Para la mayoría de las aplicaciones comerciales, MVC puede ser excesivo y bastará con arrastrar algunos controles a una página aspx. MVC tiene una curva de aprendizaje, y para ser productivo y aprovecharlo al máximo, realmente debe comprender HTTP, HTML, CSS y JavaScript. MVC funciona bien cuando necesita tener una aplicación web realmente personalizada donde el rendimiento es una gran prioridad. Si ese no es el caso, y los empleados no tienen mucha experiencia con él, probablemente no exista un caso comercial sólido para usarlo.

Servicios web de WCF: ¿tiene que proporcionar datos a las aplicaciones cliente remotas? WCF es probablemente el camino a seguir. ¿Está escribiendo una aplicación web que se ejecutará en el mismo servidor o red local que su base de datos? No use WCF, no lo necesita y solo servirá para complicar las cosas con abstracciones innecesarias.

En resumen, use una nueva tecnología cuando tenga sentido y tómese el tiempo para averiguar cuándo es eso. Toma mucho tiempo aprender nuevas tecnologías, pero no debería tomar mucho tiempo evaluarlas y saber si beneficiarán su situación específica. Esto es algo que los altos mandos de su empresa ya deberían estar haciendo, pero si no lo están, entonces debe hacerlo y luego tomarse el tiempo para educarlos sobre lo que ha aprendido.

EDITAR: Después de leer sus comentarios anteriores, tuve algunos pensamientos más. Puede ser útil si puede adoptar un enfoque ágil para desarrollar esta aplicación y dividirla en diferentes componentes que se pueden completar por completo antes de pasar a la siguiente. Es más probable que su gerente apruebe que se tome el tiempo extra para una nueva tecnología si puede ver que está progresando constantemente en el camino. Además, no tiene que elegir entre escribir toda la aplicación en MVC y Entity Framework o páginas y conjuntos de datos ASPX. Es posible usar ambos en la misma aplicación usando un enfoque híbrido. Podría comenzar usando MVC y el marco de la entidad para algunos de los componentes. Si las cosas van bien y tu jefe está feliz, entonces podrías continuar, pero si él siente que es así

Si bien definitivamente debería aprender algunas de las nuevas tecnologías de MS, mi experiencia reciente al aprender sobre cosas como WPF y WCF me ha hecho un poco más cauteloso sobre el aprendizaje de las API de MS más nuevas.

Ahora, LINQ es una gran ayuda para la productividad que definitivamente debería usar; Lo bueno es que puede introducir LINQ-to-objects por partes en todo tipo de situaciones aleatorias, con o sin la sintaxis de consulta real (comúnmente llamo Where()sin la from-selectsintaxis, ya que a menudo es más corta). El dual matemático de LINQ, Reactivo Extensiones, es algo que debe tener en cuenta, aunque todavía estoy luchando por encontrar un caso de uso realmente bueno. Del mismo modo, todas las características de C # 3/4/5 son útiles, por lo que debe estudiarlas y observar los lugares donde serán útiles, incluso si continúa utilizando las cosas "antiguas" de BCL.

Sin embargo, voy a tomar el abogado del diablo y sugerir que las nuevas bibliotecas de MS más nuevas, como WCF y WPF, no valen necesariamente la pena de aprender.

La razón principal es que son enormes y no están especialmente bien diseñados (el primero es un síntoma de este último). Recientemente escribí en un blog brevemente por qué WPF apesta . En cuanto a WCF, el documento técnicohace que parezca que interoperará fácilmente con "el servidor Java EE que se ejecuta en un sistema que no es Windows" y las "aplicaciones asociadas que se ejecutan en una variedad de plataformas", pero la verdad es que las API de WCF están muy específicamente orientadas a SOAP y tienen muy Soporte limitado para protocolos no SOAP. MS podría haber diseñado fácilmente un sistema general que permite protocolos conectables, y tal vez la capacidad está oculta (indocumentada) en algún lugar, pero por lo que puedo decir, eligieron diseñar un sistema mucho más limitado que solo puede hacer SOAP y HTTP limitado (siempre que su cuerpo de mensaje sea un objeto .NET serializado, IIRC). Investigué Entity Framework más brevemente, pero noté algunas quejas de que era incapaz de admitir algunos escenarios que el (mucho más simple) LINQ-to-SQL puede manejar de forma inmediata.

En mi opinión, el diseño de todas estas bibliotecas es fundamentalmente defectuoso porque usan muchos componentes que están estrechamente unidos entre sí, un gráfico de dependencia de las clases en cada marco probablemente sería enorme y se vería como un desorden desordenado de líneas garabateadas. E incluso si el diseño fuera bueno, no podríamos saberlo porque no hay documentos arquitectónicos públicos que profundicen en los detalles de nivel inferior, y los documentos de MSDN en su mayor parte no son muy buenos (tienden a obtener cada vez menos útil al mirar las clases de nivel inferior y inferior).

El gran tamaño de las bibliotecas también parece un defecto; He aprendido durante más de 20 años de programación que la simplicidad es una virtud, una que Microsoft nunca ha valorado.

Pero usted podría preguntar, "¿y qué"? Bueno, con bibliotecas tan grandes tal vez nunca sientas que realmente las entiendes. Eso significa que cuando desee hacer algo fuera de los casos de uso para los que Microsoft diseñó específicamente WCF / WPF / EF, no sabrá cómo, y es posible que nadie fuera de Redmond lo sepa. Y cuando algo sale mal, tendrá dificultades para descubrir qué salió mal. Y dentro de 15 años, cuando Microsoft haya pasado a su próxima API de próxima generación, nadie disfrutará de mantener el software creado sobre una base que es tan poco conocida.

Además, debido a la amplitud y complejidad de estas nuevas API, la alternativa multiplataforma a .NET, Mono, tiene poco soporte o no tiene soporte. Probablemente tenga pocas dificultades para usar sus tablas de datos escritos en Linux o Mac, pero ¿Entity Framework? Olvídalo. No me sorprendería si Mono nunca lo admite.

He usado LINQ-to-SQL en un nuevo proyecto y no está mal. De alguna manera, podría ser mejor, pero creo que la experiencia del desarrollador es sustancialmente mejor que ADO.NET. Una limitación importante: L2S es mucho más fácil si modifica las tablas en modo "conectado", a diferencia del antiguo ADO.NET que fue diseñado específicamente para funcionar sin una conexión activa de la base de datos. De todos modos, dado que LINQ-to-SQL es (según la gente de Mono) un cuarto del tamaño de Entity Framework, es una pena que MS haya decidido dejar de trabajar en él.

He desarrollado software basado en Microsoft Windows durante más de diez años antes de cambiarme completamente a software libre y de código abierto y abandonar el desarrollo de MS. Estoy escribiendo esto desde una larga experiencia personal.

Además de otras razones por las cuales cambié a FOSS, la razón relacionada con la programación es que casi nunca hay justificación para aprender / implementar tecnologías patentadas. El quid de la cuestión es que Microsoft no se compromete a respaldar todas y cada una de las tecnologías que ha distribuido. Con demasiada frecuencia, MS introduce cambios obsoletos en sus API y marcos. Esto hace que gran parte de las API existentes, así como su conocimiento, sean obsoletos. De hecho, incluso hacen esto con su software de usuario final. Por ejemplo, MS Office 2007/2010 no es similar a MS Office 2003 y, lo que es más importante, Windows 8 es una desviación radical de las plataformas existentes. En particular, es probable que haya todas las API y marcos nuevos para Windows 8, y no podrá admitir Windows 8 (en el futuro, si no ahora) sin implementarlos.sin soporte , es una de las principales razones comerciales para continuar implementando cualquier tecnología nueva que MS lance. Si MS deja de admitir la tecnología anterior mañana, ¿a dónde vas con el código heredado? ¿Dónde obtienes actualizaciones para ello?

Tenga en cuenta también que no le pido que abandone el desarrollo de MS y cambie a FOSS. Solo quería ayudarlo aquí, ya que tenía una larga experiencia en tecnología MS.

Creo que lo principal es descubrir cuáles son los beneficios concretos de adoptar una tecnología más nueva y presentarlos como justificación para hacerlo, en lugar de su propio deseo de no quedar obsoleto. Dices que no tienes "razones comerciales", pero seguramente puedes encontrar algunas con la investigación ...

Tal vez pasar a un marco / tecnología más nuevo le permite diseñar aplicaciones que se ejecuten con una huella de memoria más pequeña, sean más receptivas, sean más rápidas de implementar, etc. Esas serían razones comerciales concretas. Entonces, supongo que sugeriría retroceder un poco e investigar "¿por qué la gente comenzó a usar MVC, LINQ, Entity Framework, WCF Web Services, etc. en primer lugar?" Responda esa pregunta y probablemente encontrará alguna justificación comercial para ofrecer. Si es suficiente o no abandonar la filosofía de "ir con lo que funciona" es otro asunto y puede ser una función de su capacidad de ventas.

Lo que uso actualmente funciona bien y mi tiempo de desarrollo es rápido

Desafortunadamente, Microsoft no le importa nada, lo que les importa es venderle más herramientas. ¡Eso significa crear nuevas tecnologías, lo que significa que también debes comprar más capacitación! Ganar-ganar, para ellos.

Para usted, significa una batalla constante para aprender cosas nuevas, y una vez que haya comenzado a ser bueno en ellas y su productividad de desarrollo sea tan rápida como solía ser ... hay algo más que aprender y debe comenzar. todo de nuevo. Hay una razón por la cual el software generalmente es de baja calidad, porque no se trata como los servicios 'profesionales' como ingeniería o arquitectura, mantienen las cosas que funcionan. Los tiramos y comenzamos desde cero todo el tiempo.

Pero este pobre estado del mundo no te ayuda. Así que mi consejo es usar una combinación de "mantenerse al día con la tecnología" y "no quiero quedarse atrás". Su jefe debería preocuparse por el reclutamiento, si solo hizo el desarrollo de VB6, entonces le resultará bastante difícil reclutar personal nuevo (bueno, en realidad probablemente lo encuentre realmente fácil, todos los chicos a quienes les gustó VB6 se reunirán con usted, Pero ese es otro asunto).

Diría que debe verificar si la nueva tecnología x lo ayudaría a realizar un desarrollo futuro aún más rápido; luego deja de ser una tarea personal o simplemente un desperdicio, y se convierte en una tarea de mejora comercial, las empresas siempre están hablando sobre cómo la I + D " la innovación "les ayuda a mantenerse competitivos.

Como desarrollador, debe impulsar la administración para usar tecnologías más nuevas y justificarlo demostrando los beneficios y el valor que aportará a la empresa (por ejemplo, rendimiento, características, facilidad de uso, mantenimiento). La administración generalmente es reacia al cambio y no justificará cambiar nada a menos que traiga algunos beneficios adicionales sobre lo que está actualmente en uso.

El uso de una nueva tecnología "de vanguardia" también es bueno para el equipo de marketing para que puedan comercializar a la empresa como líder de las tendencias tecnológicas actuales y no estancada en el pasado utilizando tecnologías y plataformas heredadas.

Tendrá que hacer algunos proyectos más pequeños en su tiempo libre si su empresa no le permite aprender sobre los suyos. El aprendizaje que hagas en tu tiempo privado debería darte un argumento comercial para hacerle a tu jefe sobre las mejoras en las tecnologías más nuevas. Si actualmente te sientes demasiado agotado por tu trabajo diario para aprender cosas nuevas, es posible que debas tomarte unas semanas de descanso, descansar unos días y luego hacer una sesión de entrenamiento intensiva por ti mismo.

Digan lo que quieran acerca de Microsoft , una cosa que no les puede fallar es que las herramientas y la capacitación para desarrolladores estén disponibles sin costo alguno . Instale el último instalador de Microsoft Web Platform en su PC, luego enciéndalo y espere a ver todas las herramientas y plataformas de desarrollo gratuitas que puede probar. Visite los sitios web de MSDN , ASP.Net y Channel9 y consulte sus tutoriales.

Todavía puedo desarrollar ASP Classic si puedes creerlo, pero con algunas horas de persuasión he convencido a mi jefe de que .Net es el camino a seguir, haciendo un caso de negocios para ello. El año que viene comenzaremos la transición de nuestro código heredado.

La mejor manera de justificar el uso de nuevas tecnologías es cuando puede demostrar que mejoran la productividad del desarrollador. Esto significa más trabajo realizado a un costo menor. Eso es lo único que importa desde una perspectiva empresarial.

Algunos ejemplos:

1. Herramientas que facilitan el trabajo del desarrollador
2. Bibliotecas que proporcionan características que de otro modo tendrían que desarrollarse internamente
3. Lenguajes más potentes que pueden dar como resultado un código que es más fácil de leer o menos líneas de código que deben escribirse / depurarse