¿Alguna vez dejaste un error intencionalmente mientras escribías un código de software?

Prefacio:

Antes de comentar para decirme que estoy equivocado, lea el mensaje completo, ya que me estoy cansando de los comentarios que me dicen cosas que ya se mencionan a continuación.

Si va a decir que su orden de operaciones es definitivo (y todos los demás están equivocados), envíe una imagen del libro de texto con ese OoO en blanco y negro.

Si quiere reír, lea todos los comentarios porque hay muchas diferencias de opinión sobre el tema del orden exacto de operación con multiplicación implícita, operadores unarios y el resto.

Mi respuesta sobre errores intencionales que no se solucionan

****

¿Error, característica o función ambigua de Microsoft?

Microsoft es bien conocido por un error que nunca solucionarán. Aquí está cómo ver el error:

1. Abra Microsoft Excel
2. Escriba la expresión -3 ^ 2 en una celda
3. Presione enter

Como puede ver arriba, Excel me dio lo que la mayoría de los ingenieros llamarían la respuesta correcta, pero la mayoría de los maestros de matemáticas dirían que es la respuesta incorrecta.

OoO: Orden de operaciones
PE-MD-AS, también conocido como BO-DM-AS

Matemáticamente, el “Orden de Operaciones” (OoO, también conocido como PEMDAS o BODMAS) nos dice que la exponenciación viene antes que la resta. 3² es igual a 9, luego aplica la resta.

Incluso si pensamos en esto como negación, en otras palabras, esto es menos uno por 3², la exponenciación sigue siendo lo primero.

¿Por qué Microsoft nunca arreglará este “error” (o es una característica?)

Tendrían que reescribirse miles de hojas de cálculo Excel existentes para dar la respuesta correcta porque dependían de cuál (para algunas personas) es el Orden de Operaciones incorrecto. Si corrigieran el error, miles de programadores tendrían que arreglar esas hojas de cálculo que de repente se romperían.

¿Qué hay de Texas Instruments?

Aquí hay algunos cálculos similares en la calculadora gráfica TI-84 PLUS CE

Como puede ver, la entrada correcta requiere el uso de paréntesis cuando pretendemos que (-3) sea al cuadrado. Esto estaba usando aritmética “unaria” (negación). En la primera línea, puede ver que recibí un error cuando intenté ingresar “restar 3 al cuadrado”.

Ingenieros vs Maestros de Matemáticas vs Programadores de Computadoras

Siempre habrá argumentos sobre cómo se debe calcular esta operación. Busca en Google y encontrarás que muchos ingenieros piensan que debería ser (negación primero) y luego (exponente), pero muchos programadores de computadoras creen que debería ser todo lo contrario.

Visite esta página: http://mathforum.org/library/drm …

donde verá lo que dice uno de los expertos de “Doctor Math” sobre el tema.

Comentarios

Sí, nunca habrá un 100% de acuerdo sobre este tema.
Sí, para algunas personas esto es un error ; para otros es exactamente correcto.
Quizás todos podamos estar de acuerdo en que lo que definitivamente es ambiguo .

Lea todos los puntos de vista en esta respuesta antes de agregar comentarios a continuación. Gracias.

Puede sonar mal aquí, pero sí, varias veces.

Especialmente en mis proyectos independientes. * Inserto * un error complicado intencionalmente y no lo solucionaré hasta que me hayan pagado por completo.

Muchos de mis clientes me piden un código antes de entregarme el efectivo, por lo que en mi defensa generalmente inserto un molesto y complicado error difícil de encontrar (que podría bloquear toda la aplicación o algo similar después de algún uso)

o (este es malo) si el cliente no me pide el código sino el archivo .war, generalmente inserto un servidor que truncaría TODAS las tablas por si acaso es un fraude, todavía puedo quemarle la vida. No diría que nunca he hecho eso en el pasado.

Tuve un cliente que solicitó un portal web, era enorme y me llevó ~ 2 meses hacerlo con otros 2 desarrolladores. Al final, el tipo no pagó y trató de escapar con mi archivo .war.

Conocía el nombre de su compañía y el nombre de dominio, y ahí es donde había implementado el portal, y configuré un cron (semanal) para ese servidor y simplemente se volvería loco cuando todos sus datos (usuarios, publicaciones de blog, historial de tickets, etc.) se había ido, y él conseguiría un equipo y todo se volvería a hacer y mi cron volvería a correr el próximo domingo 🙂 Esto continuó durante un mes y me envió un mensaje de texto “ Gracias a Dios que no te pagué, tú tu software es un pedazo de mierda ”y solo le devolví la sonrisa 🙂

PD: Esto fue respondido originalmente por mí en esta pregunta, pero pensé que la identificación se creó por error, así que eliminé y copié la respuesta aquí.

Sí, solo para agregar a todo esto: está el “Error como característica”. Usted programa algo, pero comete un error en la codificación y decide “oh, eso es bastante bueno, no había pensado en eso” y luego se convierte en una característica.

Soy autor de software para hacer melodías fractales, Tune Smithy. Y algunas de las características de melodía fractal comenzaron como errores. Allí la prueba del programa es si sonaba bien y esa era la única razón para escribirlo, para hacer música que sonara bien. Entonces, si un error conduce a una melodía o ritmo más interesante, bueno, lo convertí en una característica. Podría ser más creativo que si lo hubiera programado de esa manera yo mismo.

Este es un ejemplo de un programa visual en lugar de música:

Ese efecto de costillas bastante atractivo es un error, al menos en el sentido de que no lo esperaba. Cuando agregué transparencia al patrón, solo esperaba láminas transparentes, pero debido a los polígonos utilizados para hacerlo y al diseño de esos polígonos, entonces la curva se convirtió en esta nervadura bastante atractiva.

No hubo ningún resumen de diseño aquí. Solo apuntaba a hacer patrones atractivos. Así que estaba bien con eso y simplemente lo dejé como un “error como característica”. De hecho, me encantó este “error como característica” mucho más interesante de lo que esperaba. Fue un día de letras rojas para mí. Debido a que había logrado la transparencia, esto fue hace algún tiempo, trabajando en Open GL y aprendiendo cómo usarlo, y quería hacerlo pero no había podido hacerlo antes. Y luego obtuve este agradable efecto de nervadura también.

Este es el mismo patrón animado.

día lleno de promesas

nota: es un gif animado. Cuando haces clic en el botón de reproducción, tomará un momento o dos para que ocurra algo, no es necesario que sigas haciendo clic. Solo espere un momento después de hacer clic, y luego se animará.

Luego, continuando con el tema, cosas como esta: es todo lo que normalmente pensarías que es una representación 3D con fallas, pero haciendo patrones atractivos y así, no tengo un resumen de diseño, ni una plantilla. Si hace esto y se ve bien, solo ve con él :). Probablemente ni siquiera hubiera pensado en diseñarlo así, no importa que se vea tan bien como este.

rayos espirales – Película

Muchos ejemplos más aquí: Lissajous 3D Example Patterns

El software es Lissajous 3D

Tune Smithy también tiene algunos errores, así como características que comenzaron como errores, aunque no recuerdo cuáles fueron originalmente, pero hay uno que tiene “error” en el nombre de la canción.

Mi software también tiene muchos errores del tipo ordinario y no estoy haciendo un software de misión crítica para un reactor nuclear o un lanzamiento de cohete. Es casi imposible eliminar los errores por completo, a menos que use un código probablemente correcto. Si lo hace, puede hacerlo, pero es mucho más lento de codificar, y todavía es tan bueno como la especificación, si realiza una especificación incorrecta, aún no hará lo que quiere que haga.

Aún así, eso no está dejando intencionalmente errores. Pero a veces tengo situaciones en las que tengo dos funciones que el usuario podría desear usar juntas, pero no está programado para permitir que esas funciones funcionen juntas o pueden tener consecuencias inesperadas si lo intentas. Muchos programadores simplemente harían imposible probarlos juntos.

Pero dependiendo de la situación, si el intento de mezclarlos puede ser interesante musical o visualmente, puedo permitir que el usuario “rompa el software” como una característica avanzada :). Con una advertencia en la interfaz de usuario que puede tener consecuencias inesperadas, pero posiblemente interesantes para el ritmo / melodía / patrón visual. Así que también es un tipo de error intencional, y también es un tipo de “error como característica”.

Otras veces simplemente no dejo que se usen juntos.

Además, a veces tienes un error que alguien ha informado y aún no has tenido tiempo de solucionarlo. Tengo uno justo ahora que creo que tomará un día o dos de codificación para solucionarlo.

Puedo hacer cosas como esta como programador de operador único que vende mi propio software. Me atrevo a decir que probablemente no podría hacerlo como parte de un equipo, excepto tal vez en algún lugar con un diseño / ética de trabajo inusual.

Cuando alguien informa un error, puedo solucionarlo de inmediato en dos o tres días.

Pero la idea de un “error como característica” es bastante común. Ejemplo: Notch llama a Creepers de Minecraft “un error”

Sorprendido, nadie ha mencionado esto todavía (tal vez me lo perdí).

Si. Muchas veces en realidad. Por lo general, no puedo hablar sobre el trabajo en Quora, pero puedo contar esta historia porque el error y la razón por la que no pudimos eliminarlo desaparecieron hace mucho tiempo.

Soy ingeniero de producto para herramientas de diseño digital. Lo que significa que esencialmente soy un gerente de producto, pero debido a la naturaleza técnica del software, mi atención se centra en los cambios eléctricos y físicos que la herramienta realiza en el circuito dado, no en las métricas de adquisición de clientes.

Una de las cosas que hago es revisar los cambios de I + D que se espera que cambien los resultados de la herramienta y determinar si son aceptables o no. A la mayoría de los ingenieros de I + D no les gusta especialmente esto o no entienden por qué es necesario, porque desde su punto de vista su código es mejor que el código anterior, por lo que deberíamos enviarlo. Pero el software de diseño digital es extremadamente complejo. Existen múltiples capas de algoritmos de análisis y optimización que interactúan entre sí, por lo que mejorar los resultados de uno de hecho puede degradar los resultados finales al hacer que otro trabaje menos. Lo que ha hecho I + D es correcto y funciona, pero aún no podemos activarlo. Esto a veces sucede incluso con correcciones de errores.

En el caso particular en el que estoy pensando, un gerente de I + D que en realidad es un buen amigo, trabajamos para la misma startup antes de que nuestro empleador actual lo adquiriera, encontró lo que parecía un simple error: estaban enrutando (es decir, conectando componentes con pedazos de metal) parte del diseño dos veces. Entonces entraron en otra etapa con el doble de cables que se necesitaban. Entonces lo arregló, sin pasar por el proceso de revisión, justo antes del lanzamiento. Lo que desató el caos en nuestras pruebas: terminamos con muchas más violaciones de las reglas de diseño una vez que las herramientas terminaron con el diseño. Ahora eso apesta, porque si violamos una regla de diseño, en este caso una regla que dice qué tan rápido debe cambiar una señal, el usuario tendrá que ir y arreglarla a mano. Si hay 3 violaciones, está bien, pero si hay 1000, eso es un problema importante porque algún pobre tendrá que trabajar las 24 horas para arreglarlas y cumplir con la fecha límite de fabricación. La gente se enfada cuando esto sucede.

Así que entendimos el problema (phew) y la administración de versiones corren tratando de encontrar el error y lo fijan en el check-in de mi amigo y él está absolutamente convencido de que no hay forma de que su cambio pueda estar equivocado. Entonces, el gerente de lanzamiento me pregunta y hago lo que suelo hacer, que es sentarme y tomar café, mirar fijamente y fragmentos aleatorios de información hasta que algo se me ocurre.

Resulta que había un defecto subyacente en la fijación de la regla de diseño que en realidad tomó muchos años y un cambio en la administración para solucionarlo correctamente. Pero fue más o menos, funcionaba bien siempre y cuando le dieras estimaciones de capacidad masivamente pesimistas. Que es lo que obtienes cuando tienes el doble de cables de los que debías tener (más conductores activos significan más capacitancia, si recuerdas).

Entonces volvemos a poner el error. Los cables adicionales se retiraron un poco más tarde, por lo que no causaron ningún daño, pero sí hicieron que algo más funcionara correctamente. En la próxima versión, lo reemplazamos con un margen numérico, que es mucho más simple y en realidad muestra la intención correctamente. Luego, mucho más tarde, se encontró y solucionó el problema subyacente.

Si. El término para esto es ‘deuda técnica’. Cualquier producto en el mundo empresarial surge a través de un acto de equilibrio entre recursos, tiempo y calidad. En el caso del software, el desarrollador es el recurso. Si el software necesita ser lanzado en una semana, por ejemplo, ese es tu momento. Tanto el recurso como el tiempo asignado limitan directamente la mejor calidad posible posible.

La mayoría de las veces, se le pedirá a un desarrollador que codifique algo en una fracción del tiempo que realmente debería asignarse. El resultado de esto es que el desarrollador se ve obligado a ignorar las mejores prácticas y cortar esquinas (leer: escribir código con errores) para llevar el software a un estado liberable, y luego esos errores se corrigen más tarde en parches, correcciones de errores o incluso nuevos y mejorados caracteristicas.

Si me he visto obligado a hacer esto, comentaré el código de error para que sea obvio para cualquiera que lo lea más tarde (especialmente para mí, tengo una memoria horrible) que hay un error conocido. Esto ahorra el tiempo de buscar errores más tarde, al tiempo que es mucho más rápido inicialmente que escribir código sin el error.

Además, muy a menudo, incluso esos errores conocidos nunca se solucionan realmente: si ningún usuario se queja o incluso sabe que existe el error, un desarrollador nunca tendrá la oportunidad de volver y aplicar las correcciones, porque la compañía tiene formas más lucrativas de usar el tiempo del desarrollador. Cada recurso tiene lo que se conoce en economía como un costo de oportunidad.

¡Oh sí! Y también fue por el bien de la compañía (como pronto descubrirías).

De acuerdo, no fui yo, pero me gustaría compartir esta historia corta que leí en el libro Game Coding Complete [1] de todos modos.

Entonces, el coautor David, también conocido como Rez, estaba trabajando en Planet Moon Game Studio. Rez, junto con su equipo, estaba desarrollando un juego llamado Brain Quest para Nintendo DS.

Ahora, para aquellos que no saben, la Nintendo DS tenía solo 4 MB de RAM (sí, MB). Esto hizo que la gestión de la memoria fuera realmente crucial.

Hacia el final del proyecto, el equipo de Rez estaba corriendo hasta el límite de 4 MB. Cuando llegaron los recursos de producción final y se agregaron a la fuente del juego, ¡ simplemente cruzaron ese límite de 4 MB!

En este punto, uno de los ingenieros del equipo sonrió, se acercó a su computadora, abrió el archivo main.cpp y comentó la siguiente línea.

seguro de carbón sin firmar [10240];

(esta línea simplemente asigna 10240 bytes en la memoria, evitando así que otro código use esa memoria)

Un seguro de memoria!

Entonces, sí, este tipo escribió intencionalmente el código ‘buggy’ en el juego, para obligar a los otros ingenieros a optimizar su código.

Ahora, ¿no era ese genio?

Notas al pie

[1] Codificación de juego completa, cuarta edición: Mike McShaffry, David Graham: 9781133776574: Amazon.com: Libros

Algo así como. Diseñé microchips en Verilog y, por lo general, tenía un equipo de 2 a 5 ingenieros de verificación que se aseguraban de no estropear nada. Esta fue una buena decisión, porque no soy un buen programador y cometí errores como si obtuviera un cono de helado para cada uno.

Entonces, en el proceso de depuración de un error que había cometido, descubrí otro (no relacionado con el error que había encontrado mi equipo de verificación). Pero en lugar de arreglarlo en ese momento, comenté al lado del código defectuoso en TODAS LAS MAYÚSCULAS, diciendo “¡ESTO ES INCORRECTO Y DEBE CAMBIARSE!” Y en realidad coloqué lo que pensé que sería el código correcto, en los comentarios . ¿Por qué?

Porque quería asegurarme de que el equipo de verificación detectó el error. Necesitaban preparar una simulación de prueba que fallara mi diseño por esta razón específica; si no podían, eso significaba que faltaba algo en su entorno de verificación, y me gustaría investigar eso con ellos.

Pero, efectivamente, un par de semanas después abrieron un nuevo informe de error y tan pronto como miré la simulación supe que lo habían encontrado. Puse el código comentado en su lugar, y fue la solución más rápida en mi carrera en IBM. 🙂

Lo hice una vez, porque era necesario enseñarle una lección al líder del equipo.

El líder del equipo que literalmente no hace nada, se burla de las personas, habla mierda, pasa el rato con el gerente durante más de tres horas al día para convertirse en su favorito. Miente obsesivamente sobre todo y cualquier cosa, hablar basura, beber alcohol y una gran cantidad de otros vicios … Solo hay una cosa que sabe hacer: “HABLAR” Era un vendedor en una carrera anterior y de alguna manera logró entrar en TI. Haríamos la mayor parte del trabajo y él hablaría sobre cómo tomar crédito.

Un día perdí la paciencia y no le grité, no hice mucho escándalo al respecto. Nos entregaron el proceso de cargar datos en el software. El proceso requiere una serie de 30 pasos, que se realizarán lentamente. Uno de los pasos requiere el uso de una macro VBA – en Excel para eliminar duplicados del catálogo. Modifiqué una línea de código – Eso no fue un error – técnicamente hablando – Todo parecía funcionar – No se plantearon problemas, NO HAY BANDERAS. Los datos se cargaron en el catálogo, pero se rellenaron con duplicados. La mejor parte fue que nadie verificó los datos. Asumieron que todo estaba bien.

El proceso continuó durante un mes. Luego, alguien de algún equipo de algún lugar de la tierra en ese enorme MNC informó de un error: encontró 100 duplicados en el catálogo, es decir, esa es la cantidad de veces que se ha cargado contenido desde entonces. Durante los siguientes tres meses: se culpó una y otra vez al líder del equipo. Buscó por todas partes lo que salió mal. Me pidió a mí y a otros miembros del equipo que lo arreglaran, pero le dije que no tenía idea de lo que estaba pasando. Corrió hacia otros equipos para encontrar el error. Bueno, dado que él nunca echaría un vistazo al código, nadie tuvo tiempo de pasar de cinco a seis horas para revisar todo el proceso paso a paso para rastrear la razón de los errores.

Así que esto continuó durante seis meses y la gente se volvió loca por este error que nunca se solucionó. Se desesperó, e intentó todo tipo de tácticas de evasión, comenzó a negociar con el gerente. Finalmente, me compadecí de él después de los tres meses y cambié esa línea de código a la original y todo comenzó a funcionar sin duplicados.

Que mis amigos son la importancia de una línea de código. Realmente no tiene que ser un error. Podría haber un ligero cambio en una variable, un archivo o una clase o un método, un pequeño cambio puede arruinar todo el software sin generar un error o un mensaje de error en cualquier lugar.

Es por eso que a los ingenieros de software se les paga tanto, porque ponen mucho esfuerzo en el código. Desafortunadamente, tienen que recordar cada línea de código, cada método, cada clase, matriz en el proyecto. No tienen que memorizarlo, pero deben ser conscientes de la lógica o deben tener una imagen mental de todo el código.

La moraleja es que hay una gran posibilidad de dejar un error de tal manera que, nadie puede resolverlo, podrían leer todo el código pero no pueden descubrirlo.

Esa es la triste verdad.

Personalmente, no, por supuesto que no, si puedo solucionarlo fácilmente.

Organizacionalmente, todo el tiempo, como toda organización de ingeniería lo hace todo el tiempo.

Verá, la mayoría de los proyectos tienen un rastreador de problemas. Enumera los errores informados, las solicitudes de funciones, los hitos, etc. Se prioriza todo. En un mundo ideal, ¿no sería bueno corregir todos los errores conocidos antes del próximo lanzamiento? En realidad no. Ese sería un enfoque ingenuo con un resultado terrible. De hecho, es muy probable que la “próxima versión” simplemente nunca ocurra.

Entonces, en la práctica, usted decide qué es lo suficientemente importante como para arreglarlo, qué características puede incluir, y luego lo sigue mientras mantiene el cronograma.

Aquí hay algo: casi todos los rastreadores de problemas que he visto para un proyecto exitoso crecen con el tiempo, en cada categoría, incluidos los errores. Si un proyecto no tiene errores conocidos de ningún tipo en la última versión, es probable que sea un pequeño proyecto personal.

(Y sí, hay excepciones como TeX y METAFONT, y el equilibrio puede inclinarse fuertemente hacia las soluciones, como en OpenBSD).

Así que este incidente tuvo lugar hace unos días. Había empezado a codificar hace un par de años solo como un hobby, sabía lo básico que era todo.

En nuestra universidad, nuestros alumnos de último año habían organizado un taller en el que enseñaban Java desde cero, era domingo y no tenía nada más que hacer, así que decidí asistir en lugar de perder mi tiempo jugando videojuegos. Yo, con un par de amigos, entré en la sala de conferencias y nos sentamos. Después de algún tiempo llegaron los mayores. En nuestra universidad necesitamos dirigirnos a ellos como Señor y Señora. No estaba prestando mucha atención, pero de repente vi a una de nuestras personas mayores (Señora) y me quedé estupefacta, tal era su belleza. Después de estar un poco más atento, me di cuenta de que estaba explicando los códigos de una manera tan simple y sencilla que me sorprendió.

Cuando se terminó la parte de enseñanza, se nos dio un problema que resolver. Fue fácil, no me llevó mucho tiempo y volví a posponer las cosas. Cuando la volví a ver, esta vez, explicando los errores a los estudiantes individualmente, no sé qué me pasó, pero estaba decidido a hablar con ella al menos una vez, así que destruí mi código perfectamente perfecto y creé algunos 5– 6 errores estúpidos en el mismo.

Cuando pasaba a mi lado, la llamé con tanto entusiasmo, incluso ella se sorprendió un poco, pero luego sonrió un poco al ver mi entusiasmo y comenzó a explicarme los errores que cometí y corrigió todos los errores en uno ir. Sus explicaciones fueron muy educadas y significativas, algo que rara vez veo.

La clase terminó después de eso, y aún no la he visto, pero créanme, en los dos meses de mi vida universitaria, esta fue una de las experiencias más emocionantes que he tenido.

Si. Esto fue hace 35 años y fui consultor en Reader’s Digest en el Reino Unido. Me encargaron escribir algunas rutinas de ensamblador para extraer datos significativos de su ‘base de datos’. En realidad no era una base de datos, sino un archivo enorme que abarcaba múltiples cintas. Tuve que extraer el apellido de ‘Mr O md’ – O y no ‘md’. Y también date cuenta de que O no es un inicial ni un honorífico. Las direcciones fueron peores, especialmente las del Reino Unido que no tienen rima ni razón. Le pregunté al analista dónde debería poner los mensajes de error. Dijo que no había necesidad. La entrada de datos siempre pasa a través de filtros. Pero si los datos eran incorrectos, es probable que mi programa de ensamblaje se bloquee y sea difícil de depurar. Así que inserté una instrucción ‘Ejecutar’ para ejecutar ‘Ejecutar’. Eso causó una excepción Ejecutar. Muy raramente ocurren como un error. Mientras tanto, apunté algunos registros a los datos incorrectos, explicaciones, etc. Por supuesto que siguió sucediendo. Sus datos fueron un desastre. Cada registro tiene un nombre. De Verdad? ¡No!

En el código fuente nombré al analista, mi problema, su respuesta, mi petición, su respuesta escrita y lo que cada registro significaba cuando el programa se abstuvo. (Fin anormal)

El programa fue modificado posteriormente para incorporar mensajes de error. Un buen trabajo realmente porque tenían miles de ‘imposibilidades’ en este archivo secuencial de 20 millones de registros.

¿Hice mal? Todavía no puedo decidir.

Como programador de mainframe en las décadas de 1980 y 1990, fue útil iniciar la depuración creando una pequeña instrucción de ensamblador para dividir por cero o bifurcar a media palabra de ceros.

Al hacerlo, al menos en los mainframes de IBM, se produjo un volcado formateado de la memoria del proceso. Luego entramos y podremos ver dónde se bloqueó el programa, qué valores estaban en los registros, mirar las áreas de almacenamiento del programa, ver qué registros se cargaron, etc.

Una razón por la que tenía sentido deshacerse tan pronto como sucedió algo “extraño” es que una vez que el programa entró en lugares “inesperados”, podrían suceder cosas malas. Por ejemplo, si estaba recorriendo una lista, digamos de 100 registros, y la lista terminaba antes del 100º registro, tal vez estaba calculando una suma y un promedio … pero si esperaba 100 registros, su promedio estaría apagado y nadie podría ¡Lo he recogido! Además, una vez que el programa se ramificó en ubicaciones inesperadas, la memoria en ejecución podría corromperse y el proceso podría volcarse en algún lugar no a propósito, pero debido a que una ubicación de memoria era “0” y se dividió por cero … podría pasar una hora recompilando y probando cosas solo para determinar que la lista fue menor de lo esperado. Así que tirar cuando supiste que algo andaba mal tenía más sentido.

Este tipo de cosas era importante antes de los sistemas operativos en tiempo real, cuando la mayor parte de la entrada era de tarjetas perforadas, y la salida era a través de impresoras de línea. Una vez que pudimos trabajar en tiempo real, en pantallas, por ejemplo, este tipo de creación de volcados se hizo menos necesario.

Una vez que comenzamos a usar el lenguaje de programación C, los programadores pueden haber usado técnicas similares de generación de volcados. Tenía que crear una lista de errores conocidos y hacer que todos mis programadores los definieran en una biblioteca de mensajes, de modo que a) los errores pudieran documentarse (en cualquier idioma que se usara localmente) yb) para que no se produjeran volcados. en lugares inesperados!

Por supuesto, todavía había lugares donde los vertederos ocurrían inesperadamente, y esto se debía principalmente a que los programadores nunca esperaban que sucedieran cosas como “no llegaron a todos los elementos de mi lista”. Yo … alentaría (insisto) que cualquier ciclo iterativo tuviera pruebas de condiciones de índice fuera de límites inusuales, y que generarían uno de los mensajes estándar … o el programador necesitaría agregar otro mensaje a la biblioteca.

-L

Anónimo porque el error aún existe y su sistema aún es vulnerable.

Trabajé con una empresa en su nuevo sistema de distribución. No te diré lo que distribuyeron, porque están entre los jugadores más grandes en su campo.

Aquí está el error de seguridad crucial que tenían: almacenaron un token git en el repositorio.

Ahora, esto puede no parecer un gran problema, pero este token tenía derechos completos de extracción y derechos de inserción también. Como resultado, incluso los empleados que abandonaron la organización o fueron despedidos, aún podrían usar el token para tener acceso completo a todos sus repositorios de código.

¿Por qué no lo arreglamos? Nosotros tratamos. Intentamos decirle a la gerencia que este es un problema crítico de seguridad, pero en cambio estaban demasiado centrados en las características. Así que ahora, todo lo que uno necesita es ese token para poder borrar por completo sus repositorios de código de manera irreversible. Pero bueno, esa característica necesita salir primero, ¿verdad? ¿Derecho?

Lo hice hace unos años cuando era un emprendedor tecnológico . Teníamos 18 organizaciones educativas de alto valor como nuestros clientes. De los 18, 2 fueron los creadores del problema y utilizan para retrasar el pago de las facturas recaudadas en 60 o 90 días, aunque el contrato dice que solo se permiten 30 días para los pagos. Estos 2 estaban en la posición de que las finanzas no eran un problema, pero las personas sí lo eran.

En un momento en el que estaba en el Centro de Desarrollo, el equipo de finanzas decía que casi £ 950K + estuvieron pendientes durante 90 días de esos dos. Entonces, la mente cruel cautivada se activó para entregar el proyecto y recuperar el pago.

Dejó intencionalmente 15 errores importantes que estropearán gravemente a su fuerza laboral. Cuando todos actualizaron su aplicación, el error funcionó perfectamente. Obtuve numerosos boletos de soporte y no había nadie en mi oficina para asistir a esos boletos, excepto yo, ya que les pedí que fueran a la gira de 3 días. Como los boletos no se actualizaban, las cosas empeoraron al paralizar todas las operaciones. El presidente de esas universidades me llamó directamente amenazando con cancelar el acuerdo considerando el incumplimiento del acuerdo.

Respondí fríamente diciendo: “Señor, los pagos se retrasan profundamente 90 días en un promedio que bloquea nuestras operaciones. Pero esos tickets de soporte no se respondieron solo durante las últimas 24 horas. ¡Solo quería explicar lo difícil que es manejar sin plomo! ”

Lo entendieron, y en los siguientes minutos recibí una llamada de su departamento de Finanzas diciendo que habían enviado por correo electrónico la copia de referencia de pago escaneada para todas las facturas pendientes. Ese mes fue un gran salto en toda nuestra historia financiera en términos de volumen.

Personalmente fui al Centro de desarrollo y eliminé esos errores intencionales y lancé la próxima actualización en pocas horas. Que yo sepa, siguen siendo los clientes de mi organización fundadora.

–

¡Ni tú ni yo somos John Keats y Shakespeare! Así que evite las críticas sobre el uso del Idioma, si leyó mi respuesta y la entendió, vote por ella, de lo contrario, Gracias y Perdón por pasar su tiempo leyendo esta respuesta.
Kokula Krishna Hari K

Si mucho.

Eso puede sonar extraño para el oído inexperto, pero en realidad es muy común.

No hace mucho trabajé para uno de los grandes supermercados del Reino Unido. Si eres inglés, es muy probable que hayas comprado con ellos. Es posible que incluso haya experimentado uno de mis errores.

Estaba con el lado de I + D, trabajando en un nuevo producto móvil. Parte de eso fue que habíamos decidido que para la puesta en marcha con un pequeño número de clientes seleccionados (en gran parte internos) solo admitiríamos iOS, pero si funcionaba en Android sería genial.

Trabajé en una función que funcionaba en iOS y Android, pero tenía unos pocos píxeles en Android. Mencioné durante la demostración con el propietario del producto que estaba casi allí en Android, por lo que cuando llegamos a apoyarlo solo tendríamos que jugar con la interfaz de usuario (y debería tener un desarrollador de interfaz de usuario en ese punto).

Esto salió mal y me pidieron que lo hiciera perfecto en píxeles en las dos plataformas. Me defendí, pero perdí y pasé 7 días haciendo que se viera bien.

Mencioné cuánto costó solucionar un error que pocas personas notarán. Sin reacción. Mi jefe dijo lo mismo en el lenguaje que entendieron: número de pollos vendidos para pagar esos pocos píxeles.

Unas semanas después trabajé en una función diferente. Una vez más, terminé con algo que era perfecto en píxeles para los diseños en iOS, pero no en Android. Me preguntaron cuánto costaría arreglarlo en Android. Esta vez, el propietario del producto decidió dejar el error hasta que necesitáramos admitir Android (e incluso entonces, ya que tenemos la intención de tener una aplicación, tal vez no la solucionemos).

Saber cuándo corregir errores es una señal de que el equipo está maduro. Los jóvenes no siempre saben cuándo son intrusos, los equipos “adolescentes” intentan eliminar todos los errores, los equipos maduros saben cuándo aceptarlos.

Pero, ¿qué es un error ?

Según recuerdo, la política de IBM era que todo lo que necesitaba corrección se consideraba un “error”. ¡Esto se aplica incluso a simples errores tipográficos en los comentarios! Y más bien sospecho que esto es / era algo así como un enfoque estándar de la industria. (No puedo evitar preguntarme si eso fue en parte un dispositivo para aumentar la aparente eficiencia del proceso de control de calidad).

Cuando hay un amplio espectro de lo que se considera un error, entonces, ciertamente, un grado de discreción es obligatorio al decidir si corregir un error … incluso los peores que los comentarios mal escritos.

Recuerde que hay costos asociados con cualquier cambio más allá del esfuerzo del cambio en sí: las cosas deben ser reconstruidas y probadas. Además, simplemente ejecutar las pruebas de unidad / integración existentes no garantiza que todo saldrá bien. Pueden surgir errores de una naturaleza completamente nueva. De hecho, a medida que el código y las aplicaciones envejecen, las cosas pueden llegar a un punto en el que corregir los errores existentes simplemente hace que aparezcan tantos o más nuevos. En ese punto … ¡reescribe / rediseña el tiempo!

Si.

Apple me solicitó que dejara un error del kernel que permitiría una escalada de privilegios locales mediante la sobrescritura de una región de la memoria del kernel. Tienes que superar KASLR ( aleatorización del diseño del espacio de direcciones del núcleo ), un tipo de seguridad a través de la oscuridad, para hacer el acto, pero es factible.

Sin ese error en su lugar, Final Cut Pro dejó de funcionar. Final Cut Pro era una aplicación “no debe romperse”, por lo que el error permaneció.

Parece que el error todavía está allí en la versión de escritorio del sistema operativo, a partir de este escrito.

¿Un insecto? Supongo que podría ser referido como un error.

Trabajé como administrador en un proveedor de servicios de internet. Teníamos la necesidad de sincronizar las cuentas de usuario en varios servidores, pero no queríamos la sobrecarga asociada con ldap u otros sistemas de red, o los riesgos de seguridad. Mi solución era bastante simple y no cargaba los sistemas que ya estaban bajo carga. Cada 5 minutos, consultaba un servidor sql, era el almacenamiento principal de nuestras credenciales maestras. Lo haría desde cada servidor y volvería a crear la lista de acceso completa en función de esa consulta. Lo había escrito en C, por lo que el tiempo del proceso fue rápido, menos de un segundo rápido.

Esta compañía en particular era bastante escoria. Si bien los trabajadores allí eran muy leales y trabajadores, la propiedad carecía de escrúpulos. Sabiendo que se venderían tan pronto como pudieran, dejándonos a todos en la calle, tenía un plan. Codifiqué mis credenciales de usuario en el programa de sincronización. Si fuera eliminado o mi cuenta modificada, mi cuenta se volvería a crear con acceso de nivel raíz. Tiempos divertidos. Ah, y vendieron sin tener en cuenta a las personas que hicieron que la empresa fuera lo suficientemente exitosa y valiosa como para obtener ganancias.

Nunca utilicé la cuenta para nada malicioso, pero me aseguré de que mi programa ejecutara su propósito con éxito. Lo hizo. Puedo imaginar su frustración, borrando mi cuenta, solo para tener el acceso recreado un momento después. Tecnológicamente eran bebés, supongo que les costó un poco desmantelarlos.

Si. En una unidad Siemens Micromaster. Y es una razón común por qué.

El código tiene un error de larga data, donde no cumplió con una especificación publicada.

Se suponía que debía enviar tres comandos a través del enlace de comando en serie para apagar el dispositivo. Uno inmediatamente, otro lo más rápido posible, y el apagado controlado más normal.

Uno de ellos fue implementado con el código de comando incorrecto.

Un cliente importante había necesitado usar esta función en su fábrica y había escrito su software de control para usar este código de comando ‘incorrecto’.

Si solucioné el error, tendrían que reescribir y volver a implementar sus sistemas de automatización de fábrica. Una tarea enorme, con una gran pérdida de ingresos para ellos.

Esto se conoce como una interfaz publicada. El código externo dependía de la interfaz que teníamos, a pesar de estar roto.

Elegimos dejar el error, pero lo documentamos en el manual como una desviación conocida de la especificación.