Chess - antoniomartel.com

Archivos de Categoría: Blog 1

El golpe en la mesa funciona (pero solo un rato)

Puede que a veces sea necesario dar un golpe en la mesa para conseguir un cambio, una reacción, pero ¿es eso todo lo que puedes hacer?

Si tienes un problema, o tienes que hacer una entrega es posible que te funcione dar un toque de atención, pero si dos semanas después hay otro incidente en producción que no se resuelve, o cada final de mes tienes que volver a dar otro toque de atención para que te hagan caso, para que “se pongan las pilas”, me temo que esto no te está funcionando.

Revisa el problema de fondo y descubre qué está atascando al equipo ¿Son las pruebas insuficientes y por eso hay tantos errores? ¿Están los requisitos mal redactados? ¿Tu gente tiene el conocimiento suficiente para hacer el trabajo? Descubre qué está pasando y pon medidas para resolverlo.

Gobernar por impulsos, llamar la atención y echar broncas va a conseguir una mejora repentina de la fiebre, pero no del problema. Saldrás del atasco y salvarás la cara por unos días. Solo hasta el siguiente problema. Además, seguramente estarás retrasando todo lo otro que no está bajo la línea de fuego ahora. Sin embargo, lo estará en breve, cuando se pase esta alarma y alguien descubra que se desatendió el resto del trabajo durante días.

Tengo malas noticias: no va a ser rápido, no va a ser fácil, pero es la única forma de mejorar un poco. Van a pensar que no estás haciendo nada, que hace falta alguien que dé un golpe rápido de timón, pero no creo que ningún barco llegue a buen puerto a base de dar bandazos de un lado a otro según alguien reclama tu atención aquí o allí.

Marketing de sepulterero (por Amalio A. Rey)

Algo de esto le ha pasado a Agile. Primero cayó en combate el Scrum Master. Al poco tiempo hablar de Scrum ya sonaba a viejuno. Por último, todo lo que suene a Agile recuerda ahora a los vendedores de aceite de serpiente del salvaje Oeste. Te vendían el mismo remedio como bueno para tratar la caída del cabello, el reuma o la artritis. Incluso para conciliar el sueño y teñir el pelo. Si usabas bien la loción, podía hasta salvar proyectos con alta rotación de personal.

No todo lo que daba vueltas alrededor de Agile se puede declarar difunto o simple humo. Los valores y principios básicos continuarán con nosotros mucho tiempo. Reformulado quizás, con un nuevo nombre y marketing, pero colaborar con el cliente, adaptar los requisitos y entregar pronto algo de código que ayude al usuario, eso dificilmente va a cambiar.

Ver el post de Amalio A. Rey en LinkedIn: https://www.linkedin.com/feed/update/urn:li:share:7374501464880254976/

¿Hay alguien que se lee la documentación?

Estos días leía un libro de arquitectura software en el que te aconsejaba: «No escribas documentación de más de 5 páginas. No se la van a leer».

Y ahora qué hago yo con los documentos de 40-60 páginas que escribí hace solo unas semanas!?

Me temo que tiene mucha razón. Veo los accesos a esos documentos, y apenas hay visitas. Solo unas pocas personas accedieron a ellos, y estoy seguro de que la mayoría solo le echaron un vistazo al índice y pulsaron Control-F para buscar algún término que les llevara directamente al grano.

Si quiero que estos documentos sean útiles, creo que mejor paso esos docs Word a páginas Confluence con solo un par de páginas por sección y unos pocos párrafos explicando lo impresicindible. Como máximo!

Proyecto para la creación de cuentas y jerarquía

He creado hace unas semanas otro pequeño proyecto en AWS para poner en práctica mis conocimientos en la arquitectura software con la nube de Amazon: una API serverless para la creación de cuentas y su jerarquía.

Este proyecto usa:
– AWS Lambdas con Python
– API Gateway
– Dynamo DB
– SNS para eventos de domino

En este enlace de GitHub puedes ver el código completo y el diagrama de la arquitectura: https://lnkd.in/eHNHFyf4

No alternative text description for this image

Parálisis por análisis

Hace eones construíamos una aplicación para una administración pública en la que el arquitecto software no se decidía nunca por ningún diseño para la aplicación. Y si múltiples usuarios se conectan a la vez? Y si se vende a otras administraciones y se multiplican los accesos? Mejor añadir más colas de mensajes, y throttling, y límites por cuenta, y…

Nada era nunca suficiente y la aplicación no se empezaba a desarrollar. La realidad es que el servicio solo tenía tres técnicos en Las Palmas. Quizás otros dos o tres más en Tenerife. Aunque todas las comunidades autónomas del país migraran a nuestro sistema, probablemente tendríamos menos de 170 posibles usuarios en total. Cuántos podrían estar conectados a la vez a las 9:35 de la mañana o a las 12:51? Cinco, diez?

Parálisis por análisis lo llaman. A veces los ingenieros software usamos la tecnología como excusa para no tomar decisiones, para no poner el cuchillo entre los dientes y empezar a programar. Era más importante que nunca evitar la complejidad innecesaria, la over-engineering, o aplicar el principio YAGNI (You Aren’t Gonna Need it).

Por más vueltas que les des no vas a evitar al 100% la posibilidad de cometer un error. Nunca. Siempre podrás mejorar el diseño 2 años después de haber propuesto el primer diseño. Y otros 2 años más tarde también pensarás que la nueva propuesta era aún bastante mejorable. Y así indefinidamente.

Haz un borrador, pruébalo, mejóralo luego y vuelve a probar. Todo diseño se basará en trade-offs. Todos son una apuesta. Si solo piensas en las desventajas, nunca aprovecharás ninguna ventaja.