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

Una gran cantidad de trabajo de software es mantenimiento. Ningún gerente de contratación realmente 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 logran hacer "nuevo y creativo", lo hacen mal, por lo que es difícil mantener el sistema (esto es especialmente probable si nunca lo han hecho. Hicieron el mantenimiento por sí mismos (nadie que haya trabajado constantemente en pequeños proyectos greenfield puede realmente afirmar ser competente).

Otra razón (probablemente mayor) 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 se haya redefinido). Sobrevivieron a un entorno empresarial cambiante. Probablemente sobrevivieron a cerca de diez propuestas de programadores jóvenes ingenuos para reescribir todo en Java o lo que fuera que estaba de moda en ese momento. Tuvieron la suerte de que cualquier departamento, compañía o agencia que atendiera el software sobrevivió a los diversos recortes presupuestarios, reorganizaciones, fusiones, etc.

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

Entonces, en lugar de lamentarse por esto, es 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 se usa a menudo para proyectos nuevos que no dependen de desarrollos más antiguos es proyecto greenfield . Ocasionalmente, puede ver el término en las listas de trabajos; 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 que construyendo como proyectos nuevos, por lo que no es sorprendente que no puedas hacer muchas cosas completamente "nuevas".

Además, crear algo completamente nuevo es un lote de trabajo. Incluso en un proyecto greenfield, probablemente elegirás una serie de herramientas para ayudarte: plataforma, compilador, marcos, bibliotecas, etc. Tan pronto como tomes esas decisiones, has impuesto ciertas restricciones a tu proyecto. Eso no quiere decir que ya no esté haciendo un nuevo trabajo, solo que "nuevo" es un término relativo aquí. No es un gran paso desde allí ver cómo agregar una característica o módulo a un proyecto existente como "nuevo", aunque no lo llamaría un proyecto greenfield.

Depende del trabajo que busques.

Solo una vez he trabajado para una empresa de productos de software puro en la que trabajé en su única aplicación chapada en oro en un pequeño equipo de puesta en marcha.

De lo contrario, he trabajado para compañías de tecnología que necesitaban software para respaldar sus productos internos y de I + D + i.

La ventaja es que puedo crear productos completos de principio a fin y prácticamente construir lo que quiero. En ocasiones, también puede probar tecnologías más nuevas que si estuviera atascado al agregar funciones a una aplicación líder existente en el mercado.

El inconveniente 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 un negocio central "= ¡es increíble cómo las compañías creen que pueden vender una máquina-herramienta de $ 100 K sin software para operarla!

En lugar de ver el código heredado como una limpieza continua del desorden de otra persona, considérelo como una oportunidad para trabajar en muchos proyectos nuevos.

Piénsalo, cada nueva característica agregada a un sistema es un pequeño proyecto dentro de sí mismo. Aún debe aplicar todo el SDLC para asegurarse de haber completado el trabajo correctamente. Claro, es probable que te den una especificación para la función, pero por lo general se deja de lado el detalle, así que depende de ti analizar el problema como se muestra, diseñar el mejor método para aplicar el cambio, probarlo, codificarlo, y luego devuélvalo a su sistema de control de versiones y, posiblemente, manténgalo en el futuro.

Según mi experiencia, no es frecuente que trabaje en un campo completamente verde y, cuando ha tenido la suerte de hacerlo, se espera que vea el proyecto a través de una buena parte de su mantenimiento y tal vez incluso durante 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 usted se convierte en un repositorio de conocimientos, y puede parecerle costoso cambiarlo a otras cosas. Cuando comienza con un producto existente, es porque el empleador perdió recientemente un recurso o necesita más recursos en el proyecto, y su negocio necesita asegurarse de que no suponga una pérdida demasiado grande para la inversión que ha hecho en su software. . Esa es la realidad de ser un ingeniero de software.

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

Es asombroso cómo un poco de calistenia mental puede cambiar totalmente tu percepción y 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 para su producto principal. Sospecho que algunos de los desarrolladores que hicieron este trabajo estaban allí cuando se escribió la primera línea de código para VMWare. Construyeron su actualización principal en el código escrito por personas que desde hace mucho tiempo siguieron adelante.

En la Workplace Beta hay una pregunta sobre cómo Google 20 % sistema de proyecto personal funciona .

Estoy seguro de que Google descubrió que los mejores desarrolladores desean estar presentes en la creación de nuevos productos de software y que, en algún momento, se cansarán de agregar pequeñas funciones y ajustar los gui para el próximo lanzamiento de puntos.

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

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

Otros están llamando a ese mantenimiento, pero ese es un término horrible. Es un rediseño y una refactorización o recodificación del software para que se ajuste a una nueva idea de lo que debería hacer el programa.

Diría que depende de la compañía para la que trabajas.

Mi primer trabajo fue una empresa de software de contabilidad cuyo producto principal era un sistema ERP, compitiendo casi al mismo nivel que Great Plains o Peachtree (como lo hizo en QuickBooks, o de costado cuando se cansó de los GP ofuscados esquema o lo que sea que usted pensaba que estaba mal con PT, luego se mudó del nivel a un paquete como SAP). Ese trabajo fue de 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. Abandoné la empresa cuando el CEO quería hacer una reescritura del sistema de una 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, dando al cliente un VS Designer simplificado, y personalizando las reglas de negocios al proporcionar un lenguaje de expresión).

Mi siguiente trabajo después de eso fue una firma de contratos que hizo "desarrollo llave en mano"; el sistema que el cliente especificó se construyó desde cero, hardware y software, luego, al finalizar el proyecto, todo se entregó al cliente, que podía mantenerlo por sí mismo o retener los servicios de la empresa por una tarifa mensual. Mi trabajo estaba en el desarrollo de uno de estos grandes proyectos, y mientras trabajaba allí, casi todo lo que había hecho no existía antes de comenzar. Incluso entonces, el desarrollo es inherentemente iterativo; siempre estás agregando a lo que ya tienes (incluso si lo que tienes no es nada), y tienes que evitar y solucionar los problemas de regresión (nuevas cosas que rompen cosas viejas). Y una vez que el proyecto pasó al estado de "garantía", se completó la nueva funcionalidad y se esperaba que reparáramos cualquier defecto que el cliente haya encontrado durante sus UAT.

Mi trabajo actual está de vuelta al desarrollo interno, para una compañía de seguridad que usa monitoreo de video y retroalimentación de audio para proporcionar verificación de señales de alarma y otros servicios de "guardia virtual". Este campo está creciendo rápidamente y sigue desarrollándose; Los equipos nuevos ingresan al mercado todo el tiempo, se registran nuevos clientes que quieren que hagamos cosas nuevas y los productos existentes ya no cumplen con las normativas gubernamentales y de UL. El 99% de este trabajo es "integración"; escribiendo 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.

Diría que depende mucho de la naturaleza de tu rol.

Soy parte de un equipo pequeño 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 la asistencia técnica después de que haya liberado 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 su puesto de trabajo: ;-)

   Si trabaja para una nueva compañía que desarrolla productos nuevos con un alto riesgo de que la compañía sobreviva, es probable que cree algunos nuevos productos excelentes.

   Si trabaja para una compañía 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 tentadora . La verdad es que es difícil hacer esto de manera correcta . Hacer un código mantenible no es una tarea trivial.

   Si piensa en estos muchos 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 que ayude incluso a personas desconocidas a participar en su proyecto, documentación, pruebas automáticas y pruebas. desarrollos impulsados.

No hay mucha gente que lo esté 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 usted realiza principalmente el 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 es porque busco trabajos que me permiten hacer nuevos desarrollos. No soy un contratista, y en general no hago desarrollo web. Casi siempre he trabajado para pequeños empleadores, y normalmente trabajo en áreas específicas (desarrollo de GUI de escritorio, herramientas de control de calidad, herramientas de desarrollador, mercados verticales).

También he visto y experimentado de primera mano que los mejores programadores en 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 cómo se desarrolla un nuevo desarrollo.

El desarrollo del mantenimiento es una tarea difícil, más difícil en muchos aspectos que el desarrollo nuevo. En mi experiencia, a los empleadores les gusta mantener a un desarrollador haciendo el 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 de mantenimiento, y un equipo de proyecto, que era todo un desarrollo nuevo. Hubo grandes desarrolladores en ambos lados, pero los tipos de mantenimiento eran definitivamente más especializados y usaban tecnología heredada.

¿Puedo hacer una sugerencia para que rechace y solicite un nuevo trabajo de desarrollo? Y si su empleador solo hace el mantenimiento, entonces tal vez necesita seguir adelante.

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

Los cuatro años que he trabajado en mi empresa, diría que el 70-80% de mi tiempo lo dedico a crear 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 lo que sé es cómo funciona mi empresa. No todos los integrantes de mi equipo de desarrollo dedican tanto tiempo a crear nuevas funciones. Hay un número que enfoca su tiempo en nada más que en solucionar problemas / cazar. Si se trata de una nueva funcionalidad o si necesitan ayuda, entonces me encargan que la investigue. Sin embargo, en general, ese pequeño equipo de cazadores de errores es lo que permite que un grupo más grande de desarrolladores presione sin interrupción.

Llevo casi tres años trabajando como el único desarrollador en una compañía que usó QuickBooks y Excel y nada más cuando empecé. Ahora tenemos una aplicación Windows Forms , una aplicación SharePoint , SQL Server + Reports, un complemento de Excel y un complemento de Outlook.

Sólo hoy , configuré por primera vez un sistema de emisión de boletos porque perdí la capacidad de administrar las solicitudes de correo electrónico a una tasa que evitó que los usuarios se quejaran, así que veo que esto es una señal de que ' Ingresé al modo de mantenimiento.

Mis trabajos anteriores han sido más parecidos a los que otros han publicado, pero pensé que iba a ofrecer 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 cierre de software después de varios años, tal vez porque el lenguaje de desarrollo en el que estaba escrito ya no se usa (¿Delphi alguien?), o la plataforma está siendo reemplazada ( Windows XP), o requisitos reglamentarios lo exigen. P.ej. Los programas de dos niveles que hablan directamente a una base de datos ahora se están retirando en favor de tres niveles que usan conexiones Kerberizadas 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 más modernas.

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 tecnología antigua y sea reemplazado por algo más nuevo.