¿Por qué algunos programadores piensan que hay un contraste entre la teoría y la práctica? [cerrado]

Creo que la principal diferencia es que con la ingeniería civil, la física del mundo real actúa como una constante y poderosa verificación de la realidad que mantiene la teoría sana y también limita las malas prácticas, mientras que en la ingeniería de software no existe una fuerza igual de fuerte para mantener la torre de marfil poco práctica Conceptos, así como mano de obra de mala calidad en el control.

Muchos programadores han tenido malas experiencias con la teoría descontrolada convirtiéndose en un impedimento activo para hacer las cosas (por ejemplo, "UML ejecutable", procesos de desarrollo super-burocráticos). A la inversa, los hacks y los parches sucios pueden llevarte bastante lejos, aunque lentamente al final. Y como observa en su último párrafo: las fallas generalmente no son tan definitivas y, por lo tanto, no son tan problemáticas.

La ingeniería de software y la ingeniería civil tienen poco en común. Los esfuerzos de ingeniería civil están limitados por las propiedades físicas de sus materiales y el medio ambiente. Los ingenieros civiles pasan mucho tiempo aprendiendo sobre las propiedades del suelo y las características del material. El desarrollo de software está limitado físicamente solo por la velocidad de los procesadores y el almacenamiento disponible. Ambos son fáciles de entender y no dedicamos mucho tiempo a estudiarlos. La principal limitación para el desarrollo de software es el intelecto humano. Y no hay dos desarrolladores iguales. ¿Es este código mantenible? ¿Por quién? Una implementación de tres líneas de quicksort en Haskell puede ser obviamente correcta para algunos, pero incomprensible para otros. Un equipo de dos puede completar una solicitud en un mes, mientras que otro equipo de diez luchas por entregar en un año.

El desarrollo de software es todo diseño, los artefactos que se diseñan son órdenes de magnitud más complejos que cualquier artículo manufacturado, y cada uno es único.

Como ingeniero mecánico más o menos honesto (con algo de civil), se convirtió en programador, luego en CS (AI), luego en profesor y luego en programador nuevamente (disculpe, Software Engineer ), Tengo una perorata sobre este tema general.

En ingeniería tradicional

• tienes que saber tus matemáticas y ciencias porque todo lo que haces está basado en ello
• los "héroes" en el campo son personas que inventan cosas nuevas, descubren nuevas ideas, resuelven problemas que no se pueden resolver,

Hay una "física" que se aplica a la teoría de la información de software, pero los ingenieros de software tienen poca exposición a ella, y ciertamente no se aplica nada. La mayor parte de la teoría que obtienen es la computabilidad y la gran O.

También me asombran continuamente las personas que piensan que conocer la programación es suficiente, y no necesitan entender el tema de lo que tratan sus programas.

Además, no se fomenta la inventiva. Se desaconseja, a favor de los métodos de pensamiento grupal de mínimo común denominador, disfrazados de "legibilidad". (Imagínese si se alentara a los ingenieros aeronáuticos o nucleares a no hacer nada que pudiera ser difícil de entender para sus pares más jóvenes).

Las cosas que aprenden, como la forma de programar aplicaciones web, son de gran valor. Así es la habilidad de un fontanero o electricista, pero no es ingeniería.

Si recorro una esquina en el software la mayoría y hago algo que no es el mejor diseño, pero que hará el trabajo, nadie morirá. Es la misma razón por la que una cabaña en el jardín no necesita los mismos estándares que un edificio de 10 pisos. Sin embargo, puedo crear una aplicación muy grande como Facebook, y si se complica y pierde algunos datos, o lo que sea, no es realmente una gran cosa. También es más sencillo arreglar los cimientos de una aplicación grande después del hecho, que reemplazar los cimientos de un edificio de 10 pisos. Todo se reduce al contexto y al cálculo del riesgo.

También puedo, de forma segura y simplemente seguir agregando a una aplicación. No se puede tirar fácilmente en un tercer piso de un edificio de 10 pisos (haciéndolo 11). Puedo agregar una nueva característica a una aplicación grande todos los días si así lo deseo.

Ahora, un buen diseño facilita todo esto en la programación. Pero no es imposible con un diseño deficiente, y los riesgos son ... un software defectuoso. No suele ser la muerte.

Ten paciencia conmigo en este caso. Tengo un punto.

Un profesor me dijo una vez que la postergación conduce a más retrasos, aunque la mayoría de las personas después de una noche de apresurada redacción, programación / programación de papeles se dicen a sí mismos: "Nunca volveré a hacer eso. La próxima vez, lo haré". Empezaré temprano y terminaré temprano ". En mi experiencia como el procrastinador consumado, encontré que esto es cierto, y aquí está la explicación del profesor por qué: no importa cuán desagradable sea la experiencia de postergar, en la mayoría de los casos, ha terminado teniendo éxito relativo. Este es un comportamiento de alto riesgo / alta recompensa. Después de un tiempo, te olvidas de todo lo desagradable y solo recuerdas la recompensa. Por lo tanto, la próxima tentación de posponer las cosas es aún más tentadora, porque lo has logrado la última vez.

Creo que aquí se puede hacer una analogía con la técnica de programación para "hacer las cosas" que con demasiada frecuencia vemos. Un programador o equipo de programadores, quizás por ignorancia, pereza o quizás por una verdadera limitación de tiempo, toma el enfoque de "hacer las cosas" para la programación, arrojando toda su teoría y matemáticas y buenas prácticas por la ventana. ¿Y sabes qué? Ellos hacen las cosas. No es elegante, bonito o mantenible, pero hace el trabajo. Tal vez un superior no técnico que no conoce un punto y coma de un semáforo les da un gran elogio por "hacer las cosas". Por lo tanto, la próxima vez que el programador se sienta tentado a tomar este enfoque de programación, es más fácil, porque la última vez funcionó, ¿no es así? Es la salida "fácil", a menos que sea su alma pobre y desafortunada quien hereda tal aplicación años más tarde y tenga que mantenerla.

He sido esa pobre y desafortunada alma, y probablemente muchos de ustedes también. Les imploro a todos. ¡No tome la salida fácil! :)

Su premisa es defectuosa. La razón principal por la que los ingenieros civiles utilizan la ingeniería al diseñar grandes edificios, puentes, túneles, etc., es para garantizar que utilicen una cantidad mínima de material (hormigón, acero estructural, etc.) que cumpla con los estándares de seguridad requeridos. Es completamente posible construir un edificio alto sin muchas matemáticas (por ejemplo, las pirámides de las antiguas civilizaciones egipcia y maya) si los costos de material y de mano de obra no son un objeto, pero una vez construidos, generalmente no tiene sentido modificarlos. Para que usen el material de manera más eficiente.

Hay una dinámica algo diferente en el diseño de grandes sistemas de software. En todo caso, generalmente están mal diseñados, pero esto se debe a que el diseño puede cambiarse dinámicamente a medida que avanza el trabajo, lo que simplemente no se puede hacer tan fácilmente con proyectos de ingeniería civil.

El factor común es el costo. El diseño en un proyecto de ingeniería civil tradicional reduce los costos (tanto reales, en términos de material, y potencial en términos de responsabilidad), mientras que en el desarrollo de software llega un punto en el que el costo del diseño aumenta más allá del valor devuelto.

También destacaría, además de varias otras respuestas excelentes que la humanidad ha estado haciendo en el equivalente de "ingeniería civil" ya que es muy fácil para los egipcios, así que hemos tenido mucho tiempo para perfeccionar la teoría general de Cómo se deben hacer las cosas. Llevamos más de 70 años desarrollando software (según lo que considere el primer "software"); Quiero decir que no hemos tenido la misma cantidad de tiempo para desarrollar el mismo tipo de experiencia.

Los planos de un arquitecto / ingeniero civil prácticamente nunca son idénticos a los planes "tal como están construidos". Algo SIEMPRE cambia. ¿Por qué? Porque hay, y siempre habrá, "incógnitas desconocidas". Hay cosas que sabe y por lo tanto puede planificar, cosas que sabe que son desconocidas y por lo tanto puede investigar y estimar, y luego hay cosas que no sabe que no sabe; "sorpresas". Su objetivo es eliminarlos en la mayoría de los sistemas aprendiendo todo lo que pueda, pero todo lo que necesita es una pequeña infracción del código de construcción (que puede estar basada en una regla que no existía hace 2 años cuando su edificio estaba siendo conceptualizado) y todo. -el plan maestro de integración tiene que cambiar, a veces de forma drástica.

El software es muy parecido a esto; Siempre hay un desconocido desconocido. Sin embargo, a diferencia de la ingeniería civil o estructural, el desarrollo de software es inherentemente mucho más tolerante al cambio basado en los problemas que crean las incógnitas desconocidas. Si está construyendo un edificio de 10 pisos y sobreestimó la capacidad de carga de los cimientos que colocó en su diseño, no puede construir el edificio de 10 pisos o tiene que arrancar una cantidad significativa de trabajo para vuelve a los cimientos y refuérzalos o reconstrúyelos. Sin embargo, en el software, si subestimó las demandas en un nivel particular de la estructura global de la solución, hay muchas opciones para corregir ese nivel que no implican la invalidación de todo el trabajo. Puede reemplazar un solo servidor de base de datos por uno más poderoso, o un clúster de replicación / conmutación por error, o un clúster de equilibrio de carga / distribuido. Lo mismo para el servidor web. Si codificó un algoritmo que es ineficiente pero simple basado en suposiciones erróneas del tamaño de la entrada, casi siempre puede simplemente eliminar y reescribir la implementación de una manera relativamente quirúrgica, sin afectar a otro código que tenga conocimiento del algoritmo (llama y pasa la entrada a o espera una salida de él).

Esta relativa facilidad de cambio le permite a un ingeniero de software codificar basándose en lo que sabe sin preocuparse excesivamente por lo que no sabe. Esto permite una aplicación más relajada de la teoría y un diseño conceptual inicial; se sumerge y lo hace, y en el camino encuentra las cosas que codificó que necesitan cambiar y las cambia. Aún debes conocer los conceptos y la teoría, porque cuando se descubre un problema son esas cosas las que te ayudarán a identificar la causa y crear una solución. Pero, se le permite tomar una decisión rápida sin sucumbir a la "parálisis de análisis", porque si resulta que tomó la decisión incorrecta basándose en algo que no sabía o no tuvo en cuenta en sus "cálculos", el el error es más fácil de corregir.

La diferencia se debe principalmente a los requisitos conocidos:

• En el lado de la teoría, todo se define por adelantado, para que pueda saber exactamente lo que necesita antes de comenzar.
• En la práctica, a menudo no están todos allí, o descubres algo a mitad de la implementación que hace que tengas que rediseñar algo. Así que es mucho mejor saltar al menos con diseños rudimentarios, para que puedas descubrir estos problemas desde el principio.

Además, cuando se habla de "teoría", generalmente se refiere al lado teórico de la informática, en lugar de a la ingeniería de software. Esta es la parte de la ciencia de la computación que trata sobre todo de encontrar algoritmos mejores y más eficientes, de probar si algo es o no es posible (P y NP, por ejemplo), y así sucesivamente. Si bien es bueno tener esto en mente, no aparecen en el desarrollo de software muy a menudo.

Usamos bibliotecas para ese tipo de cosas tanto como sea posible.

En realidad, existen bastantes niveles de ingeniería de software, dependiendo de lo que esté haciendo el software que está creando.

La NASA necesita un software para controlar los transbordadores tripulados en el espacio, por lo que, naturalmente, el nivel del proceso de ingeniería es mucho más estricto que el de la construcción de un sitio web para mostrar imágenes de cohetes.

¡Uno de mis compañeros de trabajo que trabajó para la NASA describió previamente su proceso de ingeniería de software como escribir cientos de páginas de justificación y cientos de horas de reuniones para justificar la escritura de una sola línea de código!

No me malinterpretes porque no trato de parecer irrespetuoso cuando digo esto, pero incluso después de todo ese costo de tiempo, recursos y miles de millones de dólares, el transbordador espacial todavía explotó.

Incluso los ingenieros civiles saben que no importa cuánta teoría pongan en un diseño, algo lo romperá, por lo que también necesitan desarrollar planes de contingencia.

Cuando se crea un software, el costo de su falla rara vez causa la pérdida de vidas, por lo que es mucho más fácil tirar las cosas rápidamente y probarlas. Acordemos que hacer las cosas rápidamente resulta en un código débil. Incluso si este es siempre el caso, ver el software en acción es la mejor manera para que un desarrollador vea dónde está débil y necesita ser más fuerte en comparación con donde está débil y todavía muchas veces más fuerte de lo que debe ser para mantenerse al día. la carga.

Para resumir, Premature optimization is the root of all evil o como mi jefe siempre diría Shipping is a feature!

Muchas buenas respuestas aquí, pero creo que la comparación entre Ciencias de la Computación e Ingeniería Civil es errónea.

Estrictamente hablando, lo que hacen los desarrolladores de software profesionales es más parecido a la Ingeniería de Software que a la Informática. Una analogía mejor es que la ciencia de la computación es la física para la ingeniería de software. Del mismo modo, Civil Engieering es una colección de simplificaciones y aproximaciones de Física para prácticamente construir cosas.

Me imagino que los ingenieros civiles rara vez tienen que tomar en cuenta la relatividad general cuando realizan su trabajo. Gran parte de la ingeniería civil se puede construir de forma segura en la mecánica newtoniana. De manera similar, la ingeniería de software se puede lograr con mucho éxito con una comprensión aproximada de la ciencia de la computación teórica.

La gran diferencia es que los puentes, los rascacielos y otros productos de ingeniería civil son cosas que se entienden razonablemente bien. Los ingenieros de software a menudo construyen construcciones novedosas, o usan métodos novedosos para construir cosas bien entendidas. La Ingeniería de software es MUCHO menos madura que la Ingeniería Civil, y eso probablemente seguirá siendo cierto en el futuro previsible.

TL; DR : la teoría y la práctica son diferentes en la ingeniería de software, al igual que en cualquier otra parte. La analogía adecuada es Ingeniería de Software: Ingeniería Civil :: Informática: Física. Pero en la práctica, es un poco más complejo que eso :)

  

Así que mi pregunta es ¿por qué algunos programadores piensan que hay un   contraste entre la teoría (métodos formales) y la práctica (conseguir cosas   hecho)?

El software de construcción es diferente a construir un puente. En el software, hay muchos objetos por construir que pueden o no definirse al inicio. Existen normas para aumentar la facilidad de mantenimiento y la colaboración del desarrollador, no para adherirse a fórmulas matemáticas arbitrarias u otros ideales similares. Por ejemplo, cuando se selecciona un comportamiento basado en una variable, a veces tiene sentido usar un interruptor, otras veces un patrón de fábrica. Depende de la facilidad de mantenimiento y los puntos de dolor identificados, como los problemas de rendimiento.

Otro ejemplo puede hacerse con la manipulación de datos. A menudo tiene sentido usar delegados en el contexto de .NET. No es tan fácil en Java porque no tiene el soporte de marco para el estilo de programación funcional que tiene .NET. En otras palabras, en el caso general, simplemente no es posible hacer X en la situación Y. Esto se debe al hecho de que X e Y dependen del número N de factores variables.

  

La ingeniería de software (software de construcción) es percibida por muchos como fácil   comparado con, digamos, ingeniería civil (construcción de casas)?

No estoy seguro de que "fácil" sea el término correcto. La falta de evidencia tangible puede llevar a la percepción de que no se está haciendo ningún trabajo. O, de manera similar, ese trabajo existente se puede cambiar fácilmente.

  

O son estas dos disciplinas realmente diferentes (aparte de   software de misión crítica, la falla del software es mucho más aceptable   que el fracaso del edificio)?

La ingeniería tradicional y la ingeniería de software son muy diferentes por las razones que ya mencioné.

Su percepción puede estar equivocada aquí, o incluye muchos recursos de personas que no han escrito software suficientemente complejo.

Su experiencia está en línea con lo que diría la mayoría de las personas que conozco (que han diseñado y escrito software suficientemente complejo).

Dicho esto, cuando se trata de la mayoría de los programadores , cuando la tarea de escribir algo les llega a ellos, el diseño ("lo matemático", como lo has dicho) ya lo hizo el arquitecto / jefe. / etc. Antes de que la tarea de escribir les llegue. Así que puede parecer así desde el nivel de primera línea.

Creo que la razón de este contraste es que el ciclo de vida de un proyecto de software y un proyecto de hardware o arquitectura es diferente. La mayoría del software evoluciona gradualmente, no está planeado desde el principio hasta el final. Los desarrolladores de software pueden aplicar un enfoque iterativo al desarrollo: planificar, implementar y escuchar comentarios. Si la respuesta es positiva, continúe, no: retroceda y reconsidere su estrategia. Es por eso que los desarrolladores de software tienen cosas como desarrollo ágil, producto mínimo viable, etc.

Los ingenieros civiles no tienen ese lujo. Para ellos, una vez que se planea algo, no puede cambiarlo tan fácilmente, como con el software, porque el costo de tales cambios puede ser muy alto. Para el desarrollo de software, por otro lado, no cuesta mucho, y esto puede usarse para su ventaja.

Pero no todas las ramas del desarrollo de software pueden permitirse tal enfoque. La creación de software, por ejemplo, para la aviación o los servicios médicos requiere una planificación muy cuidadosa y muchos cálculos previos.

A mi me parece lo mismo. Usted construye un edificio grande de bloques estándar, concreto de resistencia estándar, acero estándar. Construyes una gran aplicación a partir de bibliotecas estándar.

No intenta probar matemáticamente que una aplicación grande es correcta de la misma manera que no intenta escribir la función de onda para un edificio de 100 pisos

Fui ingeniero mecánico y de fabricación antes de descubrir hace 20 años que mis aptitudes se centraban en el software. Simpatizo con muchos de los elementos que ha expuesto.

Sospecho que la verdadera naturaleza del problema es sobre cómo hacemos las cosas. Ahora tenemos diez o más años de desarrollo ágil bajo nuestros cinturones colectivos, y el mensaje es claro. No progreses por capas; Progreso por características. Claro: habrá proyectos cuando necesite avanzar por capas (por ejemplo, construir su pila de red antes que su servidor web), pero para la gran mayoría de los proyectos del mundo real, hemos aprendido la lección que ofrece funciones de trabajo, una o varias en Una vez, es mucho más eficaz construir grandes teorías no probadas y luego tratar de implementarlas.

Así que tomemos su ejemplo de choza (por lo general, hablo de hacer un puente lanzando un registro a través de una corriente frente a un puente suspendido de un kilómetro ... ¡y llévelo al mundo de la ingeniería de software! La principal diferencia que veo es que en el software, la mayor parte del trabajo es de una escala que no necesita un gran modelado inicial para tener éxito. El error del principiante es a menudo suponer que las cosas necesitan más de esto de lo que realmente hacen, y para la mayoría de nosotros, habiendo cometido ese error varias veces, estamos dispuestos a repetirlo con demasiada frecuencia.

Sin argumentos: hay proyectos que deben comenzar con un comité de 17 arquitectos de software. En realidad, son tan raros como los diamantes de 20 quilates.

Creo que la analogía es errónea. Que yo sepa, la ingeniería civil no tiene el mismo tipo de base teórica que la informática; la informática nació de las matemáticas teóricas, como las máquinas de Turing. La ingeniería civil consiste en crear estructuras que resistan a la madre naturaleza y quizás incluso se vean hermosas. Una vez más, realmente no sé mucho sobre ingeniería civil, pero no creo que haya equivalentes de ingeniero civil de P vs NP, el vendedor ambulante y otras cosas divertidas contra las que atacar. Y definitivamente hay un lugar para nuestra teoría de la ciencia computacional: si alguien resuelve al vendedor ambulante o el problema de la detención, nos encontramos ante muchos nuevos avances asombrosos. Pero para un ingeniero de software, cuya misión es diseñar software, estos problemas son realmente solo diversión y juegos.

Ahora, también creo que depende de lo que entiendas por "teoría". ¿Estamos hablando de patrones de diseño o de bombeo de lema? Porque tener una buena comprensión de los patrones de diseño es absolutamente fundamental para ser un buen ingeniero de software. Sin embargo, cuando se diseña un sistema de software grande, no es útil teorizar sobre los problemas de P / NP. En ese sentido, creo que hay un contraste muy marcado entre la ingeniería de software y la informática teórica.

¿O la teoría se refiere a algoritmos? No pasas mucho tiempo escribiendo algoritmos que aprendiste en tu clase de algoritmos. ¿Por qué? Debido a que normalmente solo los necesita en casos particulares (y luego los busca e investiga), o usa una biblioteca ya escrita para usted. No hay necesidad de escribir otro clasificador bayesiano. La abstracción es un principio importante en la informática. Creo que los ingenieros de software tienden a no aprender cómo funciona un algoritmo hasta que lo necesitan.

Otra razón es que actualmente hay varios métodos populares de desarrollo de software "listo para usar" que son efectivos. Por ejemplo, en el desarrollo ágil, no diseña un sistema completo de antemano. La razón de esto es que aún no sabe exactamente lo que está construyendo : quiere que lo que está haciendo sea flexible y se adapte a la nueva información y los nuevos requisitos. Diseñe todo desde el principio y luego cree que no siempre se produce el mejor software. Sin embargo, no es la solución para todo. Por ejemplo, supongamos que estás diseñando algo de computación distribuida, clúster, algo nuevo. No puedes hacer algunos bocetos de servilletas y comenzar tu SCRUM.

TL; DR. Creo que hay un cierto error en torno a la palabra "teoría". Tradicionalmente, la teoría se refiere a los aspectos matemáticos teóricos de la informática. A menos que esté investigando nuevas formas de computación, en su mayor parte la teoría teórica de la computación no juega ningún papel en la vida cotidiana de un ingeniero de software. Los ingenieros de software se preocupan por los patrones de diseño y la arquitectura del sistema. Los detalles de implementación específicos de ciertos algoritmos no son importantes. Muchas veces, con ideas menos complicadas, es apropiado no diseñar mucho y simplemente comenzar a codificar. Y creo que aquí es de donde viene la idea de que a los programadores no les gusta la teoría.

La brecha entre la teoría y la práctica es demasiado grande en este momento. Al hacer teoría, se le dan tres axiomas y posteriormente se muestra que un teorema de una línea tiene una prueba de mil páginas, o ninguna prueba en absoluto. En ingeniería de software, se le dan APIs inconsistentes de miles de funciones que le brindan una gran variedad de formas (malas) de implementar una función no especificada.

La ingeniería de software real volvería loca a la mayoría de los que trabajan en el campo formal, y el desarrollo de software matemático real vuelve locos a los de ingeniería. Ambos campos requieren personas de diferentes aptitudes, y no creo que las aptitudes a menudo se superpongan.

La teoría formal asume que puede planificar todo de antemano con precisión, como un producto fabricado, que el software existirá indefinidamente dentro del mismo entorno y que la solución a un problema abstracto general siempre es la meta. Asume un ciclo de vida del software como producto 4D: diseñar, desarrollar, desplegar, hacer. La teoría formal trata de resolver el problema del diseño de software utilizando análisis, abstracción, generalización y predicción de cambios futuros. Esto es bueno si tiene un problema bien definido en un dominio directo que es fácilmente analizable, predecible y bastante estático.

La programación práctica consiste en resolver el problema correcto (no el diseño de software) de la manera correcta en este momento, para que sus compañeros de trabajo puedan hacer su trabajo mejor / más rápido / en absoluto, o para que los ingresos puedan llegar a la empresa. . Gran parte del software no es como un producto, nunca "hecho", sino más bien como un ser vivo, que comienza altamente especializado para un nicho ecológico, y puede tener una vida útil muy variable durante la cual debe resolver problemas nuevos e imprevistos en una Amplia variedad de ambientes siempre cambiantes. En el mundo de los negocios, con políticas y legalidades y competencia y organizaciones, estructuras y tendencias en constante cambio, los requisitos son a menudo ambiguos, complicados con todo tipo de casos especiales, mal definidos y sujetos a rápidos cambios inesperados. No son analizables, predecibles ni estáticos, y con frecuencia no son lógicos o razonables. El software es tan probable que sea irrelevante en 2 semanas como para seguir utilizándose en 20 años. Viene al mundo sin saber mucho o no puede hacer mucho, y necesita ser alimentado, preparado y entrenado durante toda su vida para crecer fuerte, flexible y capaz de adaptarse a sus entornos en constante cambio y nuevos problemas. Si lo descuidas después del nacimiento, se volverá salvaje si sobrevive lo suficiente y causará dolor y sufrimiento, resolviendo problemas con fuerza contundente.

La teoría formal no responde a las necesidades de gran parte del software empresarial del mundo real. Nos engaña a creer que el software puede ser diseñado y hecho. Que es un producto que se puede arreglar ocasionalmente, pulir o apilar, pero no como un ser vivo que necesita ser criado adecuadamente con cuidado y atención constante durante toda su vida útil. Así que terminamos con un código de legado feral realmente feo, pero la teoría formal probablemente no habría ayudado con eso.

Todo suena bastante negativo, pero en realidad me encanta usar la teoría formal. Un hermoso diseño siempre trae una sonrisa a mi cara. Sin embargo, eso es principalmente en mi programación de aficionados que no está sujeta a las vicisitudes de los negocios. En el trabajo, me ocupo principalmente del código orgánico y solo espero poder prestarle suficiente atención para que crezca bien, me haga sentir orgulloso y no sea desagradable ni grosero con otros que tienen que lidiar con él.

Las apuestas son más bajas, el trabajo es más fácil y la administración rara vez ve el valor en un buen diseño. La inestabilidad, la capacidad de mantenimiento y la integridad del sistema son un problema de "TI", no un problema de "Negocio". Todos los ejecutivos tienen una cosa en común. Están enfocados en el dinero en un 95% o se reportan a alguien que lo está.

El resto de la batalla es con tus compañeros programadores. Muchos de ellos no pueden o no se comprometen a pensar en un problema antes de que comience la codificación. Debido a lo anterior, una buena parte de estas personas son desarrolladores senior, lo que dificulta aún más la puesta en producción de un buen diseño.

Para empezar, observé las pérdidas de los proyectos durante años, agregando funciones y arreglos ad-hoc a los proyectos que eran complicados para comenzar, y luego derribé todos los intentos de poner orden en el caos con frases como "demasiado complicado" o "perder el tiempo". " No es agradable ver un gran proyecto en espiral hacia su inevitable condena porque la gerencia no admitirá que están construyendo su propia prisión a diario; sin embargo, me temo que es una realidad desafortunada que muchos desarrolladores han presenciado y, para bien o para mal, han aprendido.

Intento encontrar un medio en mi trabajo. No escribo más código en proyectos "contaminados" del que es absolutamente necesario, y aprovecho cada oportunidad para mover la funcionalidad hacia fuera de ellos. "Entre proyectos", dedico tiempo al diseño y limpieza de los proyectos sobre los que tengo control.

Al final, es un gran lío de política e integridad personal que el 75% de los programadores del mundo no tienen estómago para. Apenas puedo soportarlo, yo mismo.

En primer lugar, me encanta esta pregunta. He escrito como tres respuestas de 1000 palabras y todas estaban terriblemente equivocadas cuando llegué al final de ellas.

El problema con el intento de comparar los dos como análogos, creo, es que la programación es un proceso de modelado que puede ser tan abstracto o concreto como desee.

La teoría de la ingeniería estructural, por otro lado, está estrechamente vinculada a conjuntos muy específicos de leyes basadas en la realidad con las que tiene que cumplir. No puedes simplemente alterar el contexto o las leyes. El problema en sí está arraigado en esas leyes. Sin embargo, en la programación, a veces la solución es en realidad alterar la naturaleza de la pregunta o simplemente ubicarla en un contexto diferente.

Si el patrón MVC, por ejemplo, es un ajuste perfecto, tiene mucho que ver con ese contexto. Una aplicación de escritorio generalmente trata en un solo idioma y en un solo idioma, sin contar los archivos de configuración.

La parte frontal de una aplicación web, por otro lado, consta principalmente de dos lenguajes declarativos (no de programación) y JavaScript. La única cosa física que no puedes abstraer completamente es el hecho de que siempre hay un muro http para tirar cosas entre el servidor y el navegador. Independientemente de cómo lo entierres en el código, eso lleva tiempo y un diseño asíncrono.

Obviamente, no puede usar un patrón popular y bien considerado como MVC para manejar las preocupaciones de la parte delantera en la web exclusivamente sin alterar la forma en que podría manejarlo en un contexto de aplicación de escritorio. De hecho, diría que debería estar al tanto de lo que hace que MVC sea útil, pero ni siquiera intentar implementarlo de una manera particularmente exigente o general. El paradigma de la aplicación web es único en que todas las cosas de look-to-me son manejadas por el navegador del usuario y todas las cosas de datos / modelos suelen estar en el servidor en algún lugar. ¿Pero dónde deja eso al controlador? ¿Todos en el servidor o todos en el extremo delantero? Alguien tiene que poseer eso. O tal vez MVC no es 100% la mejor opción para el escenario. No es un mal ajuste para cosas de back-end .NET. No es terrible en el contexto de widgets de interfaz de usuario específicos. Pero intentar aplicarlo a todo por motivos de coherencia podría ser una mala decisión, OMI.

Construir una casa resuelve un problema. Sin embargo, los problemas de programación típicos a menudo implican la resolución de problemas dentro de los problemas y, en ocasiones, la solución es redefinir el problema externo. Lamentablemente, la realidad no está especialmente interesada en esa idea.

Glenn Vanderburg presenta una excelente visión de las diferencias entre la ingeniería de software y las disciplinas de ingeniería más tradicionales: enlace

Si un ingeniero civil pudiera probar sus diseños sin ningún costo antes de construir lo último, haría mucho menos uso de la teoría. Si en segundos pudiera construir un puente mil veces gratis para probar cuándo se romperá, lo haría en lugar de pasar meses calculando cuándo podría frenar en teoría ...

En el desarrollo de software, eso es exactamente lo que haces. En lugar de calcular qué tan rápido es tu algoritmo en teoría, puedes probarlo y saber la respuesta en segundos.

De hecho, la mayoría del software actual ya no está limitado por restricciones físicas como la capacidad de cálculo o la memoria. La limitación del software es la complejidad que implica en sistemas cada vez más grandes. Su gestión de esta complejidad hace que el sistema sea comprensible para los humanos, lo que hace que el gran desafío en la programación de hoy.