¿Por qué el software es tan difícil de escribir?

Answer 1

Porque tienes que pensar en todas las posibilidades y planificarlas en tu código.

Si tiene un código que falla cuando alguien ingresa los datos incorrectos, ¿quién tiene la culpa? Le digo al programador, ya que deberían haber atrapado los datos no válidos e informar el error al usuario, con instrucciones sobre cómo formatear los datos correctamente.

En los días de DOS, había alrededor de 40 funciones del sistema operativo que hacían de todo, desde directorios, hasta archivos abiertos y cerrados, y funciones de lectura / escritura. Su programa realizó toda la manipulación de la pantalla, y usted tuvo que aprender a generar información de visualización para todas las tarjetas de video posibles, mono y color con diferentes resoluciones. Incluso con esta complejidad, era algo que muchos programadores podían dominar.

Cuando se lanzó la primera versión de Windows, hubo más de 1100 llamadas API principales (en comparación con 40 en DOS) y cada una de estas llamadas tenía muchos parámetros para hacer modificaciones particulares a la función. Windows asumió el papel de ser la capa de adaptación entre el código de la aplicación y la realidad (pantalla, teclado, mouse, procesador, impresora, memoria, etc.) y le pide a Windows que haga algo y lo hace lo mejor que puede, en función de la carga controladores en la configuración del sistema.

Otra capa de complejidad llegó cuando las redes evolucionaron a “normal” ya que en muchos casos, una aplicación en red tiene que ser mucho más inteligente que una aplicación sin red. Debe verificar para saber que es el único que trabaja en un archivo, o bloquear la parte del archivo que está cambiando. Debe poder advertir al usuario o evitar una condición de bloqueo de archivo cuando algo que necesita está siendo utilizado por otro. Si abre un documento que otra persona abre, MS Word dice que el documento está abierto y bloqueado por otro usuario, y generalmente le da el nombre de usuario. También le da la opción de abrir una copia de solo lectura, que puede guardar en otro lugar. Esta es una implementación limpia. Una implementación deficiente permitiría que muchos abrieran el documento y sobrescribieran el trabajo del otro sin previo aviso.

No tengo idea de cuántas llamadas API tiene Windows 10, pero diría con seguridad que hay al menos 50-60,000 llamadas API principales, además de interfaces externas para otras aplicaciones como Direct-X y otras. Windows es tan complejo que hoy en día, hay expertos en compañías más grandes que se especializan en aspectos particulares de la codificación de Windows. Los gráficos, la base de datos, el almacenamiento, la VM, etc. son todas especializaciones que las empresas más grandes a menudo tienen uno o dos especialistas en el personal. Esto se debe a que el campo es tan amplio y cambia rápidamente que una persona no puede mantenerse al día sobre las novedades, lo obsoleto y lo que está a la vuelta de la esquina de todo.

Answer 2

El software de computadora requiere dedicación para hacer las cosas de la manera correcta. Si el software es de mala calidad e incompetente, se mostrará de inmediato. El programador debe reconocer estas ideas:

o El software debe estar diseñado para cumplir con los requisitos, lo que significa que tiene que hacer lo que se le ha ordenado hacer.

o El software debe tener una complejidad mínima, con el menor número de casos especiales posible. Cada caso especial puede aumentar la complejidad por el cuadrado (al menos) del número de tales cosas.

o El software se parece más a un lenguaje que a una máquina. Es una forma de comunicación: con la computadora, con el usuario, con el próximo programador que maneja el código y con uno mismo cuando lo recupere nuevamente en 6 meses.

o El software debe tener abstracciones viables que resistan el paso del tiempo. Pocos programadores pueden manejar las abstracciones muy bien. Muchos, si no la mayoría, son mentiras. El paradigma OOP se presta a las abstracciones de mierda.

o El software debe reconocer el ciclo de vida del desarrollo. Tiene que cumplir con los requisitos, ser comprobable y ser mantenible.

o El software no debe crear efectos secundarios.

o Las cosas simples deben ser simples.

Algunas ideas relacionadas:

o Las grandes corporaciones pueden generar malas abstracciones. Un ejemplo es “Sincronizar” en Apple. Facebook es otro hogar de malas abstracciones. Ejemplo: “Muro”. Una abstracción nunca debe ser una excusa para engañar al usuario, o dejar espacio para que una operación de vellón se use más adelante.

o Debe poder escribir bien en inglés ordinario. El software tiene más que ver con la comunicación que con la computación. La documentación de su código debe estar en los comentarios, no en un archivo externo. Debe estar bien escrito.

o La mayoría del software no es la tecnología en sí, sino el uso de la tecnología. La mayoría de las startups de Silicon Valley no son realmente compañías tecnológicas

o El software de codificación a veces se ve como un trabajo degradante. El término “código de eslinga” refleja eso. Entonces es “código mono”. ¿Por qué? Los programadores a menudo se centran en problemas estrechos, con poca consideración por el panorama general.

o El software es muy difícil de escribir bien. La diferencia entre los programadores más productivos y los menos productivos puede ser 100: 1. Pero las escalas salariales no reflejan eso.

o Como líder de software, asigné un trabajo a un nuevo programador. Escribió 20 páginas de basura que no tenían posibilidades de funcionar. Lo asigné a un programador experimentado que escribió una página de código que funcionó bien.

o Como usuario, algún software web preguntó por mi condado, al cual ingresé. Luego dijo “Error, debes ingresar a la parte norte o sur de tu país”. El programador usó el controlador de excepciones, probablemente en Java, que me mintió. Dejé de comprar cualquier cosa en ese sitio.

o Me hice cargo de un código escrito por un PHD que no tenía idea de cómo codificar. Tenía cientos de goto’s (saltos incondicionales en el código de ensamblaje). No tenía idea de cómo lidiar con las abstracciones. El revoltijo de Goto fue un síntoma de eso.

Editar

El código de software también es un motor computacional. Se entenderá bien un motor de gas o diesel: sus límites de rpm, curva de torque, intervalos de mantenimiento, características de emisiones, salida de calor y mucho más.

El código debe entenderse igual de bien. La mayoría de sus propiedades son matemáticas, pero también tiene propiedades físicas. ¿Cuánto calor genera cuando se ejecuta en un procesador x86? ¿Qué puede hacerle a un dispositivo que controla? ¿Puedes ejecutar este código en una GPU, en una computadora analógica o cuántica?

¿Qué compensaciones se aplican al código? ¿Se puede cambiar la complejidad por la mantenibilidad? ¿Velocidad computacional contra precisión? ¿Quieres una versión simple pero irrompible para problemas fáciles? Quizás pueda deshabilitar versiones complejas pero permitir que se ejecute la versión simple.

¿Se puede reemplazar el código con COTS (comercial fuera de la plataforma)? ¿Qué alternativa de diseño se consideraron? Cuando se actualice el código, ¿tendrán sentido las alternativas?

Considere sus propiedades matemáticas. Esas propiedades predecirán su comportamiento bajo pruebas de estrés, cuando sean mantenidas por un programador menos experimentado o cuando sean pirateadas. Si coloca información confidencial en el código, puede convertirse en un objetivo o los datos pueden filtrarse algún día.

Al comprender las propiedades del código y limitar su complejidad, puede reducir el daño que puede causar cuando se piratea o cuando se mantiene de forma descuidada. También lo convierte en un tema potencial para el software de prueba de teoremas, algo muy bueno.

———

El autor recibió un premio de Lockheed Martin por hacer que un controlador de instrumentos complejo funcione en un vuelo de prueba orbital. Se creía que el instrumento estaba condenado al fracaso porque solo tenía un 10% de margen servo. Por lo general, se requiere un margen del 100%, pero los algoritmos que creé corrigieron estas deficiencias y el instrumento logró una puntuación de éxito del 90%.

Answer 3

Porque necesitas ser preciso.

Las instrucciones que debe dar a una computadora a través de los lenguajes de programación no son “hacerme un café”, sino que, según el idioma, son más como

• Toma la olla de moka
• Abrelo
• Desmonta las piezas
• Llénalo con agua
• Pon el filtro en su lugar
• Llena el filtro con café
• …

O

• Mover a donde está la olla de moka
• Extiende tu brazo hacia donde está el moka
• Cierra la mano alrededor de la olla
• Retrae tu brazo
• Pon la otra mano en la olla
• Gira la olla para abrirla
• …

Ves lo que quiero decir. Debe saber lo que está haciendo y asegurarse de dar las instrucciones correctas. Y, probablemente, nada le impedirá llenar la olla de moka con agua antes de abrirla, pero de todos modos causará un gran desastre.

Cuanto más alto sea el nivel o el resumen del lenguaje, más fácil será escribir programas. Tal vez algún día las computadoras puedan entender idiomas naturales, como el inglés, pero hasta entonces el programador necesita usar un idioma que la máquina pueda entender.

Nota al margen: el costo de los lenguajes de alto nivel es la pérdida de control, ya que la implementación del lenguaje determina más cómo se hacen las cosas. En pocas palabras, puede decirle fácilmente a la computadora que prepare café, pero no podrá controlar con precisión cómo resultará el café.

Answer 4

Creo que no es realmente difícil como lo ven algunas personas. Necesitas saber el idioma para usar al nivel promedio. Tome los requisitos completos de qué software necesita ser desarrollado, obtenga el flujo de proceso correcto y programe en función del flujo de trabajo proporcionado. Lo mejor de esto es probar muy bien y asegurarse de que puede realizar todas las tareas requeridas de manera efectiva y eficiente.