Buenas!

Armo este thread para consultarles más que nada a los que tengan varios años en la industria de desarrollo de software y hayan pasado por varias empresas.

Resulta que hablando con mi jefe, le plantee que no me sentía cómodo con uno de los proyectos en los que estoy participando. Básicamente el proyecto (del cual me estaría ocupando yo solo en principio) se trata de arreglar unos bugs de un sistema ya desarrollado (por una persona externa a la empresa) del cual no tengo idea.

Lo que él me plantea ante mi descontento es que en la industria del desarrollo uno se va a topar con un gran porcentaje de proyectos que consistan en arreglar lo que otro hizo mal, y sobre sistemas en los que no hay documentación y nadie tiene idea de nada.

Mi consulta es básicamente la opinión que puedan tener al respecto. Si esto es cierto y las empresas por motivos económicos se ven obligadas a tomar este tipo de proyectos que pueden llegar a ser un dolor de huevos, o si hay empresas que trabajan sólo con proyectos desarrollados desde cero y evitan tener que lidiar con este tipo de proyectos.

Él me lo planteó como que esto es una constante de la industria de sistemas, pero creo que debe haber empresas en las que no ocurra.

Cualquier opinión es bienvenida, saludos!

Esto es una constante en la industria.
Aun los desarrollos hehcos desde 0 tienen que mantenerse en el tiempo, y como la gente rota, vas a seguir tocando codigo horrible de otra gente

Y nada "empieza de cero", siempre tenes frameworks o herramientas con sus bugs y limitaciones. Es muy meta esto. Usamos software para hacer software.

---

Y no siempre es arreglar lo que otro "hizo mal". Los requerimientos cambian y hay que cambiar el software.

---

No es "por motivos económicos", mantener legacy systems lo hace desde Google hasta el Santander Río.

Es como dicen ellos, es raro que te topes con algo que se conciba de cero (en mi caso por suerte en uno de los laburos decidieron volar el proyecto base que se usaba y estuve en el momento en el que se armó uno nuevo) pero tambien pasé por proyectos más de mantenimiento. Generalmente suelen surgir nuevos requerimientos, y ahi es cuando deja de ser un poco embole todo (al menos en mi caso, el tema es que después vienen las regresiones y si no automatizás te da angustia).

A veces, dependiendo del lugar, ponen a los más nuevos en proyectos “para corregir bugs“ y al que tiene un poco más de cancha, lo meten en nuevos requerimientos.

Eso.


Es cierto que hay matices dentro de esto (entre estar en una consultora que se dedica a parchar horriblemente código que desarrollaron hace 15 años escrito con los codos y estar en una empresa que tiene un producto propio al que hay que ir manteniendo y actualizando el código de cuando la empresa arrancó que tal vez no es tan bonito hay una diferencia enorme).

Pero sí, es cierto que el mantenimiento es un gran porcentaje del laburo. Mantener, desarrollar features nuevos integrados con lo que ya está, y refactorear un poco para que integrar los features nuevos no sea tan desastroso.


Supongo que la mejor forma de desarrollar un producto desde cero es poner tu propia empresa para desarrollar tu propio producto

Supongo que es lo que todos quisiéramos hacer, pero andá a tener una idea que valga la pena...

bienvenido a la industria del mantenimiento

---

es una mierda, pero si, los sistemas tienen que mantenerse

a lo sumo te tocara migrarlos, pero siempre de alguna u otra manera te pueden caer codigos externos

Entrar en nuevos requerimientos es tambien laburar sobre lo que ya esta. Si pones tu propia empresa y te va bien en 2 años estas en la misma.

Mantener algo que hiciste vos es un caso super ideal. No es algo que se de todos los dias.
Como dicen arriba, algunas empresas la tienen lo suficientemente "grande" como para decir "no, este proyecto de mantener este muerto yo no lo hago. Suelen ser mas bien empresas chicas que tienen bastante laburo y pueden darse ese lujo (todavia quedan algunas que prefieren ser 20 y que les vaya bien a todos... hay pocas, pero hay). Las grandes agarran todo lo que les deje plata, y las chicas que no tienen mucho laburo tambien.

(20-06-2013 13:23)brunodiaz escribió:  Entrar en nuevos requerimientos es tambien laburar sobre lo que ya esta. Si pones tu propia empresa y te va bien en 2 años estas en la misma.

Bueno, pero no es lo mismo estar en un proyecto donde te ponen como tarea sólo corregir bugs, que un proyecto que si bien está iniciado, se agregan funcionalidades o nuevos requerimientos.
Sí es una gran realidad que detrás de eso te topás con documentación inexistente u obsoleta, y que "el anterior hizo todo mal" o cosas del estilo. Eso sí es un constante, al menos por los lugares en los que pasé y los proyectos donde estuve.
Y si no tenés mantenimiento, vas a tener entropía. El mantenimiento, por más embolante que pueda parecer, es necesario. A veces los requerimientos surgen del mismo mantenimiento, de hecho a veces son parte del mismo mantenimiento, en otros casos (menores) son porque el cliente viene y te pide que su sistema puede hacer tal o cual cosa, porque se le cantó y porque te lo va a pagar

Hacer "de cero" es algo que no se da casi nunca prácticamente, pero como dije antes, la esencia o lo interesante quizás son los nuevos requerimientos que surgen, sea por el motivo que fueren. Capaz para un desarrollador termina siendo monótono, porque en definitiva se la pasan codeando. Para un analista, o al menos lo cuento desde mi experiencia, no se te vuelve pesado, porque justamente es uno el que está en la búsqueda de qué poder hacer para que evolucione el sistema, para ser más competitivo, para que el cliente te siga eligiendo... no sólo en cuanto a que tu sistema funcione bien y haga lo que tiene que hacer, sino también en el sentido de darle un valor agregado.

Supongo que por eso muchos developers después se cansan. Yo por lo menos nunca sentí eso. Por lo que puedo llegar a embolarme es porque el proyecto no sea de mi agrado, o por las tecnologías que tiene, o porque el cliente solamente quiera que funcione y nada más, no quiere que se lo mejores más aun.

En fin.

El punto es que mantener sistemas existentes es la regla y no la excepción.

---

Cita:For years, the two things that most frustrated me to hear from product managers were "how hard would it be..." and "can't you just..." It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. The answer seems obvious now: The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product, and yes, we can "just" code any logic someone dreams up. What might take two weeks right now adds a marginal cost to every engineering project we'll take on in this product in the future. In fact, I'd argue that the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.

It's often subtle or intentionally hidden features that cost the most in the long term. Yammer has long had a feature that allows you to begin a message with "to:" and a username to send a private message to someone, or followed by a group name to post to a group. This probably took me an hour to implement, test and deploy back in early 2008. I have easily spent 40 hours of my time -- and, necessarily, 40 hours of others' time -- over the intervening 5 years explaining this feature and its justification. That's a 40x communications overhead just to carry the feature, even before we consider its impact on people once they get into the code. You might argue that documentation solves this problem, but I assure you that this is well documented in the code... somewhere.

Once you're in the code, the complexity cost gets more obvious. The first time you open a new section of code, you need to orient yourself. The fewer things the code does, the quicker this process. Even well-factored, well-written, clean code can take a while to become familiar with if it does a lot of things. Anything missed creates rework later: Maybe you break a unit test; maybe you don't and the code makes it to users who report bugs, costing your support or QA team time even before it gets back to cost you more time.

Read more: http://firstround.com/article/The-one-co...z2WnIITLo6

Estoy de acuerdo, en muchos casos vamos a tener que mantener sistemas.

Igualmente, me refería más específicamente a los casos en los que te dan un sistema que no se desarrolló en la empresa, que tiene documentación nula, y del cual se conoce poco del negocio, para arreglar bugs muy específicos y no para desarrollar nuevas funcionalidades.

Mi pregunta venía por el lado de cuán habitual es que las empresas tomen proyectos de este tipo, que a mi entender no son para nada felices para los desarrolladores. Ojo, tal vez me estoy equivocando y haya gente a la que realmente le motive participar en estos proyectos. ¿Ustedes se sienten motivados teniendo que participar en proyectos así? ¿Estamos "condenados" a tener que toparnos con estos proyectos en la cotidianidad de nuestra vida profesional? ¿Son muy pocas las empresas que no admiten este tipo de proyectos?

Gracias por las respuestas!

No me motivaria un proyecto asi... lo cierto es que cuando el laburo abunda, esos proyectos se descartan... ahora, si el laburo es poco, se agarra lo que se puede . Ademas imaginate que tenes un cliente groso que te tira proyectos buenos... y cada tanto te tira un muertazo como eso que mencionas... es jodido decirle que no...

Me puede llegar a motivar que el sistema tenga algo interesante.

Pero no creo que tengas que toparte constantemente con eso si no queres.