Do you have time bombs in your system?
Do you have time bombs in your system?
"If debugging is the process of removing bugs, then programming must be the process of introducing them."
Edsger Dijkstra
You can read this article in Spanish more down below in this same publish. (Puedes leer este artículo en espa?ol más abajo en esta misma publicación)
The development environment is the substantial base on which the construction of a software development project rests.
In some facilities, the creation of an adequate environment on the development machine that offers programmers working libraries with consistent, abundant data like the data that exists in the production environment is rejected. Although for security reasons the data must be "tokenized", it is essential to supply data in a massive way that allows the programmer to create the largest possible number of scenarios and conditions in their unit and integral tests.
In my opinion, the success of a software development project depends 60% on the quality of the tests that are carried out.
For reasons of cost, in some facilities they do not hire QA experts to carry out the tests and place the generation of use cases, the filling of test forms and the certification of their own creations on the shoulders of the programmers. This is not good practice. The programmers’ mind is already conditioned by the data it is familiar with, the test paths that its logic have defined, and the results of the tests that they has already performed, unwittingly skipping corrective actions that would lead to preventing the generation of issues once the software is installed.
When software has not been thoroughly tested before it is installed in production, a dangerous and irreversible mechanism of “antialgic movements” can be generated. This mechanism is started when errors are corrected in production “while” the causes are reviewed, and the update is installed. Thus, weeks, and perhaps months pass with this "temporary" correction that no one has had time to review, nor correct from its true cause. I know an institution that activated this mechanism without realizing it and in the end had to close the business.
I will illustrate with an example what an "antalgic movement" is. If, for example, our right wrist hurts when we move it, then to avoid pain, we move the wrist less and increase the movement of the forearm. This overload of work on the forearm causes the elbow to begin to hurt. We then proceed to use the arm more frequently until the shoulder begins to hurt, then the neck and without realizing it, the pain now covers the entire right side. Successively and progressively, a total paralysis of the system occurred. An antalgic movement is a mechanism that seeks to relieve muscle pain without correcting the root cause of the problem.
When I have reviewed these progressive software failures, I have been able to determine that omitting the preparation of an adequate test plan, with expert professionals and with optimal test data, in many cases caused the involuntary generation of a silent "time bomb" that triggered serious consequences for business continuity when it finally detonates.
Those facilities that do have QA staff are also negatively affected by an inadequate test environment on the development machine. The productivity of QA staff is drastically reduced by being busy repeatedly and successively testing software that could not be well tested in development. Being able to also generate collateral damage to other projects due to the reduced availability of the resources used in tests and retests.
My professional experience leads me to conclude that in a successful software development project, it is essential that developers and QA staff have adequate test environments and a thorough list of test scenarios. Users also play a fundamental role in detecting errors and should actively participate in all project monitoring phases, emphasizing advising on "mirror scenarios" that reflect the daily operational dynamics of the business.
Developing in Rpgle on an Ibm-i platform presents very interesting challenges in terms of detecting hidden errors.
?In the next article I will write about this topic.
Until Next Time!
Visit my blog. https://www.iseriesvenezuela.com/
领英推荐
___
?Tienes Bombas de Tiempo en tu Sistema?
?"Si la depuración es el proceso de eliminar errores, entonces la programación debe ser el proceso de introducirlos."
Edsger Dijkstra
El ambiente de desarrollo es la base sustancial sobre la cual descansa la construcción de un proyecto de desarrollo de software.
En algunas instalaciones se desestima la creación de un ambiente adecuado en la máquina de desarrollo que ofrezca a los programadores unas bibliotecas de trabajo con una data consistente, abundante y similar a la data que existe en el ambiente de producción. Aunque por razones de seguridad la data deba “tokenizarse”, es esencial suministrar data en forma masiva que permita al programador crear la mayor cantidad de escenarios y condiciones posibles en sus pruebas unitarias e integrales.
En mi criterio, el éxito de un proyecto de desarrollo de software depende en un 60% de la calidad de las pruebas que sean realizadas.
Por razones de costo, en algunas instalaciones prescinden de contratar expertos de QA que realicen las pruebas y colocan sobre los hombros del programador la generación de casos de uso, el llenado de formato de pruebas y la certificación de sus propias creaciones. Esta no es una buena práctica. La mente del programador ya está condicionada por la data con la que está familiarizado, los caminos de prueba que su lógica ha definido y los resultados de las pruebas que ya ha realizado, omitiendo involuntariamente las acciones correctivas que conducirían a prevenir la generación de incidencias una vez instalado el software.
Cuando un software no ha sido probado de manera exhaustiva antes de instalarlo en producción, puede generarse un mecanismo peligroso e irreversible de “movimientos antiálgicos”. Este mecanismo se inicia cuando se corrigen errores en producción “mientras” se revisan las causas y se instala la actualización. Así pasan semanas y quizás meses con esta corrección “temporal” que nadie ha tenido tiempo de revisar, ni corregir desde su verdadera causa. Conozco una institución que activó este mecanismo sin darse cuenta y al final tuvo que cerrar el negocio.
Voy a ilustrar con un ejemplo lo que es un “movimiento antiálgico”. Si por ejemplo, nos duele la mu?eca derecha al moverla, entonces para evitar el dolor, movemos menos la mu?eca y aumentamos el movimiento del antebrazo. Esta sobrecarga de trabajo en el antebrazo hace que el codo comience a doler. Procedemos entonces a utilizar con mayor frecuencia el brazo hasta que comienza a doler el hombro, luego el cuello y sin darnos cuenta, la molestia ahora abarca todo el lado derecho. De manera sucesiva y progresiva se produjo una parálisis total del sistema. Un movimiento antiálgico es un mecanismo que persigue aplacar el dolor muscular sin corregir la causa raíz del problema.
Cuando he revisado estas fallas progresivas del software he podido determinar que omitir la elaboración de un plan de pruebas adecuado, con profesionales expertos y con una data de prueba optima, en muchos casos ocasionó la generación involuntaria de una silenciosa “bomba de tiempo” que desencadenó graves consecuencias para la continuidad del negocio cuando esta finalmente detona.
Aquellas instalaciones que sí cuentan con personal de QA también resultan afectadas negativamente por un ambiente de prueba inadecuado en la máquina de desarrollo. La productividad del personal de QA queda drásticamente reducida al ocuparse en probar repetida y sucesivamente el software que no pudo ser bien probado en desarrollo. Pudiéndose además generar un da?o colateral hacia otros proyectos debido a la disponibilidad reducida de los recursos ocupados en pruebas y repruebas.
Mi experiencia profesional me lleva a concluir que, en un proyecto de desarrollo de software exitoso, es fundamental que los desarrolladores y el personal de QA cuenten con ambientes de prueba adecuados y una lista minuciosa de escenarios de prueba. Los usuarios también juegan un papel fundamental para la detección de errores y deberían participar activamente en todas las fases de seguimiento del proyecto, haciendo énfasis en asesorar sobre “escenarios espejo” que reflejen la dinámica operativa diaria del negocio.
Desarrollar en Rpgle en una plataforma Ibm-i presenta retos muy interesantes en cuanto a la detección de errores ocultos. En la próxima entrega escribiré acerca de este tópico.
??Hasta la próxima!
Visita mi blog. https://www.iseriesvenezuela.com/