18-December-2024 By Jeffrey Cooper
Hammers Before Heroes
For my Project 52 the past week, I spent it on testing, rather than creating. I have had fun doing it (I’m not finished yet). I have a friend at a startup who is beta testing a product that utilizes an LLM as a key part of it. I volunteered to test it. I like to try to break things (hence the graphic image above), or at least try some (sometimes) crazy combinations to see how the software handles it. Throw an LLM into it, and it makes it more interesting, given their non-deterministic output!
I won’t name the company or app out of secrecy, but I have enjoyed the process and as with everything, even if I have done it before, I continue to learn from it. This has been been both fun and informative, especially with the LLM thrown in the mix.
My Experience With Testing
In my career in engineering, software testing is one of those areas that frequently gets a short shrift. The joy in software for most people is in the design and coding and seeing it work. Frequently, testing is more limited to the so-called “Happy Path” to ensure a product delivers on its superficial premise.
I use the term “superficial” because that is the core of a product- do what is advertised. But, in reality, not failing while doing that is of key importance. To varying degrees, many engineers and companies fail at this.
I’ve seen, in my own teams in the past, a couple of points of resistance. One is lack of excitement- figuring out holistic tests that cover bad data input, improper uses, and myriad other sorts of possible failure (security, bandwidth, regression, usability) lead to fuller testing being under-addressed, or worse, skipped.
Though I’ve seen it less, I have seen some people get upset when someone else finds bugs in their code, and this tendency even more makes them want to avoid testing beyond the happy path. Counter to this, one of the best developers I ever knew, and one of the biggest influencers on my own design ethos (Dennis), was the reverse- he was actually happy when someone else found a bug in his code, because it meant the code is that much better. Though Dennis is one of the best developers I have ever known, he was under no illusion that, even as he knew he was very good, he was not perfect and bugs happen, no matter the skill level. I always wished I had more people like him.
(On a side note, I worked with Dennis at two companies, hiring him into the second one. For one program, my team, of which he was the technical lead, developed the 3rd largest subsystem in the product- Layers 2 & 3 of the OSI model, implementing data protocols over cellular radios. During the 2 year life of the product, that team had a total of 18 bugs, and it was a complicated piece of software. During that time period, another team with the largest subsystem on the product, some larger than ours but not massively so, had 50+ errors in one week! The contrast could not have been bigger.)
Toxic Combination
Another area of software that frequently gets shortcut (again, from personal experience) is good design and requirements gathering. And during this early phase, planning for testing is important.
Depending on your application or service, design is much more than how the pieces talk to each other or talk to hardware. It’s load balancing during peak times, optimizing third party service usage (to save costs), managing deprecation and planning for security and, very frequently overlooked, User Experience.
Couple a lack of testing with lack of attention to properly design of a system and you are asking for a nightmare.
You see examples of bad experiences every day as our lives are permeated by software driven products. Glitchy app on your streaming platform? Smart Home product malfunctions? Yet another data breach by a store or bank? Microsoft Windows 11 (I could go on for days on this one!)? Typically we experience a decent number of these glitches in our daily lives.
In fact, it is so frequent that sometimes I think the only way to avoid them is to go off grid for a day 😉
Footnote: On Dog Food And Diets
As it goes, eating one’s own dog food is generally good advice. I am redesigning and rebuilding the Word Hammer application I released last week to be more robust and flexible. And in the spirit of this, I am incorporating baked in unit testing using Jest and PHPUnit, which I am coming up to speed on in my home environment (the aforementioned Windows 11 machine). More on that later.
Nota para los lectores españoles: Estoy escribiendo mis articulos en dos idiomas mientras lo aprendo. Para mas información, lea este artículo.
Para mi Proyecto 52 pasé la semana pasada probando en lugar de creando. Me divertí haciéndolo (no he terminado todavía). Tengo un amigo en un startup que utiliza un LLM como una gran parte de la solución. Ofrecí probarlo. Me gusta romper cosas (de ahí la imagen grafica arriba), o al menos trato varias (a veces) combinaciones locas para ver cómo lo gestiona el software. Tira un LLM en la mitad, y es más interesante, ¡porque sus resultados no deterministas!
No nombro la compañía o app para secreto, pero he disfrutado el proceso y como todo, incluso como he hecho esto antes, sigo aprendiendo de ella. Esto he sido ambos divertido y informativo, especialmente con un LLM en la mezcla.
Mi Experiencia Con Las Pruebas
En mi carrera en ingeniería, las pruebas de software es una de las áreas que se queda corto, frecuentemente. La alegría en software para la mayoría es en el diseño y codificar y ver que funciona. Frecuentemente, las pruebas es más limitadas al llamado “Happy Path” (o “Camino Feliz”- no se cuando traduzca en español) para garantizar la entrega un producto la premisa superficial.
Uso el término “superficial” porque este el núcleo de un producto- funciona que cómo se anuncia. Pero, en realidad, no fracasar mientras se hace esto es de vital importancia. En diversos grados, muchos ingenieros fracasan en esto.
He visto en mis propios equipos en el pasado, un par de puntos de resistencia. Uno es una falta de entusiasmo- determinar pruebas holísticas que cubran malos datos de entrada, usos incorrectos, y
muchos otros usos de fracasos posibles (seguridad, ancho de banda, regresión, usabilidad) que conduzcan a pruebas más llenas que no se aborde suficientemente, o peor, omitido.
Aunque lo he visto menos, he visto varias personas que convierten molestas cuando alguien encuentra un error en su código, y esta tendencia les hace querer evitar probar más allá del happy path. En contra de esto, uno de los mejores desarrolladores que conozco, y una de las mayores influencias en mi propio ethos del diseño (Dennis), fue el reverso- de verdad feliz cuando alguien encontraba un error en su código, porque significó que su código es tal más mejor. Aunque Dennis es uno de los mejores desarrolladores que he conocido, fue bajo no ilusión que, aunque supo que es muy bueno, fue no perfecto y errores suceden, no importa del nivel de habilidad. Siempre deseaba que tenga más desarrolladores cómo él.
(En una nota de lado, trabajaba con Dennis en dos empresas, y contraté él en la segunda empresa. En un programa, mi equipo, de que fue jefe técnico, desarrollamos el tercera subsistema más grande en el producto- niveles 2 y 3 del modelo OSI, para implementar protocolos de datos sobre la radio celular. Durante la vida de 2 años del producto, este equipo tenía un total de 18 errors, y el software fue muy complicado. Durante el tiempo, un otro equipo con el mayor subsistema en el producto, uno poco más grande de nuestra pero no mucho más, ¡tenía más de 50 errors en una semana! El contraste no pudiera estado más grande.)
Combinación Tóxica
Un otro área de software que a menudo se queda corta (otra vez, de mi propia experiencia), es diseño y reunir los requisitos buenos. Y durante esta fase temprana, la planificación es importante.
Depende de su aplicación o servicio, el diseño es mucho más de que cómo las piezas se dicen al otro o le dicen el hardware. Es equilibrio de carga durante horas punta, optimizando el uso de servicios de terceros (para ahorrar costos), gestionar y planear para seguridad, y, a menudo olvidada, la experiencia del usuario.
Combina una falta de las pruebas con una falta de atención a diseño adecuado de un sistema y esto se puede convertir en una pesadilla.
Ves ejemplos de experiencias malas cada día cómo nuestra vidas están permeado con productos de software. ¿Una aplicación con fallos en tu plataforma de streaming? Una otra violación de datos por una tienda o banco? ¿Windows 11 de Microsoft (¡puedo hablar con esto para días!)? Normalmente experimentamos bastantes de estos fallos en nuestra vida diaria.
De hecho, es tan frecuente que a veces creo que la sola manera para evitarlos es para desconectarse de la red por un día. 😉
Nota: Sobre Comida Para Perros Y Dietas
Tal como sigue, para comer tu propia comida del perro generalmente es buen consejo. Estoy rediseñando y reescribiendo la app de Word Hammer que lancé hace una semana para ser más robusto y flexible. Y, en el espíritu de esto, estoy incorporando pruebas unitarias integradas utilizan Jest y PHPUnit, cuando estoy aprendiendo usar en mi entorno de maquina (la maquina de Windows 11 mencioné anteriormente). Más de eso luego.
El contenido de estos artículos son un poco avanzado. Necesito utilizar ayuda de DeepL, per trato utilizar lo menos posible. Todavía lo estoy utilizando alrededor 15-20%, porque necesito un más vocabulario y coloquialismos también. Pere con cada publicación, estoy utilizando DeepL menos y menos. Para esta publicación, lo utilicé menos que nunca.
COMMENTS