El amigo Ignacio (@i_cruzado), con quien hace un tiempo compartí algún proyecto interesante (y con el que espero de nuevo volver a encontrarme en algún otro próximo y duro proyecto), me envío la semana pasada un correo de esos que te hace recordar que por mucha burrada que a uno le toca ver en esta profesión… siempre queda otra que te sorprende. En vez de contarlo yo, con su permiso os dejo abajo el correo que me envió:
Hola Javier,
Gracias por tus tweets.
Procedo a contarte lo que no cabe en tan pocos caracteres: es una batallita que te cedo sin (C), para que puedas incluirla en tu blog, clases, conferencias o donde gustes ;- )
El caso se ha dado en un proyecto que dirijo:
– Nosotros (mi equipo de desarrollo) llegó tras una primera versión -fracasada- en la que otro proveedor de software (de cuyo nombre prefiero no acordarme: R.I.P.) se había estrellado creando el 90% del producto… con tan mala programación que el 10% restante no se soportaba con la arquitectura planteada. Claro, el valor del producto residía justo en el 10% restante y no en el 90% de pantallitas-conducentes-a que habían completado.
– Así las cosas el Cliente nos contrató para sacarles del apuro. Se negó a perder el año de trabajo (pagado) al primer proveedor y nos solicitó: 1º una consultoría del estado de la cosa. 2º un presupuesto de cómo revivirlo (a precio mínimo, of course).
– Lo hicimos y les levantamos la aplicación (refactorizacion brutales subyacentes, re-implementación del motor, …) pero no pudimos modificarles el Modelo de Datos (too late!).
– El caso que nos atañe sucede en una bonita tabla en la que el diseñador de BBDD no tuvo a bien estudiar teoría de normalización (y por eso la tabla tenía 254 campos la semana pasada) y el programador que hizo el WebService tampoco estudió patrones de diseño (por eso decició recibir 254 parámetros; uno por campo) en lugar de utilizar el Patrón de Diseño Command y dejar de abusar de la pila y de la máquina.
– Yo como arquitecto no era consciente del puntual dislate… hasta que un miembro de mi equipo ( de profesión xxxx ¿coincidencia?), que estaba manteniendo la aplicación resolviendo un Change Request (‘necesitamos un par de campitos más!’) decidió, con coherencia con el diseño planteado; a) alter table introduciendo los 2 campos y b) modificar el WS introduciendo un par de parámetros más.
– La BBDD aguantó, pero al guardar el .java el IDE le dió un mensaje raro: <<Too many parameters, parameter BLAH is exceeding the limit of 255 words eligible for method parameters>>
– Así que, como ‘experto’ me llamó, porque ese mensaje no lo había visto nunca (y por lo visto se fia más de mí que de San Google).
– Yo desconocía este pequeño detalle de diseño de la JVM, pero agradezco profundamente al que lo decició que utilizase UN byte para indexar el número de parámetros, porque sino el dichoso método hoy tendría 257 y estaría camino de acabar teniendo 65535 ;-D
– Y dado lo lastimoso del asunto me decidió a publicarlo por Tweeter por varias razones: por buscar empatía con otros ‘softwareros’, por volver a reseñar lo lamentable del nivel de calidad de mucho del software en producción actualmente (who cares?!), por indicar carencias de formación y designación en puestos de trabajo y por explicar que al final, hasta el javac ayuda a no hacer burradas como esa… menos mal!
Aprovecho para agradecerte toda la info que posteas, a felicitarte las fiestas y a desearte un 2012 más próspero (a poco) en el que ojalá podamos colaborar: está claro que éste no ha sido el año :-S
Ví el twitt de tu colega y coincido bastante: la gente se enrolla en demasía y al final los 5 principios básicos se pierden de vista. Aún me cuesta convencer a la gente para que aplique Liskov y en cuanto me doy la vuelta empiezan a meter swtichs y else-if que luego pagamos entre todos con sangre (horas de trabajo, quiero decir).
Salu2
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Pingback: Bitacoras.com
Que animal Ignacio. Y no le dijiste que se buscase otro siio donde chapucear?
Las burradas creando tablas y con SQL dan para una buena colección de cometarios… me estoy acordando de algunas. La de «meto siempre 10 atributos de más, tipo string, por si en el futuro se necesitan, lo hacemos porque buscamos la mantenibilidad»
No hay más que verlo:
Estudias medicina -> eres médico
Estudias ingeniería industrial -> eres ingeniero
Estudias ingeniería de software -> eres ____ informático,
completar ____ con adjetivos, como por ejemplo: friki.
Igual algún día hacemos las tareas como ingenieros, para que nos llamen ingenieros.