¿Cuáles son algunos de los principios de CS que desea que entiendan los no ingenieros (UX, gerentes de producto, negocios)?

“Requisitos” ~ = “Especificaciones ~ =” Código “. Y los dos primeros son importantes.

No es un principio de CS, sino un problema estándar de Pointy-Haired Boss: “El hecho de que pueda imaginarlo no significa que se pueda programar de manera fácil, rápida o confiable”.

En la misma línea: “Elige dos de tres: rápido, bueno, barato”.

Contrariamente a los esquemas a menudo propuestos para sacar algo rápidamente de la puerta: “Nueve mujeres no producen un hijo en un mes”

“Empiezas a codificar, iré a buscar los requisitos” es un plan realmente malo. Relacionado: “Empiezas a codificar, diseñaremos más tarde”. (Los programadores también sufren mucho de este).

“El 40% de los costos de ingeniería de software son * pruebas *”. ¿Está en el presupuesto? ¿Dónde? Sí, sé que el cliente quiere el costo más bajo. No puedes dejar esto fuera; pagará más si no lo planea. Eso saldrá de su presupuesto (o la vida de su programador) ya que acordó no cobrarle al cliente por ello.

“Tengo que tener un programador que tenga 10 años de experiencia en todas las tecnologías que tenemos”. Derecha. Mi hija quiere un pony.

“El tipo que produce más líneas de código es el más productivo”.

“Este software es difícil de mejorar. Vamos a reescribirlo desde cero”. También una falla de muchos programadores. La gente olvida que si tardó 10 años en escribir el software, una parte muy importante de eso fue descubrir los requisitos, que todos han olvidado. Reescribe desde cero, puedes redescubrirlo todo de nuevo. A más o menos el mismo costo.

“Solo porque Facebook lo eligió, no significa que fuera inteligente”.

Oh notación. O (ln n) ~ = O (n) ~ = O (N ln N) ~ = O (N ^ 2), y es importante.

Matemáticas para servilletas de cóctel para controlar la cordura. Calcule el tamaño del problema simplificando demasiado para decidir si su respuesta es sensata. (Oh, la notación es una versión de esto).

“El código es el diseño” es completamente BS, a menos que no pueda diseñar. Mire lo que hay en las pizarras y luego pregúntese por qué hacemos tan poco esfuerzo para preservar la información del diseño, y luego nos quejamos de que es tan difícil entender cómo funciona un código.

Los siguientes son algunos principios de ingeniería (no exactamente de ciencias de la computación (CS) como usted especificó) que desearía que algunos de mis gerentes de producto y diseñadores usaran al determinar una característica:

  • Tablas de verdad para asegurarse de que la lógica y el conjunto de comportamientos que permite el sistema no tengan huecos que se hayan perdido. Tenga en cuenta que la solución en la que está pensando requiere una nueva habilidad que el ingeniero permitirá en el producto. ¿Explicó cada posible nueva situación que acaba de presentar? ¿O solo pensó en el 80 por ciento de cómo cree que las personas deberían usar la función?
  • Diagramas de flujo que manejan todos los casos posibles de decisiones y acciones del usuario. El ingeniero que lo implementa probablemente no sea mucho más inteligente que usted, así que no confíe en ellos para descubrir qué debería suceder cuando el usuario hace clic en el botón Atrás.
  • Tire del desarrollador real trabajando en él temprano. No es un desarrollador senior que probablemente no comunicará todos los matices a la persona que realmente lo implementa. Y temprano. Es decir, antes de pasar horas y días en bonitas capturas de pantalla bonitas.

Hace mucho tiempo, tuve una discusión con alguien en la gerencia que pensó que era bueno que los diseñadores de software no entiendan muy bien la tecnología, por lo que pueden “pensar fuera de la caja”.

Señalé una computadora y dije: “Esa es una caja. Si piensan fuera de esa caja, estamos jodidos”.

Que los detalles realmente importan.

No es que tengan que importarles a todos por igual, sino que no les importen a algunos, no significa que no importen en absoluto.