Revisar el trabajo
22-02-2006 | Desarrollo |En un mundo perfecto nadie debería revisar el trabajo de nadie, sería perfecto, no habría fallos, no habrían defectos, pero…. eso, no estamos en un mundo perfecto.
Parte de mi trabajo consiste en revisar lo que hacen otros, en darle el visto bueno o devolverlo para que lo arreglen. Como programador que soy entiendo que muchos de los fallos son porque no se entendió bien la especificación (no formal y muchas veces no por escrito, mea culpa), entonces el desarrollador lo hace como él cree que ha de hacerse, que no es como yo tenía en mente o como el cliente nos lo pidió.
Algunas veces no se hace bien porque en medio de un proceso de codificación hay una interrupción, de lo que sea, de una llamada, de un mensaje, de un compañero pidiendo ayuda. Y cuando vuelves al código, te has olvidado de poner aquella comprobación adicional que querías, o verificar que el índice está dentro del rango del array, o…. mil cosas más.
Otras veces simplemente no se ha hecho bien por dejadez, por desidia, hay que decirlo, por no querer llegar hasta el final. Quienes trabajan conmigo saben que nunca pongo prisas, que antepongo la calidad al plazo. Muchas veces no son capaces, los programadores, de ponerse en la piel del usuario medio y darse cuenta que lo hecho no le sirve al usuario porque tiene que hacer en 10 pasos lo que se podría hacer en 2. A mi también me ocurrió en mis tiempos mozos, pero para algo han de servir los años dedicados a esto.
Las hay, las veces, que simplemente es por no probar a fondo lo desarrollado, o por hacerlo muy superficialmente, me imagino que, en parte, puede ser porque estoy yo, por que saben que voy a revisarles el trabajo.
Pero … una pregunta ¿tanto cuesta revisar nuestro propio trabajo antes de entregarlo? ¿Porque no nos exigimos un poco más de excelencia en nuestro desempeño?
Desde hace tiempo utilizo una máxima:
Una tarea no está terminada hasta que no he verificado completamente el resultado.
Pero no por nada en especial, si no porque terminé harto de tener que rehacer las cosas tres veces… lecciones aprendidas en la dura escuela de la vida.
Artículos relacionados
- Mis funciones dentro de la empresa
- Una semana “out”
- Errar es de humanos
- SCRUM: El trabajo realizado
- Silencio … se trabaja.
23-02-2006 02:20
He leido tu post, y realmente me encuentro muy identificado. Recientemente me han ascendido a jefe de desarrollos, y la verdad que estoy viviendo en carne propia eso que dices.
En mi caso la gran mayoria de las veces los errores vienen por que no se prueban las cosas lo suficiente.
La peor vez fue cuando me llego para probar una modificacion sobre un sistema que ya estaba en produccion, y cuando llego a la parte que se estaba modificada directamente se me caia….y asi ocurria las 3 o 4 que repeti el proceso. Me di cuenta que el programador no habia probado NI UNA vez lo que habia hecho …. no hace falta decir que lo colgue de las pelotas!!!
Creo que el problema en mi empresa viene por algo de la cultura organizacional, la percepcion de los programadores es que su trabajo termina cuando el codigo que escribieron “se deja compilar” cuando en realidad tendria que ser “el codigo que escribi es de calidad garantizada por mi (el programador)”, donde calidad es una palabra que abarca muchas cosas (satisfaccion del cliente, mantenibilidad, claridad, efectividad, y un largo etc.).
Tu frase “Una tarea no está terminada hasta que no he verificado completamente el resultado” va a pasar a ser el lema de mi depto de desarrollos!!!! ;-D
Salu2
Pablo
Pd: un tiron de orejas, y haber si puedes hacer algo para publicar comentarios desde el firefox,
23-02-2006 08:38
Pablo, me alegro que adoptes el lema
Que razón tienes al decir que para muchos programadores su labor termina cuando el código puede compilar. Por eso Eric Sink diferencia entre programadores y desarrolladores.
Si el equipo de desarrollo es pequeño y poco estructurado, como es mi caso, se necesitan desarrolladores y no programadores a secas.
No entiendo lo de los comentarios desde firefox… Este lo estoy escribiendo desde la versión 1.5 del mismo….
¿Alguien más tiene problemas con el firefox para escribir comentarios? Enviadme un mensaje a jhernandis (arroba) mixmail.com
23-02-2006 10:58
El problema es que es muy difícil para un programador o desarrollador comprobar todos los casos y realizar una auténtica depuración, porque SIEMPRE habrá un caso o dos donde no se ha previsto algo. Y preveerlo es casi IMPOSIBLE.
El programador no solo se enfrenta a la problemática de la programación, existen otros muchos factores que influyen.
Sino, que se lo pregunten a Bill Gates cuando se le colgó el equipo y le salió un pantallazo azul al conectar un scanner en la presentación de Windows 98
¿Acaso los programadores de Microsoft no probaron del todo el software?
¿Acaso Microsoft no tiene un control de calidad que exige el completa verificación del código?
Lo que pasa es que esta profesión es muy ingrata y llena de factores que el desarrollador no puede controlar.
Que se debería probar mejor el software desarrollado por el programado? totalmente de acuerdo, pero entonces como justificarías esa parte de trabajo que tu mismo haces ?
Alquien tiene que realizar la verfificación aparte del desarrollador.
No es por criticar, pero es muy fácil comprobar y sacar fallo a algo desarrollado por otra persona, aunque esté bien, sobre todo porque TODO se puede mejorar.
Tu dame un trabajo que hayas realizado tu y te garantizo que le saco fallos.
Un saludo
23-02-2006 11:31
Desarrollar software es una de las actividades mas complejas que se pueden abordar hoy en día. De eso no tengo duda. Llevo más de 15 años en ello.
Igual es que no me he explicado bien en el post.
Lo que intentaba decir es que muchas veces hay fallos OBVIOS, muy tontos, hay fallos de sentido común, errores que evidentemente no los ha visto el programador porque NI SIQUIERA ha mirado el resultado de lo que ha hecho. A eso me refiero, como ha escrito el código, el compilador no se ha quejado, pues ya está bien… Y eso, ocurre, muchas veces, más de las que sería normal.
Intentaba transmitir la necesidad de ser más exigentes con nuestro propio trabajo, de no querer terminar enseguida, de verificar más las cosas, que desarrollar no es sólo escribir código.
Evidentemente no se pueden controlar TODAS las situaciones, es imposible, totalmente. Pero…
Un ejemplo: si a un programador le dices, “Añade un botón a esta pantalla para que muestre la ficha del cliente del documento”, el programador añade el botón, y al pulsarlo se abre la ficha, ok. Pero ¿tanto cuesta pensar que si no hay cliente seleccionado en el documento, porque es un documento nuevo, que se está creando, el botón ese no debe hacer nada, es más, debería estar deshabilitado hasta que haya un cliente asignado?
Pues a eso me refiero.
23-02-2006 11:55
Creo que habría que hablar de dos cosas distintas, por un lado revisar el código para ver que cumple con los parametros de calidad necesarios, calidad de codificación, diseño adecuado, seguimiento de estándares de codificación, etc, etc. Y por otro lado revisar que un programa funciona correctamente, son dos tareas diferentes que se deben hacer por personas diferentes.
Revisar el código es algo fundamental, kent Beck dice que el XP es llevar al extremo practicas que considera se sentido común, una de ellas es la revisión de código, y su conclusión de llevar al extremo la revisión de código fue el pair programming.
Se puede estar de acuerdo con Kent o no, pero esto nos sirve para poner de manifiesto la importancia de la revisión del código, desde las revisiones automaticas (diferentes metricas sobre el código) que pueden servir para poner “alarmas” y revisar en más detalle algunas partes hasta las revisiones exhaustivas de un programador más experto.
Por otro lado, siempre tiene que haber alguien en una empresa encargado de revisar que el programa funciona como se esperaba antes de que llegue al cliente. La responsabilidad de que un programa o caracteristica falle cuando se ha entregado al cliente no puede ser nunca responsabilidad única del programador que lo implemento, tiene que ser responsabilidad de toda la organización, porque es la organización la que ha fallado si un error no se detecta a tiempo.
Yo en mi empresa sufro en mis carnes la falta de organización a diario, los programas en muchas ocasiones salen al cliente sin haber pasado las pruebas adecuadas y la responsabilidad del error siempre va a parar a los mismos. Imaginar que una caracteristca facil de implemntar se la encargo a un becario sin experiencia, este comete un error y el cliente se encuentra con un fallo inesperado en la aplicación, ¿como organización puedo permitirme el lujo de que pase esto?,¿la culpa es del becario?, esta claro que no. En este caso la culpa es parte del becario por su error, parte mia por no revisar su trabajo correctamente, y sobre todo del departamente o encargado de calidad que no ha probado correctamente la caracteristica. Y si no hay nadie encargado de verificar la calidad, que pasa en muchos sitios, pues entonces la culpa es integramente de una organización empresarial mal construida que no garantiza la calidad del software que produce.
Ahh, y suena muy feo esto de buscar culpables, pero no se trata de buscarlos para echarles una bronca o ponerles de ptaitas en la calle, se trata de buscar el origen de los problemas para solucionarlos y no volver a cometer los mismos errores.
23-02-2006 12:25
Lo que tampoco se puede hacer es eludir la responsabilidad que tiene cada uno. Un programador se puede quejar de que no se le ha indicado bien su tarea, pero no de que no la ha realizado correctamente.
Si alguien no hace bien su trabajo, hay que decirselo, hay que hacerle ver que puede y debe hacerlo mejor.
Rastafari, tienes razón al decir que si el fallo ha llegado al cliente habiendo un responsable de Q.A., desde el punto de vista del cliente es culpa del equipo entero, no de un individuo. Pero internamente si que se sabe quien ha cometido el error, y si que hay un culpable.
No entiendo porque la gente tiene tanto miedo de reconocer que comete errores, si son oportunidades de aprender… Si hay un culpable, hay un culpable, lo otro es no querer llamar a las cosas por su nombre, así lo veo yo.
Hay que entender lo ocurrido, buscar remedio y modificar los procedimientos, técnicas, costumbres y prácticas para intentar que no vuelva a ocurrir.
No me quejo de mi trabajo, me quejo de la falta de exigencia que tienen algunos, de la dejadez, del decir “ya está!” y nada mas entrar en la pantalla ¡¡PAM!! un error. Eso indica que ni lo han probado un mínimo.
26-02-2006 16:47
sadasdasds
22-08-2006 09:25
Totalmente de acuerdo. Hoy en día es frustante la codificación, “el ya está “es equivale ya he “tirado” unas cuantas líneas de código. Y cuando lo pruebas te das cuenta que es IMPOSIBLE que a esa persona lo haya minimamente probado, ni ejecutado una vez.
Soy totalmente partidaria que la aplicación debe probarla otra persona que el desarrollador pero para encontrar ese tipo de errores mas complicados pero hay un mínimo que el desarrollador debe entregar.
Por otra parte el desarrollado debería poner más interes por entender la aplicación, despues de 4 semanas ya se pide un poco más a la persona que desarrolla, pero nada pasan las semanas y se producen errores que indican que no se entiende nada la aplicación.
Es una pena, con lo bonito que es desarrollar.
El nivel cada día es más bajo….
Bueno, que bien me ha venido este post para libera un poco de frustración y continuar en la batalla. .