¿Es la creación de software nuevo generalmente una parte importante de la mayoría de los trabajos de programación? [cerrado]

He trabajado en el desarrollo de software durante más de 10 años y me doy cuenta de que rara vez puedo crear algo "nuevo". Me doy cuenta de que "nuevo" es un término vago, pero lo definiría como cualquier cosa, desde un nuevo proyecto obvio a gran escala hasta una nueva característica grande en un proyecto existente (digamos algo que requeriría un poco de reflexión en su diseño, y eso podría tomar 2 semanas o más para completar). Tal vez una pauta aproximada es algo nuevo si requiere una especificación escrita. Creo que la mayoría de los programadores saben de lo que estoy hablando: estás en la zona, escribiendo un montón de código a un ritmo rápido.

De todos modos, pensando en lo que he hecho, estimaría que menos del 10% de mi tiempo lo paso en "nuevo" trabajo. Hay cosas como "adaptar este sistema existente para que funcione en este nuevo entorno", que ciertamente requiere mucha planificación, pero la codificación real y las "nuevas cosas" se reducen a hacer pequeños cambios en muchos lugares a lo largo del código. Del mismo modo para solicitudes de funciones pequeñas: si sé qué hacer, a menudo se pueden completar en menos de una hora, y si no lo hago, es solo una gran cantidad de código de lectura y averiguar qué hacer (lo que me frustra porque aprendo mucho mejor haciendo, no leyendo).

En general, siento que realmente no estoy creando nada la mayor parte del tiempo. Asumí que este era el caso en la mayoría de los lugares: un nuevo producto saldría bastante rápido y en ese momento todos estarían entusiasmados y descifrarían el código a un ritmo rápido, pero luego, una vez en vivo, pasa al modo de mantenimiento, donde Algunos de los cambios posteriores se considerarían "nuevos y creativos".

¿Me equivoco? ¿Estoy describiendo con precisión la mayoría de los trabajos de programación o la mayoría de los programadores sienten que a menudo crean cosas nuevas?

Una gran cantidad de trabajo de software es el mantenimiento. Ningún gerente de contratación le dirá esto, por supuesto, pero ciertamente es el caso.

Sí, tu percepción es precisa. Es una verdad absoluta que se gasta mucho más tiempo, dinero y esfuerzo en mantener los sistemas que en crear nuevos sistemas. Obviamente, la asignación de tiempo de la mayoría de los programadores reflejará eso.

Parte de la razón de esto es que muchas personas, cuando llegan a hacer "nuevas y creativas", lo hacen mal, por lo que mantener el sistema es difícil (esto es especialmente probable si nunca han realizado el mantenimiento ellos mismos) nadie que haya trabajado constantemente en pequeños proyectos greenfield puede realmente afirmar ser competente).

Otra razón (probablemente más grande) es que la mayoría de los sistemas están diseñados para ser continuamente útiles, no solo para un evento único. Por lo tanto, se siguen acostumbrando durante mucho más tiempo del necesario para desarrollarlos. Pero durante ese tiempo, los requisitos cambian (y se agregan) debido a cambios en la legislación, en el mercado, en la investigación, en los usuarios, lo que sea. Y eso significa trabajo de mantenimiento.

Los sistemas heredados son los exitosos. Sobrevivieron al proceso de desarrollo inicial donde el 50% de los proyectos fracasan (¡incluso después de que el éxito ha sido redefinido!). Sobrevivieron a un entorno empresarial cambiante. Probablemente sobrevivieron a unas diez propuestas de jóvenes programadores ingenuos para reescribir todo en Java o lo que estaba de moda en ese momento. Tuvieron la suerte de que cualquier departamento, empresa o agencia a la que sirviera el software sobreviviera a los diversos recortes presupuestarios, reorganizaciones, fusiones, etc.

Probablemente menos del 5% del software escrito seguirá ejecutándose diez años después.

Por lo tanto, en lugar de gemir por esto, verlo como un privilegio trabajar en una historia de éxito tan darwiniana y una oportunidad para aprender qué funciona en el mundo real y por qué.

El término que a menudo se usa para nuevos proyectos que no dependen del desarrollo anterior es proyecto greenfield . De vez en cuando puede ver el término en las listas de trabajo: saber que puede comenzar desde cero en lugar de heredar el esfuerzo fallido de otra persona puede hacer que un trabajo sea más atractivo.

Los proyectos de software exitosos generalmente pasan mucho más tiempo manteniéndose de lo que se construyen como proyectos nuevos, por lo que no es sorprendente que no puedas hacer muchas cosas completamente "nuevas".

Además, crear algo completamente nuevo es mucho trabajo. Incluso en un proyecto greenfield, probablemente elija una serie de herramientas para ayudarlo: plataforma, compilador, marcos, bibliotecas, etc. Tan pronto como tome esas decisiones, ha impuesto ciertas restricciones en su proyecto. Eso no quiere decir que ya no estás haciendo un nuevo trabajo, solo que "nuevo" es un término relativo aquí. No es un gran paso a partir de ahí ver agregar una característica o módulo a un proyecto existente como "nuevo" a pesar de que no lo llamaría un proyecto greenfield.

Depende del trabajo que busques.

Solo una vez trabajé para una compañía de productos de software puro donde trabajé en su única aplicación chapada en oro en un pequeño equipo de inicio.

De lo contrario, he trabajado para empresas de tecnología que necesitaban software para respaldar sus productos internos de I + D o externos.

Lo bueno es que puedo construir productos completos de inicio a fin y prácticamente construir lo que quiero. A veces también puede probar tecnologías más nuevas que si estuviera atascado agregando características a una aplicación existente líder en el mercado.

La desventaja es que usted es parte del costo, no parte del producto. Así que he tenido proyectos enlatados porque 'no estamos haciendo software "/" el software no es el negocio principal "= ¡es sorprendente cómo las empresas piensan que pueden vender una máquina herramienta de $ 100 K sin software para operarla!

En lugar de ver el código heredado como limpiar continuamente el desorden de otra persona, míralo como una oportunidad para trabajar en muchos proyectos nuevos.

Piénselo, cada nueva característica agregada a un sistema es un pequeño proyecto en sí mismo. Aún debe aplicar todo el SDLC para asegurarse de haber completado el trabajo correctamente. Claro, es probable que le den una especificación para la función, pero generalmente se han dejado los detalles finos, por lo que depende de usted analizar el problema como se muestra, diseñar el mejor método para aplicar el cambio, probarlo, codificarlo, y luego vuelva a lanzarlo a su sistema de control de versiones, y posiblemente lo mantenga en el futuro.

Según mi experiencia, no siempre trabajas en un campo completamente verde, y a menudo, cuando tienes la suerte de hacerlo, se espera que veas el proyecto a través de una buena parte de su mantenimiento y tal vez incluso para la vida útil del producto, o durante todo el tiempo que esté con un empleador determinado. Esto se debe a que su experiencia íntima con un producto significa que se convierte en un depósito de conocimiento y puede verse como costoso trasladarlo a otras cosas. Cuando comienza con un producto existente, es porque el empleador ha perdido un recurso recientemente o necesita más recursos en el proyecto, y su negocio necesita asegurarse de que no se pierda demasiado la inversión que ha realizado en su software. . Esa es la realidad de ser ingeniero de software.

He trabajado en TI durante casi 22 años con los últimos 15 como desarrollador de software, y en todo ese tiempo solo he creado alrededor de 5 productos nuevos, y la mayoría de mi tiempo mantenía esos productos a largo plazo o mantenía el de otra persona. producto. Cada uno me ha dado desafíos y problemas que resolver, y cada uno de ellos ha sido tratado no solo como un gran proyecto del que soy parte, sino también como una ENORME serie de microproyectos para completar.

Es sorprendente cómo un poco de calistenia mental puede cambiar totalmente tu percepción y el disfrute del trabajo diario que haces. ;-)

Creo que muchos trabajos de desarrollo de software implican mejorar un producto existente o adaptar el código existente a un nuevo cliente o mercado.

Esto no es realmente 'mantenimiento'. Por ejemplo, VMWare acaba de lanzar la versión 8, es una actualización importante de su producto principal. Sospecho que pocos de los desarrolladores que hicieron este trabajo estaban allí cuando se escribió la primera línea de código para VMWare. Desarrollaron su actualización principal en el código escrito por tipos que hace mucho tiempo se mudaron.

En la versión beta de Workplace hay una pregunta sobre cómo funciona el sistema de proyectos personales del 20% de Google .

Estoy seguro de que Google descubrió que los mejores desarrolladores quieren estar allí en la creación de nuevos productos de software y, finalmente, se cansarán de años de agregar pequeñas funciones y ajustar la GUI para el próximo lanzamiento.

Al tener el 20% de proyectos, especulo que al desarrollador de Google no le importará quedarse para mejorar los proyectos de Google, ya que todavía puede divertirse al estar allí al comienzo de algo nuevo.

Pasará su tiempo creando nuevas funciones y cambiando la funcionalidad del código existente para cumplir con la nueva especificación.

Otros lo llaman mantenimiento, pero ese es un término horrible. Es un rediseño y una refactorización o una nueva codificación del software para que se ajuste a una nueva idea de lo que debe hacer el programa.

Yo diría que depende de la empresa para la que trabajas.

Mi primer trabajo fue una empresa de software de contabilidad cuyo producto principal era un sistema ERP, que competía aproximadamente al mismo nivel que Great Plains o Peachtree (como cuando te mudaste de QuickBooks, o de lado cuando te cansaste del esquema ofuscado de GP o lo que sea creías que estaba mal con PT, luego subiste completamente del nivel a un paquete como SAP). Ese trabajo consistía en un 99.99% de mantenimiento, definido como corregir errores y agregar "cosas pequeñas", sin cambiar fundamentalmente la forma en que funcionaba el software o lo que podía hacer. Dejé la compañía cuando el CEO quería hacer una reescritura del sistema desde la primera página, lo que hubiera sido genial, excepto que insistió en varias características de diseño que son antipatrones claros, como la plataforma interna (que permite un alto grado de personalización del programa, básicamente, dándole al cliente un tonto VS Designer,

Mi siguiente trabajo después de eso fue una firma de contrato que hizo "desarrollo llave en mano"; el sistema que especificó el cliente se construyó desde cero, hardware y software, luego, al finalizar el proyecto, todo se entregó al cliente que podía mantenerlo o retener los servicios de la compañía por una tarifa mensual. Mi trabajo consistía en desarrollar uno de estos grandes proyectos, y mientras trabajaba allí, casi todo lo que había hecho no había existido antes de comenzar. Incluso entonces, el desarrollo es inherentemente iterativo; siempre está agregando a lo que ya tiene (incluso si lo que tiene no es nada), y debe evitar y solucionar problemas de regresión (cosas nuevas que rompen cosas viejas). Y una vez que el proyecto pasó al estado de "garantía",

Mi trabajo actual es volver al desarrollo interno, para una compañía de seguridad que utiliza monitoreo de video y retroalimentación de audio para proporcionar verificación de señal de alarma y otros servicios de "guardia virtual". Este campo está creciendo rápidamente y aún en desarrollo; nuevos equipos ingresan al mercado todo el tiempo, se inscriben nuevos clientes que desean que hagamos cosas nuevas y los productos existentes ya no cumplen con la adaptación de UL y las normas gubernamentales. El 99% de este trabajo es "integración"; escribir un software nuevo que nunca existió antes, para hacer que un equipo o software nuevo pero preexistente funcione con otro equipo o software preexistente, probablemente más antiguo, para que podamos hacer cosas nuevas con ambos.

Yo diría que depende mucho de la naturaleza de tu rol.

Soy parte de un pequeño equipo y, como tal, tengo que mantener y apoyar todo lo que creo.

Hace 5 años, la mayor parte de lo que hice fue "nuevo"; ahora diría que el mantenimiento del código existente ocupa al menos la mitad de mi tiempo, y un 25% adicional son versiones "nuevas" de los sistemas existentes.

Pero si trabajó únicamente como desarrollador con un equipo para asumir el mantenimiento y el soporte después de lanzar su código, técnicamente todo sería "nuevo". Si puede encontrar un trabajo donde no sea necesario mantener su propio código, ¡tómelo!

1. Depende de cuán peligroso sea tu puesto de trabajo: ;-)

   Si trabaja para una nueva empresa que desarrolla nuevos productos con un alto riesgo de que la empresa sobreviva, probablemente cree algunos nuevos productos excelentes.

   Si trabaja para una empresa antigua que tiene una posición estable en el mercado, es más probable que codifique en modo de mantenimiento ;-).

2. La creación de un nuevo software siempre es muy tentador . La verdad es que es difícil hacer esto de la manera correcta . Hacer código mantenible no es una tarea trivial.

   Si piensa en estas toneladas de aspectos, debe asegurarse de escribir un buen código: registro adecuado, monitoreo adecuado y adquisición de estadísticas, diseño descriptivo que sea eficiente y ayude incluso a personas desconocidas a involucrarse en su proyecto, documentación, pruebas automáticas y desarrollos basados ​​en pruebas.

No muchas personas lo están haciendo bien, por lo que debemos mantener su código y pulirlo al estado adecuado. ;-)

La buena noticia es que si está en la empresa el tiempo suficiente, puede influir en cómo se escribe el nuevo código :-)

Si realiza principalmente mantenimiento o no, está al menos parcialmente bajo su control. En mi caso, la mayor parte de mi trabajo durante los últimos 15 años ha sido un nuevo desarrollo. Esto se debe a que busco trabajos que me permitan realizar nuevos desarrollos. No soy un contratista, y generalmente no hago desarrollo web. Casi siempre he trabajado para pequeños empleadores, y generalmente trabajo en áreas específicas (desarrollo de GUI de escritorio, herramientas de control de calidad, herramientas de desarrollo, mercados verticales).

También he visto y experimentado de primera mano que los mejores programadores de un equipo generalmente (aunque no siempre) obtienen los mejores trabajos. Por lo tanto, concéntrese en ser el mejor programador de su empresa y comenzará a ver nuevos desarrollos en su camino.

El desarrollo de mantenimiento es una tarea difícil, más difícil en muchos aspectos que el nuevo desarrollo. En mi experiencia, a los empleadores les gusta mantener a un desarrollador haciendo mantenimiento, especialmente si son buenos en eso. Encontrar buenos desarrolladores de mantenimiento en tecnologías heredadas es más difícil que encontrar a alguien que pueda trabajar con la última tecnología.

He trabajado en una empresa que estaba dividida en un equipo de producto, que era todo mantenimiento, y un equipo de proyecto, que era todo un desarrollo nuevo. Hubo grandes desarrolladores en ambos lados, pero los técnicos de mantenimiento definitivamente fueron más especializados y utilizaron tecnología heredada.

¿Puedo hacer una sugerencia para que retrocedas y pidas un nuevo trabajo de desarrollo? Y si su empleador solo realiza tareas de mantenimiento, ¿tal vez necesite continuar?

Yo diría que depende de muchos factores. Dónde trabaja, qué tipo de productos fabrica, cómo está organizado su equipo, etc.

Durante los cuatro años que he trabajado en mi empresa, diría que el 70-80% de mi tiempo lo paso creando algo nuevo. Probablemente el 50-60% de eso se gasta en proyectos grandes que es un código completamente nuevo, mientras que el resto de ese tiempo se gasta en mejoras a la funcionalidad actual.

Parte de eso lo sé es cómo funciona mi empresa. No todos en mi equipo de desarrollo pasan tanto tiempo construyendo nuevas funcionalidades. Hay un número que enfoca su tiempo en nada más que la corrección de errores / caza. Si se trata de una funcionalidad completamente nueva o si necesitan ayuda, entonces me patean para investigar. Sin embargo, en general, ese pequeño equipo de cazadores de errores es lo que permite que el grupo más grande de desarrolladores continúe presionando sin interrupción.

He trabajado casi tres años como el único desarrollador en una empresa que usó QuickBooks y Excel y nada más cuando comencé. Ahora tenemos una aplicación de formularios Windows Forms , una configuración de SharePoint , SQL Server + Reports, un complemento de Excel y un complemento de Outlook.

Justo hoy , configuré por primera vez un sistema de tickets porque perdí la capacidad de administrar las solicitudes de correo electrónico a un ritmo que evitó que los usuarios se quejaran, así que veo que esto es una señal de que he entrado en modo de mantenimiento.

Mis trabajos anteriores han sido más parecidos a lo que los otros han publicado, pero pensé que agregaría mi experiencia atípica solo porque demuestra que nunca se sabe lo que traerá el próximo trabajo. Estoy agotado, pero la cantidad que he aprendido en este trabajo ha valido la pena.

Algunas organizaciones más grandes como la Compañía para la que trabajo tienen una política de desmantelamiento de software después de varios años, tal vez porque el lenguaje de desarrollo en el que fue escrito ya no se usa (¿Delphi alguien?), O la plataforma está siendo reemplazada (Windows XP) , o los requisitos reglamentarios lo exigen. Por ejemplo, los programas de dos niveles que se comunican directamente con una base de datos ahora se están retirando del servicio a favor de tres niveles que usan conexiones Kerberized para mayor seguridad.

Los usuarios aún necesitan esa funcionalidad original, por lo que se desarrolla una versión completamente nueva que utiliza las técnicas actuales más avanzadas.

Espere un ciclo de reemplazo de 5-7 años para este tipo de cosas. Por ejemplo, para 2020, espero que el software WPF (Cliente) / Java (servidor) que estoy escribiendo ahora sea una tecnología vieja y sea reemplazado por algo más nuevo.