¿Es posible escribir software que no necesita ser modificado continuamente?

23

He escrito una gran cantidad de software en muchos idiomas diferentes, y también he "escrito" hardware para usar con FPGA usando Verilog y VHDL.

Tiendo a disfrutar escribiendo hardware más que software, y creo que una de las razones principales es que es posible escribir hardware "hecho" y nunca necesita ser modificado: usted define las interfaces y la funcionalidad, escribe un banco de pruebas , implemente el módulo de hardware, luego pruebe el diablo con un simulador. Entonces puede confiar en ese módulo de hardware como un bloque de construcción para crear algo más grande y mejor: si necesita agregar una función a ese módulo, cree un segundo módulo y agregue la funcionalidad allí. Nunca deseche el módulo original, ya que funciona bien y aún puede ser útil.

Una de mis principales frustraciones con el software es que nunca se "hace". Siempre hay otra característica para agregar. A menudo, al agregar una función, presenta un error en otro lugar que funcionaba bien antes. Esto no sucede en el hardware mientras no se violen las interfaces.

Para ser claros, no estoy abogando por construir una versión de algo con una lista de características y eso es todo para siempre: estoy a favor de las iteraciones y lanzamientos múltiples a lo largo del tiempo para agregar nuevas características. Simplemente no quiero meter el código a la izquierda y encontrar un error a la derecha, y esto parece suceder después de agregar una nueva función.

¿Es posible escribir software de una manera similar en la que el hardware está "escrito"? ¿Existe una buena metodología de desarrollo de software que permita que siempre se avance hacia adelante y que se agregue nueva funcionalidad sin necesidad de reescribir el código existente e introducir nuevos errores?

Nathan Farrington
fuente
8
Parece que estás describiendo OCP
Oded
¡Este material de principio abierto-cerrado se ve genial! ¿Alguien ha usado esto con éxito?
Nathan Farrington
2
@NathanFarrington: la mayoría de los patrones de diseño (según lo descrito por GOF ) siguen el OCP. Un ejemplo sería el patrón de método de plantilla .
Spoike
2
@NathanFarrington El principio abierto-cerrado es un principio común utilizado por los desarrolladores de software al diseñar software.
Jesper
1
Me imagino que muchos de los programas que utilizamos hoy están hechos con fragmentos que son copias al código que se escribió hace 20 años.
Mallow

Respuestas:

16

¿Quizás tenga algo que ver con interfaces y pruebas bien definidas, como el hardware?

Exactamente mis pensamientos!

Los módulos bien diseñados con interfaces claras tienden a ser esencialmente perfectos. Piensa en algo como la Stringclase de Java. Es un programa de computadora, pero tiene una interfaz cristalina. No hay errores conocidos en él. Hace lo que se supone que debe hacer, perfectamente. Claro, se ha probado exhaustivamente durante los últimos 15 años, y dado que prácticamente todos los programas usan Strings como bloques de construcción básicos, cualquier error se notará rápidamente. Cualquier "peculiaridad", no estrictamente errores, pero detalles de diseño que vale la pena tener en cuenta, como los que se describen aquí http://www.jwz.org/doc/java.html son bien conocidos por ahora, y por lo tanto se pueden tener en cuenta cuenta.

El software con errores es en parte un problema cultural: la gente está acostumbrada al software con errores, y a diferencia del hardware, el software generalmente se puede arreglar fácilmente después, por lo que no tiene que perfeccionarse inicialmente (o nunca, porque bueno, debemos enviar ahora, arreglemos en la próxima versión). Pero en gran parte, es un problema de complejidad real: la complejidad del software ha aumentado constantemente durante los últimos 50 años más o menos, pero el cerebro humano es el mismo. Cuando la creciente dificultad para lograr la perfección y la creciente facilidad para arreglar las cosas más adelante (compilaciones rápidas, automáticas, distribución por Internet) se combinan con la presión del horario y la falta de disciplina, el resultado es lo que es.

¿Existe una buena metodología de desarrollo de software que permita que siempre se avance hacia adelante y que se agregue nueva funcionalidad sin necesidad de reescribir el código existente e introducir nuevos errores?

Probablemente no haya una bala de plata, pero sí una buena combinación de mejores prácticas, que incluyen, entre otras:

  • Módulos simples y autónomos. En otras palabras, bajo acoplamiento y alta cohesión.
  • Inmutabilidad. Particularmente importante con la creciente concurrencia.

Vale la pena señalar que ambos puntos apuntan a reducir la complejidad. Ese es el punto clave. La entropía siempre tiende a aumentar y, a menos que luchemos contra eso, pronto nos ahogaremos en complejidad. También es interesante ver que durante los últimos años, los lenguajes de programación han evolucionado para fomentar o incluso hacer cumplir las prácticas mencionadas anteriormente. En particular, el aumento de los lenguajes funcionales es solo eso: las funciones puras siempre devuelven el mismo valor para la misma entrada, no hay estado en ellas. Luego, solo compones funciones puras que toman y devuelven valores inmutables , y limitan la inevitable mutabilidad a pequeños lugares bien definidos en lugar de difundirlo por todas partes. Mira esto: http://clojure.org/state

Joonas Pulakka
fuente
1
jwz no está del todo de acuerdo en que la clase String esté libre de errores - jwz.org/doc/java.html
1
Puede funcionar según lo diseñado, por lo que la pregunta es si el diseño subyacente está roto. Sin embargo, estoy de acuerdo en que String es una clase muy confiable.
1
Excelente respuesta Ahora codifico casi exclusivamente en Python y trato de aprovechar las construcciones de programación funcional. Sí, creo que tienes razón en que la inmutabilidad es la clave. La primera vez que creo un módulo de software, incluso si lo pruebo, probablemente haya estropeado la interfaz, o tal vez tenga la responsabilidad incorrecta o demasiada. ¡Así que hago un segundo módulo y dejo el primero solo! Todavía puedo usar el primer módulo en el futuro si lo deseo, pero nunca cambiarlo, porque aunque no es perfecto, funciona. Por lo tanto, los lenguajes funcionales con inmutabilidad podrían ayudar, como sugiere.
Nathan Farrington
1
@JoonasPulakka: Sí, si hay un resumen de una línea del software, podría ser "siempre hay otro error". :-) Y creo que ese es uno de los puntos de Nathan.
Ross Patterson
1
Joonas, tú ganas. Empecé a aprender Clojure. Parece la mejor manera de hacer que la programación sea divertida nuevamente.
Nathan Farrington
9

La diferencia es cuánto más fácil y económico es modificar el software en comparación con el hardware. Si el hardware fuera tan fácil y barato de modificar y enviar a los clientes, lo harían.

Creo que si pudiera resumir mi pregunta mal expresada sería algo así como, "¿cómo puedo divertirme más escribiendo software al no introducir errores en el código de trabajo y siempre progresando?" ¿Quizás tenga algo que ver con interfaces y pruebas bien definidas, como el hardware?

Definitivamente debe verificar el desarrollo basado en pruebas .

RCE
fuente
Muchas respuestas a mi pregunta parecen contener folklore. ¿Es necesariamente más fácil encontrar y corregir errores de software que diseñarlos desde el principio? ¿Cuánto cuesta realmente modificar el software? Probablemente nadie lo sepa realmente. Con respecto al desarrollo basado en pruebas, tiene sentido probar el software que se puede reutilizar. El software se convierte en un bloque de construcción real en lugar de una bola de barro. Pero no tiene sentido probar el software si solo va a cambiar mañana. Supongo que me preguntaba si realmente podemos hacer software a partir de bloques de construcción en lugar de barro.
Nathan Farrington
1
@NathanFarrington: Creo que hay una gran diferencia en cómo se hacen las especificaciones y el diseño del hardware / software. La mayoría de los fabricantes de hardware tienen probablemente mejores especificaciones para lo que hacen que un desarrollador de software cuyo cliente solo puede decir "¡Quiero un programa que haga esto!" Está prácticamente garantizado obtener nuevas funciones y lo que no.
RCE
Claro que si hay muchos cambios, es posible que algunas pruebas también necesiten cambiar, pero no es como si el software cambiara del procesador de textos al servidor web. Su función de "nuevo documento" seguirá creando una nueva función y sus pruebas aún deberían ser válidas.
RCE
Usted señaló otro principio clave: cuanto mejores son las especificaciones, menos cambios se requieren en el futuro. Pero esto no era exactamente a lo que me refería en mi pregunta porque puede agregar funciones al hardware antes de que se haga como el software. Creo que OCP fue la respuesta real, lamentablemente es un comentario, así que no puedo marcarlo como la respuesta. Otro punto era avanzar siempre y creo que TDD puede ayudarlo proporcionando pruebas de regresión.
Nathan Farrington el
Cambiar el software parece más fácil y menos costoso que el hardware, pero ¿lo es realmente? Sí, puedo hacer un cambio y casi instantáneamente hacer una nueva construcción con solo presionar mi dedo. Sin embargo, la compilación todavía necesita pasar por validación / QA. ¿Cuál fue el costo de oportunidad? ¿Qué hubiera estado haciendo en lugar de corregir este error? ¿Qué hubiera estado haciendo QA si no hubieran necesitado volver a validar el software? ¿Se postergaron otros proyectos para llevar esta solución al mercado? Hay muchos costos "ocultos" en los que la gente no piensa. Puede ser más fácil, pero no necesariamente menos costoso.
Pemdas
6

Comentaré algunos de sus comentarios, esperando que obtenga la respuesta de estos comentarios.

Una de mis principales frustraciones con el software es que nunca se "hace".

Esto se debe a que la especificación de la solución está incompleta o porque el plan para entregar mejoras no es exacto. Esto puede sucederle a cualquier software, hardware o cualquier otro proyecto.

¿Existe una buena metodología de desarrollo de software que permita que siempre se avance hacia adelante y que se agregue nueva funcionalidad sin necesidad de reescribir el código existente e introducir nuevos errores?

Por supuesto, la creación de módulos independientes debería reducir en gran medida la dependencia. Esto debe tenerse en cuenta al diseñar el software. Debe considerar la separación de preocupaciones, capas, niveles, objetos de controlador, interfaces, etc.

"¿Cómo puedo divertirme más escribiendo software al no introducir errores en el código de trabajo y siempre progresando?"

1-Comprender los requisitos con cuidado. Es posible que deba considerar cerrar los requisitos antes del diseño. Si realiza un desarrollo iterativo, no hay posibilidad de hacerlo. Algunas metodologías fomentan esto, pero personalmente, creo que esto no es bueno para todos los tipos de proyectos. La creación de software con requisitos sólidos permite un mejor diseño.

2-Haz que tu usuario entienda esta filosofía a largo plazo.

Implementación de 3 planes cuidadosamente

4-Diseño antes del código.

5-Use diseño genérico cuando sea apropiado.

6-Use prototipos como herramienta de confirmación de diseño.

Ninguna posibilidad
fuente
Todos estos son excelentes consejos. Para resumir mis pensamientos hasta este punto: (1) hacer lanzamientos una GRAN OFERTA y hacer muchas pruebas y control de calidad antes de un lanzamiento, (2) hacer módulos una GRAN OFERTA y asegurarse de que tengan interfaces bien definidas documentadas con pruebas para esos interfaces y aserciones para ver si se viola la interfaz y una vez que se "libera" un módulo, nunca se modifica (OCP).
Nathan Farrington
4

Como la gente suele señalar muy rápido, uno de los beneficios del software es que se supone que es fácil y relativamente barato cambiarlo en comparación con el hardware. Esto es especialmente importante cuando te das cuenta tarde de que tienes algo fundamentalmente incorrecto. Haga lo mismo con el hardware y perderá un millón de dólares, por lo que, como ha dicho, usa sus simuladores, etc., y prueba el bazinga. Creo que es aquí donde el paradigma falla un poco cuando cambias al software.

Métete en la cabeza del desarrollador de software promedio, y lo que tienes es una persona muy ocupada con un plazo increíblemente ajustado. Su gerente le dice que está bien dejar algunos errores porque siempre puede solucionarlo más tarde. Las pruebas son a menudo una idea de último momento, pero incluso en un escenario basado en pruebas, las pruebas se mantienen mínimas y el código se escribe al mínimo de las pruebas, y a menudo se toman atajos para que muchos de los casos límite puedan perderse. El sistema puede someterse a una prueba exhaustiva de la unidad, pero rara vez se prueba rigurosamente en su conjunto, y tan raramente se somete a prueba de esfuerzo en gran medida. Agregue a esto que usted escribe software desde cero, y hay pocas oportunidades para simular el software antes de comprometerse a escribirlo, principalmente porque raramente escribimos software del mismo tipo de bloques de construcción fina que encontraría en el hardware.

De vuelta a la pregunta del OP. ¿Podría definir un sistema de bloques de construcción del cual derivar todo su software? Posiblemente. ¿Sería muy rentable? Probablemente no, porque para cuando llegue el momento de desarrollar un sistema lo suficientemente robusto de componentes, pruebas y otra parafernalia para apoyar este idealEn el sistema de programación, descubriría que su competencia ya lo habría ganado al mercado y, lo que es peor, desde la perspectiva del programador promedio, probablemente encontraría que un estilo de sistema de programación "cortador de galletas" es muy limitante y muy probablemente muy aburrido. Personalmente, trabajo en una API, donde la mayor parte del código del módulo se ha refinado y estandarizado tan completamente, que todo lo que hago ahora es generar una plantilla de código y completar los espacios en blanco. La mayor parte de mi tiempo se puede dedicar a escribir código de conector simple y sacar los módulos de la puerta lo más rápido posible. Es realmente aturdidor. Hay muy pocas oportunidades para hacer algo más que codificar el mismo tipo de cosas una y otra vez, por lo que cuando aparece otra oportunidad de proyecto, aprovecho la oportunidad de poder hacer NADA más.

Entonces, ¿cómo puede llegar a ofrecer software de alta calidad y bien factorizado, y al mismo tiempo disfrutarlo haciéndolo? Creo que esto se reduce a su elección de herramientas y metodología. Para mí, la respuesta ha sido emplear el uso de una buena API BDD, porque me ha permitido crear un código muy fácil de leer, pero muy granular. Puedo construir un conjunto de pruebas a partir de un número mínimo de métodos reutilizables y describir mis pruebas en el idioma de las especificaciones. De esta manera, me acerco a un enfoque de desarrollo más componente, excepto por el hecho de que soy responsable de diseñar y verificar los componentes básicos. Además, la salida de la prueba señala la parte exacta de la prueba donde ocurre la falla, de modo que no tengo que adivinar si las fallas están en la configuración o en la afirmación.

Ajustar su metodología también ayuda. Soy un gran defensor de la aplicación de principios de desarrollo lean y de combinarlos con muchas de las otras técnicas y principios sobre los que el movimiento Agile ha estado trabajando durante muchos años. La eliminación de la mayoría de las prácticas derrochadoras que solía encontrar tan frustrantes ha ayudado mucho a hacer del desarrollo una actividad más agradable. Todavía me queda el problema de que a veces, pero con suerte no con demasiada frecuencia, aparecerán errores en mi código, sin embargo, ahora me encuentro con más tiempo e incluso más incentivos para pasar más tiempo escribiendo pruebas más sólidas y con el objetivo de 100 % de cobertura de prueba. Aún mejor, se siente realmente genial ver todas esas luces verdes aparecer al final de mi día,

S.Robins
fuente
Tengo curiosidad, escribes que las pruebas son importantes pero también alucinantes.
Nathan Farrington
@NathanFarrington Gracias por señalar eso. Mi punto era hablar positivamente sobre la prueba, pero estaba pensando en eso mientras escribía algo más, ¡así que salió completamente mal en ese párrafo! ¡He corregido para adaptarme al punto real que estaba tratando de iluminar!
S.Robins
3

Una de mis principales frustraciones con el software es que nunca se "hace". Siempre hay otra característica para agregar.

Si eso te frustra, considera una carrera diferente. Seriamente.

El objetivo del software es poder agregar funciones. La razón completa para inventar "software" en primer lugar fue para poder agregar funciones.

A menudo, al agregar una función, presenta un error en otro lugar que funcionaba bien antes.

Ese es un problema de control de calidad.

Esto no sucede en el hardware mientras no se violen las interfaces.

Eso también es cierto en el software.

¿Existe una buena metodología de desarrollo de software que permita que siempre se avance hacia adelante y que se agregue nueva funcionalidad sin necesidad de reescribir el código existente e introducir nuevos errores?

Sí. Tienes que practicar realmente el aseguramiento de la calidad.

S.Lott
fuente
1
Por cierto, no estoy tratando de troll, y sí, tal vez no estoy preparado para el software. Pero usted dice que "el punto del software es poder agregar funciones". ¿Es realmente? von Neumann inventó el software para poder construir una computadora que pueda calcular más de una función matemática sin necesidad de volver a cablear sus unidades lógicas y aritméticas. Tengo curiosidad de dónde viene esta filosofía de funciones de software. El hardware tiene funciones, pero el propósito del hardware no es agregar funciones.
Nathan Farrington el
Supongo que por Garantía de calidad te refieres a las pruebas. Sí, mi intuición dice que se requieren pruebas exhaustivas para producir software de calidad. Pero creo que va más allá de eso. En hardware, un módulo puede tener un error. Pero cuando agrega nuevo hardware, no introduce nuevos errores en un módulo de hardware existente. Finalmente, todos los errores en todos los módulos se pueden encontrar y corregir. Pero en el software, a menudo el código se cambia (los módulos se cambian) en lugar de agregarse, lo que puede introducir errores. Supongo que estaba buscando una metodología de desarrollo de software que fuera puramente aditiva.
Nathan Farrington el
Ahora tengo un comentario más inteligente sobre tu respuesta. La razón por la que me quejé acerca de que el software nunca se "realiza" es probablemente porque siempre he usado un enfoque muy impreciso para los lanzamientos. Una nueva característica equivale a la próxima versión, sin pruebas de regresión y muy poco control de calidad. Si los lanzamientos fueran una GRAN OFERTA, apuesto a que mis quejas sobre el software que nunca se ha hecho desaparecerían.
Nathan Farrington el
@NathanFarrington: Turing inventó el software para romper los códigos Enigma que cambian constantemente. "por Garantía de calidad te refieres a las pruebas". Falso. Me refiero a la garantía de calidad: cada aspecto del desarrollo debe tener estándares de calidad que deben cumplirse. Las pruebas son una forma (limitada) de evaluar la calidad de un tipo de artefacto. "el código ha cambiado ... lo que puede introducir errores". Correcto. Esa es una falla en la garantía de calidad, no una característica inherente del software.
S.Lott
Definitivamente estamos saliendo del tema. Según este enlace , el Coloso de Turing no era universal (en el sentido informático) y no utilizaba programas almacenados (software).
Nathan Farrington el
2

¿Es posible escribir software de una manera similar en la que el hardware está "escrito"? ¿Existe una buena metodología de desarrollo de software que permita que siempre se avance hacia adelante y que se agregue nueva funcionalidad sin necesidad de reescribir el código existente e introducir nuevos errores?

Le recomiendo que busque " métodos formales " para verificar la exactitud de los diseños y el software. Las herramientas de simulador que usa para el diseño de hardware están tratando de hacer algo cercano. No creo que las herramientas para métodos formales estén cerca de ser útiles en la industria en este momento, y las únicas industrias que tienen fuertes incentivos para estar libres de defectos son la aviónica y la medicina (curiosamente, la FDA dice claramente que "el software es diferente desde hardware "en ese enlace). Además, si está desarrollando con Verilog / VHDL, entonces se está quedando con la lógica binaria. Esto reduce drásticamente la complejidad. No habrá un hardware equivalente a un problema de Y2K.

El gran problema es que las cosas son complejas. Y no puede eliminar la complejidad, solo puede moverla.

Tangurena
fuente
1

es posible escribir hardware que está "hecho" y que nunca necesita ser modificado: usted define las interfaces y la funcionalidad, escribe un banco de pruebas, implementa el módulo de hardware y luego prueba con un simulador. Entonces puede confiar en ese módulo de hardware como un bloque de construcción para crear algo más grande y mejor: si necesita agregar una función a ese módulo, cree un segundo módulo y agregue la funcionalidad allí. Nunca deseche el módulo original, ya que funciona bien y aún puede ser útil.

En el mundo del software, llamamos a ese "módulo" una biblioteca, y lo usamos de la misma manera. Muchas bibliotecas están construidas hasta el punto de que funcionan bien, y luego se sientan satisfechas haciendo su trabajo sin cambios hasta que algo importante conduce a la próxima revisión. Piense en ellos como un software que está lleno de epoxy :-)

Una de mis principales frustraciones con el software es que nunca se "hace". Siempre hay otra característica para agregar. A menudo, al agregar una función, presenta un error en otro lugar que funcionaba bien antes. Esto no sucede en el hardware mientras no se violen las interfaces.

Bazofia. Tal vez usted es personalmente mejor que muchas otras personas de "hardware" sin soldador, pero he visto cualquier cantidad de diseños de circuitos defectuosos, chips defectuosos ( por ejemplo , el famoso problema Intel "f00f"), pero eso no hablar al campo como un todo. Y a medida que el hardware falso se vuelve "más blando", los problemas se vuelven más difíciles de prevenir.

¿Es posible escribir software de una manera similar en la que el hardware está "escrito"? ¿Existe una buena metodología de desarrollo de software que permita que siempre se avance hacia adelante y que se agregue nueva funcionalidad sin necesidad de reescribir el código existente e introducir nuevos errores?

Sí. Simplemente no usamos esas metodologías mucho. Tienden a ser extremadamente caros de operar, y la mayoría de los programadores no disfrutan trabajando dentro de sus restricciones. Pero cuando la vida humana está involucrada, por ejemplo, bueno, sí, tratamos de no matar a los usuarios.

Un último punto: el software tiene un modelo financiero diferente del hardware, incluso el hardware programado. La mayoría del software que no es para el consumidor, y también parte del software para el consumidor, se vende de una manera que fomenta el cambio. Cuando puede decirle a una empresa "Pague $ 10,000 ahora más 18% al año", esencialmente puede revender el producto cada pocos años. Pero para justificar esa tarifa, debe darle al cliente los cambios que desea. Hmm ... pensando en la curva de hardware obsolescencia de Apple, tal vez esto no es una diferencia después de todo - el hardware te hace realmente volver a comprarlo!

Ross Patterson
fuente
Nunca dije que era mejor que nadie. ;-) Cuando el hardware tiene un error, se convierte en noticia. Cuando el software tiene un error, ummm, el software de espera siempre tiene errores. ¿Qué metodologías son las que no usamos porque son demasiado caras y no divertidas?
Nathan Farrington
0

¿Cómo puedo divertirme más escribiendo software al no introducir errores en el código de trabajo y siempre progresando?

Me encantaría encontrar una respuesta final a tu pregunta. Pero la realidad es que no hay una manera fácil de hacerlo, es por eso que la programación extrema y las técnicas TDD se están volviendo tan populares. Necesitas aceptar el cambio, porque va a suceder. No sé si es más divertido de esta manera, pero mucho menos estresante seguro ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

Cuando interactúa con el hardware, el hardware necesita el valor x y eso es todo (en teoría), pero cuando interactúa con las personas de hoy, necesitan x, y mañana pueden necesitar y, etc. Así es como es, cambian los requisitos comerciales y de las personas . Porque personas! = Máquinas, entonces el código que NUNCA cambia la mayoría de las veces no es posible.

Además, como dije en mi respuesta anterior / eliminada, trate de evitar cambios que no sean importantes haciendo que la gente piense antes de comenzar a codificar. Involucre a los usuarios más en la toma de decisiones, etc. Aclare los costos de los cambios, planifique más, etc. Esas no son "formas de codificación", son formas de "no codificar" porque con más sobre los requisitos habrá menos cambios y más diversión.

H27studio
fuente
1
Buena respuesta. He hecho programación extrema. Parece exactamente lo contrario de lo que estaba buscando, donde toda la dirección del proyecto puede cambiar semanalmente dependiendo del capricho del cliente. No estoy en contra de los lanzamientos iterativos, simplemente no quiero que la segunda versión introduzca errores que no estaban presentes en la primera versión. Y tiene razón en que el diseño inicial puede ahorrar esfuerzo a largo plazo.
Nathan Farrington el
Como siempre digo, el mejor código es que no hay código. :-)
H27studio
0

¿Es posible escribir software de manera similar?

Sí lo es. Solo tenga cuidado como si estuviera desarrollando hardware, pruebe todo lo que pueda y su software tendrá una calidad similar.

por cierto, ¿no has oído hablar de los errores de HW? Mucho más desagradable que cualquier error de SW y más difícil de solucionar (no solo actualizar el software)

BЈовић
fuente
1
Sí, el hardware también tiene errores, incluso hardware maduro bien probado como los procesadores. ¡El buen hardware está diseñado para que los errores de hardware puedan repararse en el software! La razón de mi pregunta original es que he escrito mucho software, pero siempre me ha preocupado lo fácil que es introducir errores y lo desordenado que era el sistema en su conjunto. Soy una persona limpia, por lo que la metodología de desarrollo de hardware siempre me pareció más natural. También podría tener algo que ver con el alcance.
Nathan Farrington
1
@NathanFarrington El software suele ser más complejo que un HW. HW se prueba más a fondo. SW puede cambiar más fácilmente, por lo tanto, las personas tienden a no prestar tanta atención.
B 20овић
0

También quisiera señalar que los errores de software en el hardware a menudo pueden matar personas. Por lo tanto, se tiene más cuidado para determinar a fondo los requisitos y probarlos exhaustivamente por adelantado. Y esos requisitos no necesitan cambiar hasta que lo haga el hardware. Y dado que el nuevo hardware puede requerir una reescritura, sospecho que tampoco se acumula mucho.

Los requisitos comerciales, por otro lado, cambian constantemente, a veces apenas se puede obtener un requisito en la producción antes de solicitar un cambio. A veces, he tenido que cambiar el requisito varias veces antes de que llegue a producción. Este es el resultado de varias cosas. Primero, la parte interesada en el proyecto en el lado comercial a menudo está menos interesada en pasar el tiempo para definir a fondo lo que quiere porque está "ocupado" e "importante" y la gente no morirá y las familias lo demandarán o lo meterán en la cárcel si él se desprende de su parte del proceso. En segundo lugar, las partes interesadas del proyecto tienden a tener una mejor idea de lo que quieren que haga el hardware, ya que es menos abstracto para ellos. Realmente no saben lo que quieren hasta que lo ven. Lo cual es menos problemático con el hardware.

HLGEM
fuente
Tienes un punto válido. Los tipos de cosas que tradicionalmente hacemos en hardware son bien entendidos: procesadores, controladores USB, puntos finales PCI Express, controladores de memoria, etc. Luego, introducimos toda esa lógica empresarial de aplicaciones en software. ¿Tal vez a medida que avanzamos en la pila de software las cosas se vuelven más desordenadas y menos entendidas?
Nathan Farrington
-1

Hay herramientas de alto nivel con muchos 'ladrillos' terminados, como los llama, que puede combinar en aplicaciones. Los ladrillos son piezas terminadas para su uso, solo tiene que combinarlos. Tal vez piense que es más fácil ... hasta que su cliente le pida algunos cambios extraños e inesperados.

AndSoYouCode
fuente