No vemos las cosas como son, las vemos como somos.
– Anaïs Nin
Nuestra perspectiva del mundo
Tag Archives: Pensamientos
ENIAC, Mark I y la importancia de los tiempos de respuesta
Si bien, es cierto ENIAC es reconocida como la primera computadora (1945), un año antes ya existía la Harvard Mark I, que incluía el uso de tarjetas perforadas para su programación (técnica que se usó por muchos años) y soporte a ejecución multipropósito (a la fecha, cualquier computadora personal cumple ese objetivo)
Entonces, si ENIAC se programaba por medio de circuitos (lo cual incrementaba la complejidad de entendimiento y uso) e inicialmente ejecutaba cálculos con objetivos armamentistas ¿Por qué cuando se habla de Historia de la Computación, se le da tanta relevancia?
Yo creo que no solo tuvo que ver su importancia e impacto en objetivos armamentistas de la época, sino también su velocidad de ejecución. ENIAC realizaba cálculos matemáticos en menos de 1 segundo, mientras que Mark I podría tardar hasta 15 segundos en mostrar el resultado de una simple operación aritmética.
Queda decir, que si la velocidad de ejecución siempre jugó un papel importante ¿Por qué no darle la relevancia del caso, incluso desde etapas muy tempranas?
Les deseo un excelente inicio de semana.
JD
Éxito y Calidad de Software (Borrador)
Estaba pensando en una investigación que hace mucho dejé de lado, pero que he decidido retomar. El triángulo de hierro está involucrado y también una presentación que hice hace 9 años (!@#!@#! estamos envejeciendo)
Tenemos que aceptarlo, hace mucho que la calidad ha pasado a un segundo o tercer plano debido a la posiblle confusión generada por la agilidad y la necesidad del negocio porque es “transparente”, “ya debería venir”, “no habíamos pensado en eso” o bueno, “es una caja negra”, cuando en realidad es un factor crucial para el éxito en un proyecto.
Pero bueno, voy a darle una mirada a esa presentación que hice en Microsoft Perú por esa época, estoy seguro que muy pocos la recuerdan. También estoy seguro que mis chistes fueron malos, Pero diablos, tanto tiempo y esa ppt tiene cosas que siguen caladas en mi ser!
Abrazo de gol peruano.
JD
Deuda técnica en el 2017
Si bien es cierto nunca he escrito sobre la deuda técnica, reconozco que cada cierto tiempo reviso o empiezo un nuevo borrador al respecto y lo dejo –con mucho dolor– en la lista de apuntes sin publicar.
Hoy por la noche voy a borrar aquellos apuntes y tengo un sinsabor que aumenta con el paso de los años.
Antes de continuar con ello y para quitarme el clavo, aquí algunos apuntes:
- Ward Cunningham indica que la deuda está asociada a la programación/reprogramación/corrección que harás más adelante, pues hoy –o ayer– no hiciste un programa sin seguir las recomendaciones, estándares o buenas prácticas de programación y/o arquitectura.
- McConnell y Fowler clasifican las causas como deliberadas, por desconocimiento o incluso ingeniudad.
- Por mi parte y considerando que más que software se entrega una solución, pienso que la deuda se debe analizar en todo sentido, en cada capa, etapa, proceso, modelo o secuencia utilizada para la creación del producto.
- Esto significa que también se debe hacer una mención al hecho de cómo se definen las necesidades de los usuarios o cómo es que se compila, distribuye o instala el software resultante.
- Tampoco se debe olvidar el prototipado/maquetado de la solución. El cual a veces es olvidado y otras es tan sobrevalorado que hasta llegas a odiarlo.
- La deuda se debe mitigar de a pocos ni bien se vaya identificando. Sería ideal eliminarla pero casi nunca es así.
- Para finalizar, creo que para no confundir, la deuda técnica debería cambiar de nombre o al menos de versión, pues la realidad ha cambiado y con tantos nuevos jugadores, debería existir algo así como una “Deuda Técnica 2.0”
Jersson on the block 2.0 