Cambios Inesperados

[Anónimo]

Debe responder a la pregunta realizada en el contenido DP-04

[Raúl Fernando Ayllon Salinas]

A simple vista lo primero que se detecta es que no se respeto en lo mas minimo SoC, SRP  ademas que estoy completamente seguro que no se podria reutilizar casi nada de la solucion provista(DIP)

“In a clean system we organize our classes so as to reduce the risk of change” Robert. C. Martin – Clean Code

Muchas veces debemos realizar cambios, esperados o no en nuestras implementaciones. Necesitamos en todos los casos tener entornos de testing, staging y finalmente produccion. Si lo se a veces “no hay tiempo” para probar las cambios pero en que caemos entonces? Por temas de tiempo no realizaremos testing a nuestro codigo ? dejaremos de respetar los Design Patterns que hacen que nuestra solucion sea robusta, escalable y facil de mantener?.

Otro punto que me llama la atencion en la situacion presentada, la cual no justifica para nada el resultado, es que al parecer no se tenia documentacion del uso del producto en lo mas minimo o quizas se busco la mano de obra mas economica lo que muchos de los clientes suelen preferir. Se que documentar nuestras aplicaciones es tedioso, a veces aburrido, pero a pesar de todo trae beneficios a largo plazo. Si el “mecanico” a cargo del trabajo tenia la documentacion pudo encontrar alli el tema del cable que iba conectado al motor, quien pudo diseñar un producto de esta manera, y asi evitar el quedar tan mal realizando una tarea supuestamente sencilla que termino en que el automovil no encienda mas.
Un cambio en la aplicacion no deberia bajo ninguna razon “crashear” la aplicacion, quiza desde mi punto de vista afectar al modulo mas cercano a donde se realize el cambio directamente, esto nos quita la reputación que cuesta mucho crear la cual debemos cuidar y valorar a veces inclusive mas que la cantidad de dinero que podamos ganar por realizar un trabajo.

[Alvaro Cardenas Venegas]

El ciclo de desarrollo de software (SLDC), ya sea en una metologia agil o en cascada, busca minimizar los fallos en ambientes de produccion para los clientes, para esto se define etapas de documentacion y pruebas a diferentes niveles durante la construccion, esta informacion es importante para el mantenimiento de la solucion mas adelante.

En el escenario descrito en DP-04, mi impresion es que el responsable de reparar el retrovisor solo vio el incidente en particular (reemplazo del retrovisor) y se centro en las pruebas asociadas a la pieza en particular (funcionalidades del retrovisor) pero no hizo al menos un smoke test para garantizar que las funcionalidades basicas de todo el sistema (el automovil) se encuentren operando correctamente, que son pasos minimos que se deben realizar para corregir una falla, por otro lado es importante revisar la documentacion asociada al producto antes de iniciar la correccion de un falla/defecto (bug) para enteder el impacto del cambio que se realizara y comprender la naturaleza del diseño realizado, al estar en una etapa de mantenimiento el paso de revisar la documentacion es importante.

Finalmente llegar al extremo de que el cliente tome control de los cambios a aplicar en el software demuestra que los responsables de gestionar y construir/mantener el software no han mostrado al cliente un proceso ordenado de identificacion de fallas y resolucion de las mismas con etapas de verificacion (pruebas), evidenciado en los resultados la estabilidad que se esta alcanzado aplicando mecanismos de ingenieria tras cada paso que se da.

[Kleber Isaac Aquilar Perez]

En el caso presentado se nota la importancia de las buenas prácticas a la hora del desarrollo, quizá aplicar el principio de responsabilidad única y el principio abierto/cerrado (por nombrar algunas prácticas) hubieran evitado el problema; es muy importante crear soluciones para los clientes que engloben todo el significado de la palabra y no crear una solución a corto plazo que probablemente pasado un corto período de tiempo resulte más complicado que el problema que se trataba de resolver. Como hemos aprendido en el corto tiempo desde el inicio del programa hay que saber diferenciarse entre un programador y un programador profesional.

[Kevin Eduardo Barja]

Podríamos decir que tocar fondo respecto al mal diseño de un producto de sw es cuando:

• Desde el punto de vista gerencial:
  • Existe baja o nula productividad, realizar nuevas funcionalidades, corrección de errores, etc. Consumen mucho más tiempo y recursos económicos comparado con etapas tempranas del proyecto, lo que podría llevar a la quiebra a la empresa o caer en desventaja con la competencia al no poder cumplir el roadmap.
• Desde el punto de vista programador:
  • El código base no es reutilizable, es rígido,  frágil. No puedes dormir tranquilo sabiendo que tu cambio puede romper otras partes del código que quizás tu no escribiste y no tienes un mecanismo de testearla.
  • Dedicas más tiempo descifrando lo que hace el código, en lugar de leer y escribir código.

[Paul Fernando Grimadlo Bravo]

En lo personal pienso que es una de las barreras mas grandes que existen en el desarrollo de software dentro de lo que a nuestro país corresponde. La mayoría de las personas que buscan desarrolladores de software generalmente suelen tener solo la idea de lo que necesitan, y muchas veces poco o mal estructurada, en cuanto a las empresas ocurren exactamente lo mismo, para equipos novatos generalmente, o que comienzan en una startup, los gerentes de proyectos, el gerente de la empresa, suelen ser en gran mayoría personas lejanas al área de tecnología, lo que repercute directamente en el diseño del sistema. Pues que para ellos (como se mencionó en alguna clase) solo le interesa los números,  lo que se traduce en un diseño pobre, y es donde entran a futuro el prohibir cambios en el sistema, cambios que los desarrolladores creen que puede ayudar al sistema de manera general.

[Luis Rolando Vasquez Velasquez]

En terminos de software, a mi entender son las consecuencias de un diseño de baja calidad, que seguramente no aplicó los estandares y mejores practicas para su desarrollo.

Normalmente va empeorando con el tiempo hasta llegar al punto que se menciona como “tocar fondo para el diseño de un producto” en donde los usuarios o el dueño te prohiben que toques mas el codigo.

Una experiencia que me toco vivir, fue el heredar un sistema que tenia un mal diseño, y por tanto su codigo tenia serios problemas. Al ser entre mis primeros trabajos lo acepte sin problemas, pero meses despues se volvio insostenible por los problemas que generaba. Mirando atras, creo que, como profesional tendría que haber solicitado un analisis previo del sistema, haber hecho un diagnostico, y presentar el informe donde tendria que haber indicado los problemas serios que presentaba el mismo  para luego hacer una analisis de costo beneficios respecto si valia la pena rehacerlo o no.

[Patricia Cano Encinas]

¿Qué es tocar fondo para el diseño de un producto?

Es cuando la situación se ha tornado insostenible debido a las malas prácticas implementadas en el diseño, al principio tal vez no se notan tanto, pero paulatinamente el código se torna difícil de mantener, surgen cambios o requerimientos que no fueron pensados al inicio, que no se contempló, y para los cuales lo programado no soporta, que obliga a parchar, en algunos casos duplicar código para no tocar lo anterior, aumentando el nivel de code smells, en otros casos modificando sin una planificación, provocando errores en lugares donde antes todo “funcionaba bien”, debido a que no se dimensionó el impacto del cambio, ni se trabajó bien desde el inicio. Esta sucesión de problemas llega a un punto donde inclusive se pierde la confianza del cliente, ya que cada cambio se traduce en más errores, más tiempo, más costo y un producto que pierde credibilidad.

[Yely Josefina Galindo Ribera]

Creo que toda empresa o como desarrollador Freelance deberíamos tener procedimentado los pasos para que nuestro software asegure una calidad aceptable en precios competitivos, muchas veces por ahorrar dinero las empresas o programadores sacamos software muy fragil o que funciona con los requerimientos aceptables, pero con el tiempo dar soporte o hacer ajustes a este software nos lleva al camino de que los cambios pueden romper otras funcionalidades, para esto se debe tener procedimentado la parte de pruebas necesarios, etc.

Nunca me ha pasado que me digan lo de no tocar codigo, si me ha pasado que por corregir algo , se daña otra funcionalidad, por medio de estandares y procedimientos que tenemos se ha detectado en pruebas de software antes de llegar a los usuarios finales.

[Irene Jenny Apaza Peralta]

Que es tocar fondo en un diseño :

Es cuando un usuario no sabe que hacer con el producto( el producto no es lo que necesita), pues el producto tiene fallas tan obvias. Por no seguir un proceso correcto donde exista interacción real con los usuarios ( comentarios reales del usuario) ayudando a prevenir tempranamente fallas.

Es decir se debe diseñar en función a la necesidad y deseos del usuario , de esta manera se marcara la diferencia, solucionando los problemas o fallas  en temas de software puede requerir poca inversión pero al final con muchos frutos, tomando en consideración siempre que el un buen diseño es un gran negocio.

[Franz Ajit Singh Verdi]

<span style=”color: #444444; font-family: Lato; font-size: 14px;”>¿Qué es tocar fondo para el diseño de un producto?</span>

Cuando llegamos al punto en el que perdemos el control sobre el producto. el punto en el cual no podemos continuar realizando cambios, corrección de errores o desarrollo de nuevas funcionalidades debido a un mal diseño.

[Marco Antonio Gil Montero]

<div style=”-en-clipboard: true;”>Qué es tocar fondo para el diseño de un producto?</div>
<div>Cuando no se pueden implementar soluciones o mejoras sin que existan consecuencias o bugs en el funcionamiento del producto en otros modulos diferentes al que se esta trabajando.</div>

[Nanet Taboada Frias]

Tocar fondo para el diseño de un producto de software desde el punto de vista del usuario o dueño que no tiene idea de la tecnología, podrían pasar diferentes ideas por su cabeza, podría sentir que la productividad es muy baja con relación a lo que esta pagando por  los cambios o nuevas funcionalidades, también que se esta tardando demasiado en agregar una pequeña funcionalidad.

Por lo que podemos pensar que el código de ese producto no es de calidad, el código es rígido, frágil y es inmovible por lo que tendríamos problemas al momento de agregar un nueva funcionalidad, tardar mas reutilizando lo que se tiene que agregando nuevo código.

 

[Guillermo Soliz Nagatoshi]

<span style=”color: #444444; font-family: Lato; font-size: 14px;”>¿Qué es tocar fondo para el diseño de un producto?</span>

Tocar fondo es cuando se llega se llega al limite, en este caso donde por una serie de situaciones se llega a perder el enfoque o el fin del diseño y este ha tomado otro rumbo.

Esto sucede por muchas razones, puede ser que no se implementaron buenas practicas, por no tener todos los requisitos completos, muchas veces a los desarrolladores les entregan ciertos requerimientos para realizar, pero no le explican el fin, cual será el resultado final, por ese motivo no se toman en cuenta muchos casos de uso, todo esto conlleva a un mal diseño y desarrollo de un software, que va aumentando con el pasar del tiempo, donde llega a un momento donde un solo cambio puede tardar semanas o realmente el sistema no puede soportar ese tipo de cambio sin volver a reestructurar mas del 50% del sistema.

Y es ahí donde  a veces prefieren no implementar ciertas funcionalidades por el hecho de evitar que el sistema colapse mas de lo que se encuentra o porque el cambio no se puede medir en tiempo y alcance.

[Alvaro Dante Espejo Maidana]

En nuestro contexto los cambios inesperados que surgen de un mal diseño, tienen mucha relación con los equipos y lideres de proyecto versus el presupuesto con el que cuenta el desarrollo del producto de software, mientras menor el presupuesto, el producto de software presentara muchos mas cambios inesperados debido a la baja calidad del diseño y desarrollo.

En relación a la pregunta ¿Qué es tocar fondo para el diseño de un producto?, es cuando se llega al límite de forma desfavorable en lo que respecta la visión de los principios y métodos del diseño del producto de software.

[Adan Condori Calisaya]

En el ciclo de desarrollo de software siempre existirá cambios inesperados, para poder afrontar debemos tener definidos alcances previamente con el Dueño del producto, así mismo para poder hacer esto debemos apoyarnos en un marco de trabajo como SCRUM, el cual nos ayuda a definir Sprint en el cual tendremos pequeños entregables donde el desarrollados como el PO estarán contentos, asá mismo esto no quiere decir que no tendremos cambios inesperados, seguiremos teniendo pero sera en menor grado por lo cual el desarrollo avanzara.

En mi experiencia de debe definir el alcance inicial con el PO, y el PO debe hacer un acompañamiento muy de cerca para que se pueda cumplir, este alcance se ira entregando en pequeños entregables hasta alcanzar el alcance final.

[Autor]

Entradas