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

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?

¿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

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 .

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.

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,

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.

¿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.

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!

¿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.

¿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)

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.

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.